Docker for business apps: when containers help and when they don’t
“It works on my machine” stops being an excuse once the machine’s setup ships with the app. That is what Docker does, at the cost of one more thing to learn and keep up to date.
Reviewed by: Rahul Jaiswar, founder
Images and Compose
Docker packages an application with its runtime and libraries into an image that runs the same way on a laptop, a build server or a production host. Docker Compose describes several containers, such as an app, a background worker and a database, that start together.
Does a small business app need Docker?
Often not. A website or a single service deployed to a platform that builds straight from your code repository gains little from a container. Docker starts paying for itself when the system has more than one moving part in more than one language, or when it runs on a server you control and has to behave the same there as on a developer’s laptop.
Where we use it
We run containerized apps with Docker, and our self-hosted voice infrastructure runs in containers too. The voice layer itself is covered on the LiveKit page and under voice agents.
What we check
Database connections are opened on first use rather than when the code loads. That way building a container image never needs a live database to succeed.
We also deploy and host the apps we build. Some projects run on a platform such as Railway, others on a managed virtual private server, where containers keep the setup identical from a laptop to that machine. The hosting accounts are in your name, and the region is chosen with you; a US region is an option.
Cases where containers pay off
- The system mixes languages, such as a Node.js app with a Python worker, and both need exact versions.
- Open-source software is self-hosted on your own server.
- A later move between hosts should need no rebuild.
- A new developer should be able to start the whole system with one command.
Cases where a container adds work
- A website deploying to a platform that builds from your repository gains nothing from a container.
- A single small service on a platform that builds from source, such as Railway, can skip the Dockerfile.
- Real-time audio and video use WebRTC, which needs wide UDP port ranges. Docker’s default network translation can get in the way, and host networking is often the practical setup.
Before you ship an image
- Secrets in image layers. A key copied in during a build stays in the image history even if a later step deletes it. Pass secrets at runtime, and if the build itself needs one, use a BuildKit secret mount, which is never saved in a layer.
- The
latesttag. Deployinglatestmakes it unclear what is running and hard to roll back. Tag images by version or commit. - Containers running as root. A compromised process gets more access than it needs. Run images as a non-root user wherever the software allows.
Building an app with more than one moving part?
Tell us what the app needs to do and who will use it. We build these under software and web apps, and we can deploy and host them as well.