Docker Ignore Generator
Every docker build sends the build context, usually your whole project folder, to the builder. A good .dockerignore keeps dependencies, build output, Git history, logs and above all secrets such as .env files and keys out of it. Choose your stack and the generator writes the patterns, as a classic exclude list or as an allow list that only lets through what the build needs.
- Runs in your browser
- No sign-up
- Free to use
How to use Docker Ignore Generator
- Tick the languages and tools in your project.
- Choose what else to leave out.
- Pick exclude-list or allow-list style.
- Save the result as .dockerignore next to the Dockerfile.
Docker Ignore Generator features
Stack patterns
node_modules, venv, vendor, target, bin/obj and more.
Secrets excluded
.env files, keys, certificates and credentials.
Faster builds
Smaller contexts and fewer cache invalidations.
Allow-list mode
* first, then only the paths the build needs.
Grouped
Sections with comments, duplicates removed.
Explained
Notes on why each group matters.
When to use Docker Ignore Generator
- Adding a .dockerignore to a project that builds slowly.
- Making sure .env files never end up in images.
- Shrinking images that accidentally contain node_modules or .git.
- Hardening a Dockerfile before publishing an image.
Docker Ignore Generator FAQ
Why exclude node_modules or vendor?
Dependencies should be installed inside the image for its platform. Copying your local ones makes the context huge and can include binaries built for another operating system.
Why exclude .git?
The Git history can be large and contains every past version of every file, including secrets that were later removed.
What is the allow-list style?
Starting with * excludes everything, and !path lines re-include only what the build needs. New files are excluded until you add them, which is the safest approach.
Is the Dockerfile still used if it is excluded?
Yes. docker build reads the Dockerfile and .dockerignore separately; excluding them only keeps them out of COPY . instructions.
Which pattern syntax is used?
Go’s filepath.Match rules relative to the context, with ** for any number of folders and ! to re-include.
Is anything uploaded?
No. The file is generated in your browser.
Why .dockerignore matters
When you run docker build, the client packs the build context, normally the current folder, and sends it to the builder before any Dockerfile instruction runs. Without a .dockerignore, that includes dependency folders, build output, the Git history, editor settings, logs and local configuration, which makes builds slow and images larger than necessary.
It also affects caching. COPY . . copies everything in the context, so any change to any file, even a log file, invalidates the cache for that layer and every later one. Excluding files that do not belong in the image keeps the cache effective and builds fast.
The most important reason is security. Files that reach the context can end up in an image layer through COPY, and image layers are easy to inspect. A .env file, a private key or a cloud credentials file copied into an image is exposed to everyone who can pull it, even if a later layer deletes it. The secrets group excludes these files while keeping .env.example.
Stack-specific groups cover what each ecosystem produces: node_modules and package manager caches, Python virtual environments and bytecode, Composer’s vendor folder and Laravel storage contents, Go binaries, Maven and Gradle output, .NET bin and obj folders, Bundler paths and Rust’s target folder.
The allow-list style turns the logic around: exclude everything with *, then re-include the source folders and manifest files the build needs. It takes a minute longer to set up, but it never sends a new, unexpected file to the builder.