Docker Compose works in production in 2026 if you manually close five gaps: orphan containers, disk bloat, unhealthy container restarts, mutable image tags, and Docker socket security.
Key Takeaways
Use --remove-orphans on every docker compose up or removed services keep running, still bound to ports, invisible to docker compose ps.
Cap logs in /etc/docker/daemon.json with max-size and max-file; the default json-file driver writes unbounded logs until the disk fills and containers crash.
Health checks report status but never trigger restarts; wire in willfarrell/docker-autoheal or use Docker Swarm to get actual self-healing behavior.
Pin images by digest (myapp@sha256:...) not tag; tags are mutable and two hosts pulling the same tag minutes apart can run different code.
Mounting /var/run/docker.sock gives a container effective root on the host; use rootless Docker or docker-socket-proxy to limit blast radius.
Hacker News Comment Review
Strong consensus that Compose is genuinely production-ready for single-node, low-scale, or vendor-distributed workloads; the debate is about scope, not soundness.
A recurring warning: teams that bolt on features like external DNS, rolling updates, and auto-scaling are incrementally rebuilding Kubernetes without its operational model.
Docker’s port publishing bypasses host firewalls by writing iptables/nftables rules directly; commenters flag this as a sharp edge that surprises operators managing host-level firewall rules alongside Compose.
Notable Comments
@__jonas: Adds port publishing bypassing host firewalls as a real production gotcha not covered in the article.
@merpkz: Raises nftables conflict in detail – Docker daemon manages its own firewall rules, breaking host-level firewall management.
@noodlesUK: Suggests Podman plus systemd as a stronger fit for Linux appliance-style deployments where Compose’s operational gaps matter most.
