SSH Workbench

Dockerfile Generator

Build a Dockerfile from a form. Supports multi-stage builds, env vars, healthchecks, and inline best-practice hints.

Client-side only — nothing leaves your browser

Image

Pin a specific tag. Avoid :latest in production.

Copy lockfiles before source so dependency installs cache better.

Blank lines separate RUN layers. Lines in one block are joined with && \\ to keep them in a single layer.

Space- or comma-separated. e.g. 80 443, 53/udp

Run as a non-root user in production

The default command to run.

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
COPY . .
RUN npm ci --omit=dev
EXPOSE 3000
USER node
CMD ["node", "server.js"]

Build steps

  1. 1. Save as Dockerfile in your project root
  2. 2. docker build -t myapp:latest .
  3. 3. docker run --rm -p 3000:3000 myapp:latest

What is a Dockerfile?

A Dockerfile is a plain-text recipe that tells the Docker build engine how to assemble a container image. Each instruction — FROM, COPY, RUN, ENV, CMD — runs in order and adds a new layer to the image. When you run docker build ., the engine reads the Dockerfile in the current directory and produces a runnable image. The same Dockerfile works with Podman, BuildKit, Buildah, and most container CI systems without modification.

Dockerfile Instructions Reference

Quick reference for every instruction this generator produces.

InstructionPurpose
FROMBase image the build starts from. Must be the first instruction (after optional ARG).
WORKDIRSet the working directory for subsequent RUN, COPY, CMD, ENTRYPOINT.
COPYCopy files from the build context into the image.
ADDLike COPY but also handles remote URLs and auto-extracts tar archives. Prefer COPY.
RUNExecute a command at build time. Each RUN creates a new layer.
ENVSet an environment variable available at build and runtime.
ARGBuild-time variable. Available only during build, not at runtime.
EXPOSEDocument which port the container listens on. Does not publish it.
USERSet the user (and optionally group) for subsequent instructions and the running container.
CMDDefault command/arguments. Overridable at `docker run`.
ENTRYPOINTFixed prefix of the container command. CMD becomes its arguments.
HEALTHCHECKProbe the container periodically; report healthy/unhealthy.
VOLUMEDeclare a mount point with anonymous-volume semantics.
LABELAttach metadata key=value pairs to the image.

Dockerfile Best Practices

Pin your base image

Use a specific tag like node:20-alpine, not :latest. Better still, pin by digest (image@sha256:...) for fully reproducible builds.

Order layers from least to most volatile

COPY package.json && install dependencies before COPY of source. Source changes won't bust the dependency-install cache.

Combine RUN instructions

Each RUN creates a layer. Chain related commands with && \ and clean caches in the same layer (e.g. rm -rf /var/lib/apt/lists/*).

Use multi-stage builds

Compile in a fat builder image, COPY --from=builder into a slim runtime. Drops compilers, dev deps, and toolchains from the shipped image.

Run as a non-root USER

Most base images include a non-root account (e.g. node). Set USER before CMD so the process drops privileges.

Prefer COPY over ADD

COPY is predictable. ADD also fetches URLs and auto-extracts tarballs — usually surprising. Use ADD only when you need those features.

Use exec-form CMD/ENTRYPOINT

CMD ["node", "server.js"] receives signals directly. The shell form runs under /bin/sh -c and swallows SIGTERM on shutdown.

Add a .dockerignore

Exclude node_modules, .git, build artifacts, and secrets from the build context to make builds faster and smaller.

Dockerfile Examples by Stack

Common base-image picks for popular runtimes. Use them as the starting point for the FROM field above.

StackBase imageTypical CMD
Node.jsnode:20-alpinenode server.js
Next.jsnode:20-alpine (build) → node:20-alpine (run)node .next/standalone/server.js
Pythonpython:3.12-slimpython app.py
FastAPIpython:3.12-slimuvicorn main:app --host 0.0.0.0 --port 8000
Java / Spring Booteclipse-temurin:21-jrejava -jar app.jar
Gogolang:1.23-alpine (build) → scratch (run)/app
Static site (Nginx)nginx:alpinenginx -g 'daemon off;'

Frequently Asked Questions

What is a Dockerfile?
A Dockerfile is a plain-text file containing the instructions Docker uses to build a container image. It starts with a FROM line that picks a base image, then a series of instructions like COPY, RUN, ENV, EXPOSE, USER, and CMD that each add a layer to the resulting image. When you run `docker build .`, the engine reads the file named Dockerfile in the current directory (no extension), executes the instructions in order, and produces a tagged image you can run as a container. The same file works with Docker, Podman, BuildKit, and Buildah, and is the standard way to describe a reproducible container build in version control.
What is the difference between CMD and ENTRYPOINT in a Dockerfile?
ENTRYPOINT defines the fixed program a container runs; CMD provides the default arguments to that program (or the full command if there is no ENTRYPOINT). Use ENTRYPOINT when the container is essentially a wrapper around a single binary — for example ENTRYPOINT ["nginx"] with CMD ["-g", "daemon off;"]. Then `docker run myimage -t` overrides only the arguments, not the binary. Use CMD alone when you want users to be able to replace the whole command with `docker run myimage bash`. Combining both gives sensible defaults that callers can selectively override. Always prefer the exec form (JSON array) so signals like SIGTERM reach your process directly — the shell form wraps the command in `/bin/sh -c` and breaks graceful shutdown.
What is the difference between ARG and ENV in a Dockerfile?
ARG defines a build-time variable — it's available only while `docker build` is running and disappears from the final image. ENV defines a variable that's set in the image and visible to the running container at runtime. Use ARG for things you pass with `--build-arg`, like a version number, build flag, or private package URL that shouldn't leak into the image. Use ENV for things the application needs at runtime, like NODE_ENV=production or DATABASE_URL. ARG values can be referenced by later ENV lines (e.g. ARG VERSION then ENV APP_VERSION=$VERSION) to bake a build-time value into a runtime variable. Note that ARGs declared before the first FROM are global and only available in FROM lines themselves.
What is the difference between COPY and ADD in a Dockerfile?
COPY just copies files from the build context into the image — predictable and explicit. ADD does everything COPY does and adds two behaviors: it can fetch a remote URL as the source, and it auto-extracts local tar archives (.tar, .tar.gz, .tar.bz2) into the destination directory. Those extras sound convenient but are usually surprising — a .tar.gz you meant to copy as a file gets exploded into a directory tree. The Docker official best-practice docs recommend COPY for almost all cases. Reach for ADD only when you genuinely need auto-extraction of a local tarball; for remote files prefer RUN curl or RUN wget so you can verify a checksum in the same layer.
Why use a multi-stage Dockerfile build?
A multi-stage Dockerfile has more than one FROM. Each FROM starts a fresh stage; the final image is built only from the last stage, but earlier stages are still available as named sources via `COPY --from=<stage>`. The point is to keep build-time dependencies — compilers, dev tools, package caches, the full JDK or Go toolchain — out of the shipped image. A typical pattern: use `FROM node:20 AS builder` to install dev dependencies and run `npm run build`, then `FROM node:20-alpine` and `COPY --from=builder /app/dist ./dist` to ship only the compiled output. The result is a smaller, more secure runtime image without any of the build tooling. It also makes the Dockerfile self-contained — no separate build step on a CI runner needed.

Related Tools

Docker Compose Generator

Build docker-compose.yml visually. Add services, volumes, networks, env vars — with live YAML and lint warnings.

Firewall Rule Generator

Cross-platform firewall rule builder (UFW, iptables, nftables, Windows, AWS, GCP). Also explains existing rules.

iptables to nftables

Convert iptables rules to nftables. Translates chains, NAT, conntrack, and common matchers.

Nginx Config Generator

Generate nginx.conf from form inputs. Reverse proxy, SSL, static files, load balancer, and basic auth — all common modes.

Nginx to Caddy Converter

Convert nginx server blocks to Caddyfile syntax. Maps reverse_proxy, TLS, redirects, and headers.

Need to manage SSH connections?

SSH Workbench lets you connect, browse files, and manage servers visually.

Try SSH Workbench Free