.dockerignore Generator

Build a .dockerignore file by ticking the stacks you use. Excluding node_modules, build output, version-control directories, secrets, and editor files keeps them out of the build context Docker sends to the daemon — which makes builds faster, images smaller, and stops credentials from leaking into a layer. Pick presets, get a ready-to-commit file.

.dockerignore

How to use the .dockerignore Generator

Tick every stack that applies to your project — they combine, so a Node frontend with a Python service can use both. The General preset (version control, OS junk, editor files, and secrets) is on by default and is worth keeping for almost every image. The file regenerates as you toggle, with duplicate patterns removed, then copy it to a .dockerignore at the same level as your Dockerfile.

Review the result before committing. A few patterns depend on your build: if your image is built from compiled output you produce inside the Dockerfile, ignoring dist/ is correct; if you copy a pre-built artifact in, remove that line. The goal is to exclude everything Docker does not need to read, while keeping what your build genuinely copies.

What .dockerignore does

When you run docker build, the client first packages the build context — by default the entire directory you point it at — and sends it to the Docker daemon. A .dockerignore file, placed at the root of that context, lists patterns to leave out, exactly as .gitignore excludes files from Git. Anything matched is never sent, so it cannot be read by a COPY or ADD instruction and never ends up in the image.

This matters for three reasons. Speed: a context bloated with node_modules, .git history, or build caches can be hundreds of megabytes, and all of it is transferred and hashed on every build. Image size and cache stability: a broad COPY . . that pulls in junk creates large, frequently-invalidated layers. Security: without exclusions a stray .env, private key, or cloud-credentials file can be copied straight into a published image, where anyone who pulls it can extract it.

The pattern syntax mirrors .gitignore: one glob per line, * matches within a path segment, ** spans directories, a leading ! re-includes something a previous line excluded, and # begins a comment. A well-tuned .dockerignore is one of the cheapest wins in a Docker setup — a few lines that shrink the context, harden the image, and speed up every build.

Common use cases

  • New Dockerfiles. Start a project with a sensible exclude list instead of shipping junk.
  • Shrinking build context. Stop sending node_modules and .git to the daemon on every build.
  • Preventing secret leaks. Keep .env files and keys out of published images.
  • Polyglot repos. Combine presets for projects that mix several languages.

Frequently asked questions

Where does the .dockerignore file go?
At the root of the build context — normally the same directory you pass to docker build, which is usually where your Dockerfile lives. Docker looks for a file named exactly .dockerignore there and applies it before building.

Is the syntax the same as .gitignore?
Almost. Both use glob patterns, # comments, and a leading ! to re-include. Docker additionally supports ** to match across directories and matches patterns against the whole context path, so the two files are similar but not identical.

Will ignoring dist/ break my build?
Only if your build copies a pre-built dist/ from the host. If the image compiles the code itself, ignoring dist/ is correct and avoids stale output. Adjust the build-output lines to match how your Dockerfile produces artifacts.

Does excluding files reduce image size?
Indirectly but significantly. Excluded files are never available to COPY, so they cannot be added to a layer. A tight ignore list also keeps COPY layers small and their cache stable, which speeds up rebuilds.

Can I re-include a file that a pattern excludes?
Yes. A line beginning with ! re-includes a path that an earlier pattern matched, for example ignoring *.log but keeping !important.log. Order matters: the last matching pattern wins.