Docker Compose in Production: 10-Point Checklist

Docker Compose was designed for development: its defaults favor simplicity over robustness. A container will not restart after a host reboot, its logs grow without limit, it can consume all the machine's RAM, and it listens on every network interface. In development, none of these behaviors cause problems because you relaunch the stack by hand several times a day. In production, these missing settings turn into incidents: full disk at 3 a.m., database lost after a docker compose down, service unreachable after a power outage. The good news: hardening a Compose stack requires no rewrite, only a dozen targeted additions. Run through each point before going live, and your service will handle load and reboots without constant monitoring.

You need a VPS with Docker Engine and the Compose v2 plugin. The command is docker compose, without a hyphen: check it with docker compose version, because the deploy.resources syntax outside Swarm requires Compose v2 (the old docker-compose is covered below). Check the engine too with docker version. Docker Engine 29.7.2 fixes CVE-2026-17106 (CopyEscape), a race condition in docker cp disclosed on 10 August 2026: an untrusted container can use it to overwrite a file on the host, including the runc binary. On workstations, the fix shipped in Docker Desktop 4.86.0. Until you update, do not run docker cp from a container whose content you do not control. Keep the project in a dedicated folder (/opt/myapp), with a .env set to chmod 600. Plan for an upstream reverse proxy — Traefik, Caddy or Nginx — because port binding assumes public traffic never reaches your containers, and keep the Compose file under version control.

Two tools carry almost the same name. docker-compose, with a hyphen, is Compose v1, written in Python: its repository declares it end of life since the general availability of Compose v2, announced by Docker on 26 April 2022. docker compose, with a space, is Compose v2, written in Go and plugged into the Docker CLI as a plugin. Ubuntu 26.04 completes the transition: the docker-compose package has been out of the archive since Ubuntu 25.10, and the docker-compose-v2 package installs only the plugin, in /usr/libexec/docker/cli-plugins/. After the upgrade, any script that still calls the old name stops on docker-compose: command not found. On the CI side, GitHub took Compose v1 out of its hosted runners on 9 July 2024, and moves ubuntu-latest to Ubuntu 26.04 between 19 October and 19 November 2026: a workflow that installed docker-compose by hand needs a second look. Two behaviour differences are documented. Container names use a hyphen instead of an underscore (myapp-web-1 versus myapp_web_1), unless you pass --compatibility. And the version: key is ignored, with the warning “the attribute version is obsolete, it will be ignored”.

A well-configured health check goes beyond a simple curl: it measures the functional state of the service, not just network availability. For an HTTP API, test a lightweight business endpoint (/health or /ready) that returns 200 only if the database connection is established. For PostgreSQL, use pg_isready -U postgres rather than curl. For Redis, redis-cli ping is sufficient. Check the state of your containers with docker compose ps: the STATUS column shows healthy, unhealthy or starting. A container stuck in starting beyond start_period signals an initialization problem — consult docker compose logs service to find the cause. The start_period parameter is distinct from interval: it defines a grace window during which failures do not count toward retries, which is essential for services that need time to populate data or run schema migrations.

Outside Swarm, Compose accepts file-based secrets. Declare the secret in the root-level secrets: section, pointing to a local file (file: ./secrets/db_password.txt), then reference it in the service with secrets: [db_password]. Docker mounts that file read-only in /run/secrets/db_password: the application reads it as an ordinary file, and its value appears neither in the environment variables shown by docker inspect nor in the logs. To rotate, version the secret: create db_password_v2 next to db_password_v1, make the service read v2, redeploy it alone with docker compose up -d --no-deps service, then delete v1 once the deployment is validated. The interruption is limited to recreating that one container, and the old secret stays available if you need to roll back.

Rolling back a Compose stack is prepared before the deployment, not after the incident. Keep the previous image tagged and available locally: add an explicit myapp:stable tag before each update. To roll back, put the old tag back in the Compose file (or in the .env if the version is a variable), then rerun docker compose up -d. Volumes are not touched by an image change, which makes an application rollback fast; a schema migration, however, needs its reverse migration ready before the deployment. For critical releases, split docker-compose.yml (stable version) and docker-compose.override.yml (candidate version): docker compose -f docker-compose.yml up -d ignores the override and returns to the stable state.

docker: unknown command: docker compose: the Compose plugin is not installed. On Ubuntu, install docker-compose-v2 from the archive, or docker-compose-plugin if Docker comes from Docker's official repository, then check with docker compose version. network not found: after a docker compose down, named networks are removed. If you restart and an external container tries to join that network, you get this error. Solution: declare shared networks as external: true or synchronize the restart of dependent stacks. port is already in use: another process (host nginx, an orphaned stack) occupies the port. Identify it with ss -tlnp | grep :PORT then stop it before restarting. OOM (Out Of Memory): the kernel kills a container without warning — look for OOMKilled: true in docker inspect container_id. Raise the memory limit (deploy.resources.limits.memory) or identify the leak with docker stats. permission denied on volume: the container process runs with a UID that has no access to the bind-mounted directory. Check the UID with docker compose exec service id, then adjust the host folder permissions (chown -R UID:GID /path) or add user: "UID:GID" to the service. Container restarting in a loop: docker compose logs --tail=50 service reveals the startup error. The most common causes are a missing environment variable, a missing config file or an unready dependency (solved by depends_on with service_healthy).

Copying files from a running PostgreSQL or MySQL volume with rsync or tar almost always produces a corrupted backup: the engine writes continuously during the copy, and data pages are captured at different checkpoints. The rule is to always run a SQL dump before the volume snapshot: pg_dump or mysqldump produce a consistent state you can archive or transfer. To automate this approach on a Docker VPS, tools like Restic and Offen Docker Backup orchestrate database freeze, SQL dump, encrypted snapshot and upload to remote storage. Document each named volume (step 5 of the checklist) and associate it with a tested restore strategy: a backup without a restore test is unverified data.

These ten settings turn a development Compose file into a stack that survives reboots, load spikes and unsupervised nights. Health checks, file-mounted secrets, a prepared rollback and a complete move to docker compose complete this foundation. None of it requires an additional tool: everything fits in the YAML and scripts you already have. Run through the checklist before each release, for example through a docker compose config review built into the deployment. You can then add a reverse proxy such as Traefik or Caddy, or an orchestration layer such as Coolify.