A Docker setup that works on a developer's laptop is a long way from one that survives production. The gap is a set of practices around image size, security, and reliability that are easy to skip and expensive to omit. Here are twelve we apply to every image before it ships, and they underpin the container choices in our orchestration guide.
1. Use multi-stage builds
Build with all your tooling in one stage, then copy only the compiled output into a clean, minimal final image. Your build toolchain has no business in production. Multi-stage builds shrink images dramatically and remove an entire class of vulnerabilities that ship with build tools.
2. Start from minimal base images
A smaller base means a smaller attack surface and faster pulls. Prefer slim or distroless bases over full operating system images. Every package you do not include is a package that cannot have a vulnerability.
3. Run as a non-root user
By default containers run as root, so a container escape hands the attacker root. Create and switch to an unprivileged user. This is a foundational control that also appears in our cluster hardening list.
4. Pin your versions
Avoid the latest tag. Pin base images and dependencies to specific versions so builds are reproducible and a surprise upstream change cannot break or compromise you silently.
5. Use a dockerignore file
Keep secrets, local config, and the version control directory out of the build context. It speeds builds and prevents accidentally baking sensitive files into an image.
6. Leverage layer caching
Order instructions from least to most frequently changing, and copy dependency manifests before source so dependency installation is cached. Well-ordered layers turn a slow build into a fast one.
7. One concern per container
A container should do one job. Combining a web server, a database, and a worker into one image defeats the point and makes scaling and recovery harder. Compose multiple single-purpose containers instead.
8. Add health checks
Define a health check so the orchestrator knows whether the application inside is actually working, not just whether the process is running. This is what lets traffic route only to healthy instances.
9. Handle signals properly
Ensure your process receives termination signals and shuts down gracefully, finishing in-flight work before exiting. Containers are killed and rescheduled constantly, so clean shutdown is a reliability feature.
10. Scan images for vulnerabilities
Make image scanning part of your continuous integration pipeline so known issues are caught before deployment, not after a breach.
11. Never bake in secrets
Secrets must not live in the image or the Dockerfile. Inject them at runtime through the environment or a secrets manager, because anything in the image is readable by anyone who pulls it.
Why small images matter more than you think
It is tempting to treat image size as a vanity metric, but in production it compounds across everything. Smaller images pull faster, which means quicker deployments, faster autoscaling when traffic spikes, and less time to recover when a node fails and workloads must be rescheduled. They also have a smaller attack surface, because every tool and library you did not include is one that cannot harbour a vulnerability. A bloated image carrying a full operating system and a build toolchain is slower, more expensive to store and transfer, and riskier, all at once. The discipline of multi-stage builds and minimal bases is not aesthetic housekeeping; it directly improves how quickly and safely your system responds to the events that matter most, which are exactly the moments when you cannot afford a slow pull.
12. Set resource limits
Constrain CPU and memory so one container cannot starve its neighbours. Limits are both a reliability and a security control. If you want your containerisation reviewed against this list, our cloud and DevOps team does it routinely.