Docker is useful when it removes a concrete source of variation: runtime versions, native libraries, worker dependencies or differences between environments. It becomes a burden when a small team inherits container networking, image maintenance and persistent storage without a clear benefit.
When Docker usually helps
- several services need different runtime or system dependencies
- the same tested image must move through staging and production
- workers need predictable, replaceable execution environments
- developers need reproducible local integration environments
- deployments require controlled rollbacks to immutable artifacts
Build once, tag with an immutable version and promote the same image. Configuration and secrets belong outside the image. Run processes as a non-root user, use minimal maintained base images and scan dependencies in CI.
When it can complicate the system
A single conventional application on one server may be clearer with system packages, a process manager and a documented deployment. Docker adds value only if the team can operate image registries, networks, volumes, log collection, health checks and upgrades.
Do not introduce Kubernetes because containers exist. A small Compose-based deployment can be appropriate when its failure model, backup plan and manual recovery are understood.
Persistent data and networking need explicit design
Containers are disposable; customer data is not. Keep databases and uploads in managed services or explicitly backed-up volumes. Test restoration outside the production host. Define service networks narrowly, publish only required ports and terminate TLS at a controlled edge or reverse proxy.
For process ownership outside containers, the comparison of PM2, Supervisor and systemd explains simpler alternatives.
Common mistakes
- using mutable
latesttags in production - baking secrets into images or Compose files
- running everything as root
- placing the database in a volume with no tested restore
- confusing a health check with application readiness
- sending logs only to a container's local filesystem
- rebuilding different images for each environment
- adding orchestration before defining operational ownership
Practical production checklist
- pin base images and application dependencies
- produce immutable, traceable image tags
- scan images and patch them on a schedule
- run with least privilege and a read-only filesystem where possible
- inject secrets through an appropriate secret store
- set CPU, memory and restart limits
- define readiness, liveness and graceful shutdown
- centralise logs, metrics and deployment markers
- back up persistent data and test restoration
- document rollback and host-recovery procedures
Traceability and stability
Record the Git revision, image digest, configuration version and deployment time. Monitor restarts, memory pressure, health failures and request outcomes rather than container uptime alone. Apply the baseline from logs, alerts and monitoring, and test graceful shutdown so deployments do not abandon jobs.
When hiring a technical person makes sense
Bring in a DevOps or platform engineer when deployments span several hosts, downtime is expensive, regulated data is involved, or nobody can confidently restore volumes and roll back images. They should simplify the operating model, automate repeatable controls and leave a runbook the team can execute.
Final takeaway
Choose Docker for reproducibility and isolation, not fashion. If the operational cost exceeds the variation it removes, a simpler deployment is better. For a production architecture review, see my technical services or contact me with the current topology and recovery requirements.