Docker in development: Episode 1

In this series, we’ll explore the motivation and benefits of using docker in development, and we’re going to give everyday tips that helped us moving forward using it, focused in Ruby/Ruby on Rails/React development.

This series will not explain what’s an image, a container, etc. If you don’t know that already, I strongly suggest you read docker's official documentation and then come back!


This is personal (and team!) experience, you might find yourself in similar situations, and this might help you move forward and give the first steps.

Until a couple of months ago, my standard setup for developing Ruby on Rails, minimalistic Ruby apps and React apps was plain simple.

For Ruby/Ruby on Rails, I just installed chruby, ruby-install (and the Ruby versions I needed, say 2.3, 2.5 and even 2.6!), cloned the projects, installed the gems using bundler, postgres (because we mostly use postgres) and I was ready to go. Of course, if I needed redis or other database I had to install it.

Similarly, for React projects, I just installed node and installed the dependencies. This process of installing the interpreters, the dependencies and such, with the help of homebrew (or apt-get if you use linux) is easy, but takes some time.

A month ago, I had a task to complete: fix a small bug in a Rails 3 app, on top of Ruby 1.9.3! That was a little bit harder than with new versions of ruby. Not for the interpreter itself, but the dependencies of the project. As time goes by, older dependencies might be harder to install because of their own dependencies. You might have newer versions of your dependencies' dependencies in your computer, and installing older stuff might cost time.

After thinking about it for a bit, I decided to dockerize the app. To be honest, I don't know if it took longer than fighting with the interpreter/dependencies versions, but the result paid off. Not only the bug was fixed easily, but since then I've decided to dockerize every app I work on (even some apps you might use daily as we'll see later), and as of now I use docker for local development exclusively: no chruby, no ruby-install, no postgres, no node, nothing.


Some of the benefits are obvious (specially if you’re into docker already), but we’ll go through them anyway so we expose a stronger case.

  1. Your whole project explains how’s set up from a system point of view: what database, services, etc.
  2. New developers can easily join the project and running just a command they’ll be ready to go.
  3. Your app won’t change as your local env changes. Normally, for, let’s say, bundler, that won’t be a problem, but you might end up using other binaries or libraries within your system that might change over time.


These are questions I asked myself (and you might have them as well):

Won’t I have a lot of disk space occupied by docker images?

Yes, you’ll have. But if you want you can just remove them and recreate them when you need them. It’s not a big of a deal! If you don’t want to build each time you can push your images to a repository (docker hub is an example).

What about the performance? Does it consume a lot of resources?

Short answer: no. They’re regular processes, and they consume the same resources they’d consume if you’d install all the requirements natively. You can look for yourself by running docker stats!

Do you have other questions? Get in touch!


The balance, for me, has been positive. Since I’ve been using docker, things have been exactly the same in terms of development time, getting up and running, etc. Plus, the benefits we already mentioned!

Join us in the next episode!

Got a project in mind?