Dockerfile Builder
Generate production-ready Dockerfiles with multi-stage builds, .dockerignore, and companion Compose — all in your browser.
Examples
Default Node.js multi-stage build with healthcheck
Runtime: node
Version: 20-alpine
Stages: builder (npm ci --only=production)
final (copy from builder, expose 3000, node server.js)
Healthcheck: on
Env vars: (none)# Builder stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json .
RUN npm ci --only=production
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/ .
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 CMD ["curl", "-f", "http://localhost:3000/health", "||", "exit", "1"]
RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001
USER nodejs
CMD ["node", "server.js"]The two stages are emitted in order: the `builder` runs `npm ci --only=production`, and the `final` stage copies the installed `node_modules` from the builder with `COPY --from=builder /app/ .`. The healthcheck is rendered with each command token as a separate JSON-string array element so the shell doesn't have to parse it.
With environment variables in both files
Runtime: node
Env vars: NODE_ENV = production
PORT = 8080
Healthcheck: offDockerfile:
...
ENV NODE_ENV=production
ENV PORT=8080
...
docker-compose.yml:
version: "3.8"
services:
app:
build: .
ports:
- "3000:3000"
environment:
- NODE_ENV=production
- PORT=8080Each env var is emitted as a separate `ENV KEY=VALUE` line in the Dockerfile and as a `- KEY=VALUE` entry under the compose `environment:` list. The compose service uses the final stage's EXPOSE value (3000) for the host:container mapping — even though PORT=8080 is the application-level port, EXPOSE in the Dockerfile is the listening port.
Companion docker-compose.yml with healthcheck
Runtime: node
Healthcheck: onversion: "3.8"
services:
app:
build: .
ports:
- "3000:3000"
environment:
- NODE_ENV=production
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health", "||", "exit", "1"]
interval: 30s
timeout: 3s
retries: 3The compose file uses the same healthcheck command, reformatted as the compose `healthcheck.test` array. `interval`, `timeout` and `retries` mirror the Dockerfile flags so the container is marked unhealthy the same way by both schedulers.
About this tool
The Dockerfile Builder generates production-ready Dockerfiles for nine runtimes — Node.js, Python, Go, Rust, Ruby, Java, Deno, Bun, and static Nginx — with multi-stage builds, environment variables, a healthcheck, and a non-root user all pre-wired. Pick a runtime and a base image, edit the build stages to match your project, and the tool emits both a Dockerfile and a matching docker-compose.yml.
Every preset ships a sensible default stage layout: a `builder` stage that installs dependencies and (where relevant) compiles the application, and a `final` stage that copies the build artefacts into a smaller runtime image. The builder writes the COPY, RUN, ENV, EXPOSE, HEALTHCHECK, USER and CMD directives in the correct order so the Dockerfile is ready to build with `docker build` as soon as you copy it.
The compose output is intentionally minimal: a single `app` service that builds from the current directory, maps the exposed port to the host, applies the environment variables, and adds the healthcheck if you enabled one. Both files can be downloaded separately or copied to the clipboard, so you can paste the Dockerfile into one repo and the compose file into another without retyping the port or env values.
How to use
Choose a runtime and base image
Pick a runtime (Node, Python, Go, …) and a base image version. The default stages are populated automatically with the right WORKDIR, default port, and default CMD for that runtime.
Edit the build stages
Add COPY paths, RUN commands, base images, and the WORKDIR for each stage. The final stage is fixed at the end of the list and carries EXPOSE, CMD, and the optional non-root user.
Add environment variables and a healthcheck
Click + to add KEY/value pairs under Environment Variables. Toggle the healthcheck option to add a HEALTHCHECK directive that runs `curl` against the exposed port.
Copy or download the generated files
Switch between the Dockerfile and docker-compose.yml tabs to copy or download each one separately.
Use cases
Producing a first Dockerfile for a new Node or Python service
Pick the runtime, set the base image tag, and the tool emits a clean multi-stage build with the right WORKDIR, default port and a non-root user — paste it next to your package.json and `docker build` works.
Scaffolding a dev compose file alongside a Dockerfile
The matching compose output is one click away — useful when a teammate just wants `docker compose up` to bring the service up without you hand-writing the build context and the port mapping.
Adding a healthcheck to an existing service
Toggle the healthcheck option and the tool emits both the Dockerfile `HEALTHCHECK` directive and the matching compose `healthcheck:` block, with the same command, interval, timeout and retries so the two stay in sync.
Documenting a runtime baseline in a design system
Generate the Dockerfile for a runtime, copy the rules into a `Dockerfile.template` in the repo, and update the base image tag in one place whenever you cut a new release.
Common mistakes
Mistake:Forgetting to update the base image tag when a new version is released.
Fix:Base image tags are pinned explicitly (e.g. `node:20-alpine`, not `node:latest`) so builds are reproducible — but you must bump the tag yourself when you want to adopt a new release. Re-select the version in the dropdown to update every stage at once.
Mistake:Putting secrets into `ENV` lines and shipping the image publicly.
Fix:ENV values are baked into image layers and visible in `docker history`. The builder exposes them as `ENV` for the convenience case; for anything sensitive, use Docker secrets, a mounted file, or a runtime config loader (e.g. `--env-file`).
Mistake:Skipping the non-root user on a service that handles untrusted input.
Fix:The default final stage runs `USER nodejs` for every non-Nginx runtime. Removing it means a container escape lands the attacker as root inside the container — leave it on for anything that touches user data.
Mistake:Writing the CMD as a string instead of a JSON array.
Fix:`CMD node server.js` is passed to `/bin/sh -c`, which means signals are not forwarded and a complex command won't survive being overridden. The builder always emits `CMD ["node", "server.js"]` (exec form) so PID 1 is your process and signals work.
Frequently asked questions
Related guides
References & standards
Related tools
CHANGELOG Generator
Write a clean, consistent CHANGELOG entry in the Keep a Changelog format from grouped Added, Changed, Deprecated, Removed, Fixed, and Security notes
Chmod Calculator
Calculate Linux file permissions (777, 755 etc) easily.
Credit Card Validator
Validate credit card numbers with the Luhn algorithm and detect the issuing network
Cron Expression Builder
Build and validate cron expressions with visual interface and presets
CSS/JS Minifier
Minify your CSS and JavaScript code to reduce file size.
Database Connection String Builder
Build and URL-encode connection strings for PostgreSQL, MySQL, MongoDB, Redis and SQLite from a simple form — with JDBC and key/value variants