When It's Okay to Use Runserver in Your Dockerfile

python manage.py runserver is not something you want to use in your production setup. After all, runserver is not your production server.

However, it’s completely okay to write a Dockerfile, where you use it! You will have a good time running a development server in your Docker container, if you are using them for development instead of deployment.

Let’s look at two cool use cases.

An automated example development setup

Readmes are great! You can explain the “why” behind your project and tech choices. Usually, you also provide people with a set of steps on how to set up your project for development.

There’s one frequent dilemma with these step-by-step kinds of documentation though:

• You have to try the steps every once in a while to see if they still work.
• If another dev has an issue, it’s hard to tell whether you left some important step out or if they missed something along the way.

Automation helps with those! Int this case, you can use either Vagrant, or Docker (+docker-compose) to create a one-command development environment. Think of this, as a nice addition to your written dev documentation. If it stops working, you know that it’s the code’s fault, and not because you forgot to follow a certain part of the instructions.

You can make sure that everything works by building and running the docker-compose stack. If somebody wants to see all the steps needed to reproduce the setup, they simply can look into the Dockerfile and see all OS libraries and configuration steps.

One command to run a local backend stack

Not everybody is into backend development. Docker can be a nice tool to provide other team members, such as frontend developers, with a one-command backend setup.

This can go hand-in-hand with the previous point, but would need to be extended to contain useful data from the get-go. Imagine, if people don’t need to get to know a completely new set of backing services and development environment gotchas, just to use the API they need.

Instead, they can run docker-compose up, point their local development server to the now-running local port and interact with their own version of the backend. No magic, or explaining how pip works required. Also, as they are not changing the backend frequently while they work, they won’t be impacted by a Dockerfile which needs a while to build.

In Conclusion

There are good reasons to write a Dockerfile which runs a local development server. Just don’t use it for production deployments.

After all, Docker isn’t exclusively reserved for production usage. Not all environments need to live up to the same high requirements. Instead, think of Docker as a development tool, which can help you to get work done. Alternatively, you can make your development environment nicer as an in-between step towards getting comfortable with Docker. No risk, but all the upsides.

If you haven’t already, go ahead and try to dockerize your development environment. Don’t aim to integrate it perfectly into your current workflow, but look at it as an opportunity to learn and experiment. Just one more useful piece of tooling to, instead of a cure-all and the only way to do things.