Stop Writing Bad Dockerfiles: Production-Ready Best Practices That Actually Work

Most Dockerfiles are a disaster waiting to happen. I inherited a project last year with a Dockerfile that took 12 minutes to build. Twelve. Minutes. For a simple Node.js API. The final image was 1.8GB. There were five different :latest tags scattered throughout. And it ran as root. That project taught me everything about what NOT to do. Here are the Dockerfile best practices that will save you from those mistakes. The Problem with Typical Dockerfiles Most developers write Dockerfiles like this: FROM node:latest COPY . . RUN npm install CMD ["node", "index.js"] This looks fine until you realize it: Rebuilds everything on every code change Includes your node_modules in the image Uses an unpredictable Node version Has no error handling Runs as root Let's fix this. 1. Always Pin Specific Versions Never use :latest . When you build next month, you might get a completely different base image with breaking changes. # Bad FROM node:latest # Good - specific version FROM node:20.11.0-alpine3.19