Dockerignore Generator

DevOps engineers watching multi-gigabyte build contexts upload on every deploy, security reviewers finding .env files inside production images, and developers copying a half-remembered .gitignore into a Dockerfile project all need a proper .dockerignore. This generator assembles exclude files from curated groups for Node, Python, Go, secrets, VCS, and OS junk, with custom lines and negation exceptions layered on top. The output is ready to commit beside your Dockerfile so secrets and caches never enter the build context.

Quick presets

Pattern groups

Custom patterns (one per line)

Exceptions (negation, one per line)

.dockerignore

How the Generator Builds Exclusion Files

Each group is a named list of patterns curated for one ecosystem: version-control directories, editor metadata, OS junk, secret-shaped files, and language-specific caches for Node, Python, and Go. Selecting a group copies its patterns into the output under a comment banner. Custom lines are appended next, then negation exceptions, each prefixed with ! when you forget it. The header comment reminds whoever reads the file that the last matching rule wins.

Pattern matching follows Docker's filepath.Match rules with ** support for recursive globs. Excluding node_modules stops the CLI from hashing millions of package files on every build. Excluding .env and *.pem keeps credentials out of the image even when a wildcard COPY pulls a whole directory. The stats counter shows how many active patterns the file carries so you can see the scope before committing.

Last match wins (unlike gitignore)

In .gitignore the first matching line decides the result. In .dockerignore the last matching line decides, so a negation at the bottom can re-include a file that a broad exclude earlier removed. Put the general excludes first and the ! exceptions last, otherwise the exception silently does nothing.

Keep what COPY needs

Multi-stage builds often COPY dist/ or target/ from a builder stage into a slim runtime stage. If .dockerignore removed those folders from the context, the COPY fails. When you check a build-artifacts group, confirm the Dockerfile still has every path it copies, or add a negation for the artifact directory only.

Before and after: shrinking a Node build context

Before (no .dockerignore)

# build sends everything, including:
# node_modules (400MB), .git, .env, coverage
docker build -t app .

After (generated groups + exception)

# Generated by FlowStack Tools Dockerignore Generator
# Rules are matched top to bottom; the last matching rule wins.

# Version control
.git
.gitignore

# Secrets & credentials
.env
.env.*
*.pem

# Node.js
node_modules
npm-debug.log*
coverage
.next

# Exceptions (last match wins, so these override earlier excludes)
!.env.example

Use Cases

Developer	Production	Workflow
Stop .env files from landing in production images	Cut context upload time on a large monorepo	Standardize dockerignore across a service fleet
Exclude node_modules before a multi-stage COPY	Keep private keys and certs out of registry layers	Review a PR that adds new COPY instructions
Re-include .env.example with a negation rule	Shrink BuildKit cache invalidation frequency	Pair with Dockerfile linter in a pre-commit hook

Common Mistakes and Troubleshooting

The most frequent failure is excluding a directory the Dockerfile copies, which surfaces as a build error naming the missing path. The second is treating .dockerignore like .gitignore and expecting the first match to win, so a bottom negation appears to be ignored. The third is forgetting that .dockerignore only affects the build context sent by the CLI, not files added later with docker cp or mounted at run time.

When a pattern seems to do nothing, confirm the file is named .dockerignore exactly and sits in the context root. When Compose builds from a subdirectory, the context key in docker-compose.yml decides where Docker looks for the file. If secrets still appear in an image, check earlier layers — excluding a file from a new build does not remove it from a cached layer built before the exclude existed.

Best Practices for Build Context Hygiene

Start every project with VCS, secrets, and OS groups enabled, then add the language group that matches the stack. Re-include .env.example and other placeholder files with negation lines at the bottom. Keep artifact directories you COPY, exclude the caches you do not. Revisit the file when the Dockerfile gains new COPY instructions, and run the Dockerfile linter afterwards to catch ENV secrets that no exclude file can hide.

Pair this generator with the Dockerfile generator for the matching build file, the docker-compose generator for multi-service builds, the gitignore generator for the parallel Git exclusions, the env-file-validator for the .env files you are excluding, and the git command generator to commit the new file with a clear message.

Dockerignore Generator FAQ

What is the difference between .dockerignore and .gitignore?

.gitignore controls what Git tracks; .dockerignore controls what the Docker CLI sends to the daemon as build context. A file can be committed to Git and still be excluded from the image, and the reverse is also possible. Secrets like .env should usually appear in both files, while dist/ might be gitignored but still copied into a runtime image on purpose.

Where does the .dockerignore file go?

Place it next to the Dockerfile at the root of the build context, or next to the docker-compose.yml when Compose builds the image. Docker looks for a file named exactly .dockerignore in the context root; there is no per-stage location. When several Dockerfiles build from different roots, each context needs its own file.

Why does excluding a directory break my build?

If a COPY or ADD instruction needs a path that .dockerignore removed, the build fails with "file not found in build context". The most common case is excluding dist/ or build/ and then copying those folders into a slim runtime image. Keep the artifact directories you actually COPY, and exclude only the caches and sources that the Dockerfile never reads.

Do negation patterns work in .dockerignore?

Yes. Lines starting with ! re-include a path that an earlier rule excluded, and the last matching rule wins, which is the opposite of .gitignore semantics where the first match wins. A typical pattern is excluding *.env globally and then adding !.env.example so template files still reach the image.

Does .dockerignore affect Docker layer caching?

Indirectly, yes. The build context hash includes every file sent to the daemon. Excluding node_modules, .git, and test output shrinks that context, speeds up the upload, and stops irrelevant files from changing the context hash and invalidating cache mounts. Large excluded directories are one of the cheapest build-speed wins available.

What should always be excluded from the build context?

Secrets first: .env files, private keys, .npmrc with tokens, and certificate files. Then bulky non-inputs: .git, node_modules, virtualenvs, IDE metadata, and OS junk like .DS_Store. Finally anything the Dockerfile never COPYs — docs, test reports, and CI output that only inflate the context transfer.

Is the generated file uploaded anywhere?

No. The generator assembles the text in the browser from the groups and custom lines you select. Nothing is stored or transmitted; copy the result and commit it beside your Dockerfile.