Running Docker on a Cloud Server, Properly

Set the host up first

1. Install Docker from the official repository, not the distribution package, which is often well behind.
2. Add your user to the docker group, and understand that this is equivalent to root access on the host.
3. Configure log rotation in daemon.json, or container logs will fill the disk. This is the most common single-server failure there is.
4. Set up a firewall — and note that Docker manipulates iptables directly, so published ports can bypass ufw rules unless you account for it.
5. Put containers on a private Docker network and publish only what must be public.

The ufw interaction surprises people regularly: a container published with -p 5432:5432 is reachable from the internet even when ufw appears to deny it. Bind to 127.0.0.1 explicitly when a port should be local only.

Compose as the deployment unit

A single compose.yaml describing the whole stack — application, database, cache, reverse proxy — is readable, version-controllable and reproducible. For one server it is the right level of abstraction.

• Pin image tags to versions, never latest, or a redeploy silently changes what runs.
• Set restart: unless-stopped so containers survive a reboot.
• Declare health checks, so dependent services wait for readiness rather than crash-looping.
• Use named volumes for data, not bind mounts into arbitrary paths.
• Keep environment values in a .env file that is not in the repository.
• Set memory and CPU limits, so one container cannot starve the host.

Images: small, layered, reproducible

1. Use multi-stage builds so build tools do not ship in the final image.
2. Start from a slim or Alpine base where compatible.
3. Order instructions so rarely-changing layers come first and caching works.
4. Copy dependency manifests and install before copying source, so a code change does not reinstall everything.
5. Never copy secrets into an image — they persist in the layer history even if deleted later.
6. Run as a non-root user inside the container.
7. Add a .dockerignore, or you will copy .git and node_modules into every build.

Data and backups

Containers are disposable; their data must not be. Named volumes survive container replacement, and they live on the host, so they need the same backup treatment as any other data.

• Back up volumes on a schedule, not only the host disk.
• For databases, use the database’s own dump command rather than copying files from a running container.
• Store backups off the host.
• Test a restore into a fresh container occasionally.

Logging and disk

By default Docker’s json-file driver keeps logs indefinitely. On a busy service this fills the disk, which stops everything at once. Set it explicitly:

In /etc/docker/daemon.json, configure the json-file driver with a max-size such as 10 MB and max-file of 3. Apply it globally so every container inherits it, and restart Docker for it to take effect.

Add docker system prune on a schedule to remove unused images and build cache, which otherwise accumulate steadily.

Deploying updates

1. Build the image in CI and push it to a registry, tagged with the commit.
2. On the server, pull the new tag and run docker compose up -d.
3. Compose replaces only changed containers, so unaffected services keep running.
4. For a zero-downtime web tier, run two replicas behind the reverse proxy and replace them one at a time.
5. Keep the previous tag available so rollback is a single command.

This is a simple, reliable deployment mechanism that a small team can operate confidently, which matters more than sophistication.

Common questions

Where to go next

See Kubernetes: when and why and reverse proxy basics.