Moving from Heroku to Docker

Heroku is perfect when you're developing an application and need a quick and easy way to get it online. However, as your application grows in complexity it's easy to outgrow the initial benefits of a PaaS.

For many applications, there will come a time where the need for flexibility and control may outweigh the benefits of easy deployment and scaling.

Heroku vs. Docker

For the past decade, Heroku has made the lives of application developers infinitely better. It allows developers to focus on application development rather than configuring and managing infrastructures.

However, like any layer of abstraction, the benefits come with some drawbacks. Two of the major drawbacks with Heroku are price and flexibility.


It would be impossible to do a direct comparison of Heroku and Docker because they aren't the same thing. The cost of Heroku comes in the convenience it provides when deploying and managing applications. The cost of Docker comes in the time spent learning it, and managing the resulting infrastructure.

What you can do, however, is compare what each one offers, and their respective prices, and decide from there which fits your needs best.

If you're strictly going for a cost comparison, Heroku, for example, charges ~$25/month for a "Standard Dyno" with 512mb of memory and a single CPU. If going with Docker, you could go with something like AWS's t2.nano, which gives you the same resources at ~$4.75/month.

One important thing to remember here is that for the price, Heroku is giving you an easy way to deploy and manage your application without having to worry about any of the underlying infrastructure.

AWS, on the other hand, is giving you a server that basically does... nothing. You would then be tasked with configuring and managing your infrastructure.


Heroku provides a one-size-fits-all setup where everything your application needs to run is bundled up and deployed to their public cloud (which happens to run on AWS).

This inflexibility can be a huge drawback for a number of reasons.

First, whether you like it or not, you're stuck on AWS. This isn't a bad thing until all-of-a-sudden you don't want to be on AWS anymore for whatever reason.

Another issue is the level of control your given. You don't own the servers your application is hosted on, Heroku does. You can only interact with those servers to the level that Heroku allows.

Both of the above issues can cause problems when it comes down to things like security and compliance.

This isn't to say Heroku is bad. For many users it's exactly what they need; the ability to focus on application development rather than infrastructure. However, once you need more flexibility, you're out of luck.

From Heroku to Docker

It might seem like the obvious choice is to jump ship for Docker, but, keep in mind that while Docker might be more cost effective and flexible, it's not without its own challenges.

Docker is complicated. As your application grows, it will get even more complicated. And once you throw something like Kubernetes into the mix to start wrangling all your containers, you're wrestling with quite an infrastructure monster.

Unless you're really into that, it's probably not worth all the hassle. What would be most ideal is something that encompasses both the flexibility of Docker with the ease of deployment and management of Heroku.


Nanobox combines the flexibility of Docker and the abstraction of Heroku, with a complete development to production workflow.

Nanobox uses Docker to create isolated development and production environments that can be deployed anywhere. With an accompanying dashboard, you can easily manage, scale, and monitor your application.


Heroku is awesome. Docker is awesome. The ability to get the best of both worlds is liberating. It's like finally being able to have your cake and eat it too...

From: Why and How to Move from Heroku to Docker

Posted in Nanobox, Heroku, Docker, Hosting