Docker on a server: when containers pay off

A developer said "just put it in Docker", and now the server runs six containers and nobody knows exactly what each one does. Or the opposite: the application was installed on the server by hand years ago, and every update is scary because nobody remembers which libraries and settings it depends on.

Docker is neither good nor bad by itself. It is a tool that solves one specific problem — the application and its environment travel together — and brings a couple of new ones. Below is when I recommend it and when I don't.

Short answer: Docker pays off when a server runs several applications with different version requirements, when the application has to be installed repeatedly and identically, or when an old application needs to be isolated from a new system. For one simple website that nobody updates, it mostly adds complexity.

When containers really help

• Several applications, different requirements. One needs an old Java or PHP version, another a new one. Without containers that means version chaos on the server; in a container each application has its own environment.
• Updates and rollbacks. A new version is a new image. If something goes wrong, you start the previous image and are back where you were within minutes.
• Migration. When the application is in a container and the data is clearly separated, moving to a new server is far more predictable. The same goes for moving to a new Ubuntu LTS — upgrading the host system does not break the libraries inside the application.
• Repeatable installs. Development, test and production are built from the same description, not by hand into "roughly the same" state.

When Docker is just extra complexity

• The server runs one simple application that works and rarely changes.
• Nobody is there to monitor and update the containers. A container does not update itself — an old image stays old even when the host is patched.
• The application is tightly bound to the server itself (hardware, file system, specific services), and containerising it would mean a big rewrite without a clear benefit.

What changes with containers

Updates. Besides the operating system, the images need updating too. An old image tagged latest that has not been pulled for months can contain software just as outdated as a neglected server. I always agree who updates the images and how often.

Backups — this is where most mistakes happen. A container is disposable; the data must not be. The database, uploaded files and configuration have to live in volumes or on the host, and backups must cover exactly those. If a database lives in a container without a volume, it disappears with the container. I always back up a database with its own tool (for example a PostgreSQL or MySQL/MariaDB dump), not by copying volume files while it is running.

Logs. Container logs need to go somewhere they can be read and where they will not fill the disk. Otherwise, six months later you find gigabytes of logs nobody has ever looked at.

Security. A container is not a security boundary by itself. Don't run the application as root, don't expose the database port publicly and don't bake passwords into the image. Securing the server itself stays the same — see my Linux server security checklist.

A typical setup

For a small business application I usually use this pattern:

1. Nginx in front — accepts HTTPS connections and routes requests to the right container. Nginx can itself run in a container or on the host.
2. The application in a container — with its own versions, without interfering with anything else.
3. The database — either in its own container with a volume or directly on the host. When there is a lot of data and performance matters, I often prefer the database on the host: it is easier to monitor, tune and back up.

The same logic applies to heavier components like Tomcat, Elasticsearch or OpenSearch — each in its own container with clearly defined data directories.

Moving an old application into containers, step by step

There is no need to rebuild everything at once. I usually go like this:

1. Map what really runs on the server: versions, configuration, scheduled jobs, where the data lives.
2. Put the application in a container while the database stays as it is for now. Test it in a separate environment.
3. Switch over once testing passes — the old installation stays as a fallback.
4. Only then decide whether the database and other parts go into containers too.

If the application itself needs real modernisation, see also my post on whether to modernise or rewrite legacy software and the software modernisation service. If a server change comes with it, the server migration guide helps.

If your server runs Docker that nobody maintains any more, or you are wondering whether your application is worth containerising, write to me. Describe in a couple of sentences here what runs on the server — I reply within one business day and tell you honestly whether containers would gain you anything. More about server management is on the Linux server management page.

Frequently asked questions

Does Docker make the server faster?

Not noticeably. The overhead of a container is small, but it is not a performance gain. Docker is a tool for installation and maintenance, not an accelerator.

Should the database run in a container?

It can, as long as the data is in a volume and backups are in order. With larger data volumes and higher demands, I often prefer the database directly on the host.

Is Docker Compose enough, or do I need Kubernetes?

For a small business's applications on one server, Docker Compose is usually enough. Kubernetes makes sense only when there are many servers and services that need to scale automatically.

Do containers update themselves?

No. Images have to be updated regularly and the containers restarted — it is one of the first things I agree on in a maintenance contract.