Pick your language, framework and extras to get a ready-to-use .dockerignore. A smaller build context means faster docker build runs, better layer caching and no secrets or node_modules copied into your image by accident.
Last updated:
1. Choose templates
Quick stacks:
2. Options
4. Your .dockerignore
Save the file as .dockerignore next to your Dockerfile, in the root of the build context (some browsers drop the leading dot when downloading, so rename it if needed). Unlike .gitignore, patterns are matched from the context root, so use **/ to match at any depth.
Advertisement
Advertisement
How to use the Dockerignore Generator
Choose a quick stack such as Next.js or Django, or click individual templates for your language, framework and extras.
Set the options: keep headers and comments for readability, or switch on allowlist mode for the tightest build context.
Add custom entries for folders specific to your project, using ! to re-include a file.
Check a path such as src/index.js or .env to confirm it is sent to the build or excluded.
Copy or download the file and save it as .dockerignore next to your Dockerfile.
.dockerignore pattern rules
Docker reads the file line by line. Lines starting with # are comments, and the last pattern that matches a path decides whether it is excluded or included.
Pattern
What it matches
node_modules
Only node_modules in the context root, and everything inside it
**/node_modules
node_modules at any depth, such as packages/web/node_modules
*.log
Log files in the root only; use **/*.log for every folder
docs/*.md
Markdown files directly in docs, not in its subfolders
temp?
temp1, tempA: ? is exactly one character other than /
*.py[cod]
.pyc, .pyo and .pyd files in the root
!README.md
Re-includes a file excluded by an earlier pattern
* then !src
Allowlist: everything is excluded except the src folder
Why a small build context matters
Speed: the whole context is transferred to the builder before the first instruction runs. A forgotten node_modules or .git folder can add hundreds of megabytes to every build.
Caching:COPY . . is rebuilt whenever any file in the context changes. Excluding logs, caches and editor files keeps that layer cached while you work.
Correctness: dependencies installed on your laptop may be built for a different operating system or CPU. Ignoring node_modules, .venv or target forces a clean install inside the image.
Security:.env files, SSH keys and cloud credentials in the context can end up in a layer that anyone with pull access can read.
Tips
Look for the "transferring context" size in the docker build output before and after adding the file to see how much it saves.
If a build fails with "file not found" after adding a .dockerignore, check the path with the checker above: a broad pattern such as build or **/*.md may exclude a file your Dockerfile copies.
Exclude Tests only if your Dockerfile does not run the test suite during the build.
Pair this file with a .gitignore for the repository, and review the Dockerfile itself with the Dockerfile Linter.
Frequently asked questions
What does a .dockerignore file do?
When you run docker build, the CLI sends the build context (usually the current folder) to the builder. Files matched by .dockerignore are left out of that context, so they cannot be copied into the image with COPY or ADD, the upload is smaller, and changes to ignored files do not invalidate the build cache.
How is .dockerignore different from .gitignore?
The syntax looks similar but matching differs. In .dockerignore every pattern is relative to the root of the build context, so node_modules only matches the top-level folder; use **/node_modules to match it at any depth. A trailing slash has no special meaning, and ! exceptions can re-include files inside an excluded folder, which .gitignore does not allow.
Should I ignore the Dockerfile and .dockerignore themselves?
You can. Docker still sends both files to the builder because it needs them, but they will not be copied into the image by COPY . . and editing them will not bust the cache of a COPY . . layer. The Docker files template does exactly this.
What is allowlist mode?
Instead of listing everything to exclude, the file starts with * to ignore the whole context and then re-includes only the paths the build needs, such as !package.json and !src. It produces the smallest possible context and prevents surprises when new files appear, but you must remember to add new folders the build uses.
Why should .env files and keys be ignored?
Anything in the build context can end up in an image layer through COPY . ., and image layers are easy to extract by anyone who can pull the image. Ignoring .env files, private keys and cloud credentials keeps them out; pass secrets at runtime or with BuildKit secret mounts instead.
Where do I put the .dockerignore file?
In the root of the build context, which is the folder you pass to docker build (the . in docker build .). With BuildKit you can also place a Dockerfile-specific file next to the Dockerfile, named after it, for example app.Dockerfile.dockerignore.
Does the path checker match Docker exactly?
It follows the documented rules: patterns are anchored at the context root, * and ? do not cross folder separators, ** matches any number of folders, a pattern that matches a folder excludes everything inside it, and the last matching line wins. Unusual edge cases can still differ, so verify critical paths with a test build.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.