Dockerfile Boilerplate Generator

Fixing a Build That Won't Cache

The single most common Dockerfile complaint is "every build reinstalls all my dependencies, even when I only changed one line of application code." The cause is almost always instruction order: if COPY . . happens before the dependency install step, Docker's layer cache invalidates every subsequent layer the moment any file in the build context changes — including a README edit. The templates this generator produces deliberately copy only the dependency manifest (package.json, requirements.txt, go.mod) and run the install step first, so the expensive layer only re-executes when the manifest itself changes.

The second most common failure is a build that works locally but fails in CI with "no space left on device" or an out-of-memory kill during compilation. This usually traces back to a single-stage build that keeps every compiler, header file, and intermediate build artifact in the final image — a Go binary compiled without a multi-stage split can drag an entire Go toolchain and module cache along with it. Splitting the build into a builder stage and a slim runtime stage, which every template here does by default, generally resolves both problems at once: the CI runner only needs enough disk for the intermediate build stage, and the shipped image carries none of that weight.

Image Size at Fleet Scale

A single bloated image is an inconvenience; a bloated base image multiplied across a fleet of services is a real infrastructure cost. Every node in a Kubernetes cluster has to pull and cache each unique image layer, so a 900 MB unoptimized node:20-based image versus a 150 MB slim, multi-stage equivalent is the difference between a rolling deployment finishing in seconds and one that saturates node bandwidth and stalls pod scheduling during a large rollout. Registry storage and egress costs scale the same way — teams running dozens of microservices, each with its own image history, can find image storage becoming a non-trivial line item purely because nobody trimmed the base layer.

Cold-start-sensitive environments feel this even more directly: serverless container platforms and autoscaling node pools both have to fetch the image before a container can start serving traffic, so shaving hundreds of megabytes off a base image directly reduces scale-up latency during a traffic spike, which is exactly when you can least afford to wait on an image pull.

From Selection to Running Container

Selecting Node.js, framework "Express," port 3000, and the Slim base variant produces a two-stage Dockerfile along these lines:

FROM node:20-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

FROM node:20-slim
WORKDIR /app
RUN useradd --system --uid 1001 appuser
COPY --from=build --chown=appuser:appuser /app .
USER appuser
EXPOSE 3000
CMD ["node", "server.js"]

Running docker build -t my-api . followed by docker images typically shows a final image in the 150-180 MB range for a typical Express app — versus 900 MB or more from the unmodified node:20 base with no multi-stage split. Change only a route handler in server.js and rebuild: Docker reuses the cached npm ci layer instead of reinstalling every dependency, because the dependency manifest hasn't changed.

Where These Conventions Actually Come From

The practices baked into these templates aren't arbitrary style preferences — they trace back to published guidance. Docker's own Building Best Practices documentation recommends the layer-ordering and multi-stage patterns used here. The CIS Docker Benchmark and NIST SP 800-190 (Application Container Security Guide) both call out running containers as a non-root user as a baseline control, which is why every generated template includes a dedicated useradd step and a USER instruction rather than leaving the default root user in place. Kubernetes' own Pod Security Standards (Baseline and Restricted profiles) encode the same non-root requirement at the orchestration layer, so a Dockerfile that ignores it will eventually collide with a cluster's admission policy even if it runs fine on a laptop.

Frequently Asked Questions