Running Docker properly on Debian 13 – 15 things administrators should know

Debian 13 “Trixie” is the current stable Debian release. For Docker administrators, this is a good time to review an installation for stability, maintainability and security rather than treating Docker as just another package.

Docker CE or the Debian package?

Debian offers multiple ways to obtain Docker. Pick one packaging strategy deliberately and avoid mixing components from unrelated repositories. If you use Docker’s official repository, keep Compose and Buildx within the same ecosystem.

docker compose is the modern path

Compose V2 is integrated as a Docker CLI plugin. The modern syntax is `docker compose`. Existing `docker-compose` installations should be identified before migration rather than removed blindly.

Docker data is not where many people expect

Containers, images, networks and volumes are managed under `/var/lib/docker` by default. Do not casually delete or clean this directory. Relocating it should be done through Docker configuration with a controlled migration plan.

Volumes are data

A container is replaceable; a volume often is not. Databases and stateful services should use persistent volumes or deliberately mounted directories. Before upgrades, identify which volumes are critical.

Logging: the underestimated disk consumer

Docker can collect container logs locally. Without rotation, one noisy service can consume huge amounts of disk space. Choose a deliberate strategy: rotation, journald, a central collector or another logging backend.

Restart policies are not monitoring

`restart: unless-stopped` can restart a failed container, but it does not prove that the application works. Healthchecks and external monitoring provide the missing application-level visibility.

Use healthchecks for real service state

A healthcheck should test the service, not merely the process. For web applications that can mean an HTTP request; for databases it should validate an actual database connection.

Understand Docker networks

Compose normally creates private bridge networks. Containers can communicate through service names, which is more robust than hard-coded IP addresses. Only publish host ports that genuinely need to be reachable.

Publish as few ports as possible

Internal database traffic does not normally need a host port. A reverse proxy and database can communicate over their private Compose network without exposing the database to the host network.

Updates: do not blindly replace everything

Images change. A blind `pull` followed by `up` can break production. A safer process is backup, pull, configuration validation, update, smoke test and rollback if necessary.

docker system prune is dangerously convenient

`docker system prune` is useful but should not be treated as a harmless scheduled cleanup. Know exactly what will be removed before running it.

Database backups should leave the container

For MariaDB or PostgreSQL, a logical dump is often preferable to merely copying a live data directory. Backups must be restored periodically to prove they work.

Keep secrets out of Git

Passwords in Compose files and `.env` files can easily end up in repositories. Restrict permissions at minimum; for higher requirements use Docker Secrets or a dedicated secret manager.

Host patching and image lifecycle are separate

A patched Debian host does not make container images current. Host patching and image updates are two separate operational tasks.

A practical model for small Docker servers

A clean structure, documented environment files, backups outside Docker storage, deliberate restart policies, healthchecks, controlled updates and external monitoring create a boring and reliable Docker platform.

Conclusion

Docker becomes reliable through clear packaging, reproducible Compose projects, separated data, controlled updates, tested backups and monitoring—not through clever tricks.