Docker Compose in Production: Patterns and Pitfalls

Nick Janetakis’s video Best Practices Around Production Ready Web Apps with Docker Compose shows how Compose can serve as a production configuration tool rather than a dev convenience. The 33:34 director’s cut of his DockerCon 21 talk is a live single-host demonstration, not a certification or universal guide.

The central pattern is one Compose model with behavior changed through environment values and development configuration. The talk uses YAML anchors for shared settings, ${VAR:-default} interpolation, and a development-only Webpack service. This avoids separate files drifting apart. Treat the override-file example as historical context: Janetakis later wrote that Compose profiles became his preferred evolution of that approach.

The operational safeguards remain useful. Bind production ports to localhost — for example, 127.0.0.1:8000:8000 — when host-level nginx is public. Add CPU and memory limits, use unless-stopped for production restarts, and keep development on no. Put health checks in Compose; a useful /up endpoint should test PostgreSQL and Redis rather than merely return HTTP 200.

Send logs to stdout so Docker or an external collector can manage them. Prefer a managed production database while keeping Postgres in Compose locally. Multi-stage builds keep Node tooling out of the final image, while copying dependency manifests before application code improves layer reuse. Run as a non-root user and use array-form commands so the server becomes PID 1 and receives signals correctly.

The pitfalls are as valuable as the patterns: an unqualified port mapping can expose a service, container log files disappear when it stops, bind-mounting node_modules can make development heavy, and web/worker startup races can break shared assets. The video does not cover Kubernetes or provide benchmarks. Use it as a Compose baseline, then validate current features and your platform’s security model.