Dockerfile Generator

Build a Dockerfile from a form. Choose base image, working directory, ports, commands, and environment variables.

Presets

Base

FROM (base image)

WORKDIR

EXPOSE port

USER

Steps

COPY (deps first)

RUN

COPY (app)

CMD (start command)

Optional

ENV vars (one per line)

LABEL (one per line)

HEALTHCHECK

Dockerfile

Base Image: node:18-alpineLines: 15Bytes: 169

Dockerfile best practices

A Dockerfile is a script that defines how to build a Docker container image. Key best practices: use minimal base images (alpine variants), copy package files before source code to leverage layer caching, install only production dependencies, run as a non-root user, and use EXPOSE to document which ports the container listens on. Multi-stage builds (FROM ... AS builder) reduce final image size by separating build and runtime layers.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Producing a starting Dockerfile for a language you package rarely.
Getting the instruction order right so layer caching actually helps.
Generating a scaffold you then optimise with a multi-stage build.
Producing a consistent base across several services.
Checking which instructions a runtime needs before writing them by hand.

Frequently Asked Questions

Why copy the lockfile before the rest of the source?: Because each instruction is a cached layer keyed on its inputs. Copying `package.json` and the lockfile, running the install, and only then copying the source means a code change reuses the install layer. Copying everything first invalidates the install on every commit.
What does a multi-stage build achieve?: It leaves the toolchain behind. The builder stage compiles with a full SDK image, the final stage copies only the artefact into a minimal runtime — a Go binary in `scratch` or Alpine is single-digit megabytes against several hundred for the build image, and every tool omitted is one that cannot be exploited.
Should the container run as root?: No. It is the default, which is exactly why it needs an explicit `USER` line — a process escaping the container starts as root on the host in several configurations. Create an unprivileged user, `chown` what it needs to write, and switch before `CMD`.
What is the difference between CMD and ENTRYPOINT?: `ENTRYPOINT` is the executable and `CMD` supplies its default arguments, which `docker run` overrides. With `CMD` alone, arguments replace the whole command. Use exec form — `["node", "index.js"]` — because shell form wraps the process in `/bin/sh` and it stops receiving SIGTERM.
What does EXPOSE actually do?: Almost nothing at runtime — it is documentation plus a hint for `-P`. It does not publish the port; only `-p 8080:80` or a Compose `ports` entry does that. A container without EXPOSE still serves fine, and one with it is not reachable until you map it.

Common errors and gotchas

Copying the whole source before installing dependencies, which invalidates the cache on every change.
Running as root, which is the default and rarely what you want in production.
Using a `latest` base image tag, which makes builds non-reproducible.
Leaving build tools in the final image rather than using a multi-stage build.
Baking secrets in with an ARG or an ENV, which remain visible in the image history.