Dockerfile Generator

Generates a Dockerfile for common stacks, with the base image, dependency install and start command laid out in the right order. A starting point that already avoids the mistakes that make images slow to build and large to ship.

Live demo · real result from this tool
Stack
Package manager

Dockerfile

# syntax=docker/dockerfile:1 ARG NODE_VERSION=24 # ---- Dependencies: cached until the manifest or lock file changes ----FROM node:${NODE_VERSION}-alpine AS depsWORKDIR /appCOPY package.json package-lock.json ./RUN npm ci # ---- Build ----FROM deps AS buildCOPY . .RUN npm run build # ---- Production dependencies only ----FROM node:${NODE_VERSION}-alpine AS prod-depsWORKDIR /appCOPY package.json package-lock.json ./RUN npm ci --omit=dev
# ---- Runtime ----
FROM node:${NODE_VERSION}-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=prod-deps --chown=node:node /app/node_modules ./node_modules
COPY --from=build --chown=node:node /app/dist ./dist
COPY --chown=node:node package.json ./
# The official image ships a non-root user called node
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

.dockerignore

.git.gitignoreDockerfile*.dockerignore*.md.env.env.*!.env.example.vscode.ideacoveragenode_modulesdistbuildnpm-debug.log*

Dependency manifests are copied and installed before the source, so editing code does not reinstall packages. Never put secrets in the image — use build secrets or runtime environment variables.

Processed on your device — nothing is uploaded.

How to use Dockerfile Generator

  1. Pick your stack and runtime version.
  2. Review the generated stages and adjust the start command.
  3. Add a .dockerignore, pin the base image, and set a non-root USER before shipping it.
  4. Copy dependency manifests and install before copying source — it is the difference between a 5-second and a 3-minute rebuild.
  5. Multi-stage builds typically cut image size by 80% or more.
  6. Never put a secret in any layer; deleting it in a later instruction does not remove it.

Layer order is what makes builds fast

Docker caches each instruction and invalidates everything after the first change. So copying your whole source tree before installing dependencies means every source edit reinstalls every package — minutes per build, forever. Copy the manifest first (package.json, requirements.txt, go.mod), install, then copy the source. Dependencies change rarely and source changes constantly, so ordering by rate of change turns a three-minute rebuild into a five-second one.

Multi-stage builds, and why your image is 1.2 GB

A build needs compilers, dev dependencies and toolchains; running needs none of them. A multi-stage build compiles in one stage and copies only the artefacts into a clean runtime image, which routinely takes a Node image from 1.2 GB to under 200 MB and a Go one to under 20 MB. Smaller images pull faster, start faster, and — the part people forget — contain far less software for a vulnerability scanner to find.

Pin the base image, and do not run as root

FROM node:latest means your build is not reproducible and can break overnight when the tag moves. Pin at least the major and minor version, and for anything that matters pin the digest. Separately: containers run as root by default, so a container escape starts with root on the host. Add a non-root user and USER it before the final command — two lines, and it is the single highest-value hardening step in a Dockerfile.

Secrets do not belong in the image

Every layer is stored and every layer is readable. A secret added in one instruction and deleted in the next is still in the image history, retrievable by anyone who pulls it — this is a recurring source of leaked credentials in public registries. Use build secrets, runtime environment variables, or a secrets manager. And write a .dockerignore: without one you will copy .git, node_modules and .env into the image, which is both bloat and a leak.

Frequently asked questions

Is the generated Dockerfile production-ready?
It is a solid, optimized starting point using multi-stage builds — review the base image version and exposed port against your deployment target before shipping.
Is this configuration production-ready as written?
It is a solid, secure-by-default starting point — review ports, paths, and credentials for your actual server before deploying.
Does this tool send my configuration anywhere?
No. Everything is generated client-side in your browser; nothing is uploaded to any server.
Why is my Docker image so large?
Usually build tooling left in the runtime image, plus a base image larger than needed. Use a multi-stage build so only the artefacts reach the final stage, and prefer a slim or alpine base where your dependencies allow it.
Why does every build reinstall all my dependencies?
Because the source is copied before the install step, so any source change invalidates the cached install layer. Copy only the manifest, run the install, then copy the source.
Should containers run as root?
No. It is the default and it is worth changing: create a non-root user and switch to it with USER before the final command. It costs two lines and removes the most direct path from a container compromise to host root.

How do we know nothing is uploaded? Test it yourself on the privacy proof page.

Written by the ToolsRift team · Last updated

Pages are drafted with AI assistance and checked by automated tests. How we write and check pages.

Was this tool useful?

Report a problem

Related tools

Start typing to search every tool.

↑ ↓ to moveEnter to openEsc to close