Build Dockerfiles visually — choose base images, configure stages, add directives, and generate production-ready Dockerfiles with best-practice hints.
Exec form (recommended): ["executable", "param1", "param2"]
FROM node:20-alpine WORKDIR /app
A Dockerfile is a plain-text recipe that tells docker build how to assemble a container image, instruction by instruction. Each line — FROM, RUN, COPY, ENV, EXPOSE, CMD — creates or modifies a filesystem layer, and the stack of layers becomes your image. Because layers are cached and reused, instruction order matters as much as content: a well-ordered Dockerfile rebuilds in seconds, a badly ordered one reinstalls every dependency on each code change.
Start from a preset — Node.js, Python, Go, static Nginx site, or PHP — or build from scratch. Pick a base image and tag, add environment variables, build args, RUN commands, COPY entries, ports, volumes, a USER, and CMD or ENTRYPOINT through form fields, and add extra stages for multi-stage builds. The Dockerfile preview updates live, with inline best-practice hints, and everything runs in your browser — nothing is uploaded.
Usually three causes: a fat base image, build tools shipped in the final image, and forgotten files. Switch from ubuntu or node to alpine or slim variants — node:20-alpine is roughly a tenth the size of node:20. Use a multi-stage build so compilers and node_modules used for building never reach the runtime stage. Add a .dockerignore excluding .git and node_modules, and run docker history my-image to see exactly which layer is bloated.
COPY does one thing: copy files from the build context into the image. ADD does that plus two magic behaviors — it auto-extracts local tar archives and can fetch remote URLs. That magic causes surprises (an archive you wanted copied intact gets unpacked, a URL download skips checksum verification), so Docker's own best-practice guide says to prefer COPY everywhere and use ADD only when you explicitly need tar extraction.
ENTRYPOINT defines the fixed executable a container runs; CMD supplies default arguments that users can override. With ENTRYPOINT set to a wrapper script and CMD set to your app command, docker run my-image bash replaces only the CMD part. If you set just CMD, the whole command is replaceable at run time. Use the exec (JSON array) form for both so signals like SIGTERM reach your process directly instead of a shell.
Docker invalidates the cache at the first changed instruction, and every instruction after it rebuilds. The classic mistake is COPY . . before installing dependencies — any source edit then re-runs the full install. Copy your manifest first (package.json, requirements.txt, go.mod), run the install, and copy the rest of the source afterward; this generator hints when it spots that pattern. When you suspect a stale layer, force a clean rebuild with docker build --no-cache.
No — processes in a container run as root by default, so a container escape or application exploit lands with root privileges on shared kernel resources. Add a USER directive pointing at an unprivileged account, such as the built-in node user in Node images or a UID like 1001 created with adduser in a RUN step. The generator flags stages that define a CMD without a USER, and ports below 1024 are the usual casualty — bind to 3000 or 8080 instead.