Dockerignore Generator

Pick your stack and copy a ready exclude list into your build context directory.

Secure (SSL)

Client-Side Processing

100% Free

Go to tool

Instructions

1

Enter data
Enter content, paste text or load a file from disk.
2

Click the button
The tool will immediately process your data in the browser.
3

Get the result
Copy the finished text or save the file to your device.

                                                function runTool() {

                                                  return "Result ready in 0.1s";

                                                }

What to exclude from the context

Node.js

PHP

Python

Git

Secrets

Editors

Documentation

System files

Pick the technologies and click "Generate .dockerignore".

Rate this tool:

Related tools

Other tools you may find useful

Dockerignore generator - a smaller build context and a shorter build

The dockerignore generator assembles an exclude list from ready-made blocks: dependencies, the Git directory, secrets, CI files, editor settings, documentation and operating system leftovers. Select the technologies your project uses, copy the result into your build context directory, and stop shipping megabytes to the Docker daemon that never end up in the image.

What the build context is

The docker build . command first packs the directory you point it at and sends it to the daemon as the build context. Only then do the instructions in the Dockerfile run. If that directory holds node_modules, vendor and the full repository history, every build starts with tens of seconds of pushing files the image does not need. A .dockerignore file works exactly at this stage: it filters the context before anything reaches the daemon.

What is worth excluding

Group	Sample patterns	Reason
Dependencies	`node_modules`, `vendor`, `.venv`	Installed inside the image from the lock file
Version control	`.git`, `.gitignore`	Repository history is often heavier than the source itself
Secrets	`.env`, `.pem`, `.key`	Image layers are readable by anyone who pulls them
CI and tooling	`.github`, `Dockerfile`, `docker-compose.yml`	A pipeline tweak should not invalidate the application cache
Documentation and tests	`docs`, `tests`, `*.md`	Dead weight in a production image
System and temporary files	`.DS_Store`, `Thumbs.db`, `*.log`	Local artifacts that differ on every machine

How to use the generator

Select the tiles that match your project stack. You can combine several, for example PHP and Node.js for a Laravel app with a Vite frontend.
Click Generate .dockerignore. Patterns that repeat across groups appear in the output only once.
Copy the contents and save them as .dockerignore in the directory you pass as the build context.
Run docker build . and compare the Sending build context to Docker daemon line before and after.

The same project usually needs a list of files Git should skip as well, and the gitignore generator produces it with very similar syntax. When you ship the image to a cluster the Kubernetes Deployment manifest generator comes in handy, and on classic hosting so does the .htaccess file generator. The syntax of the accompanying docker-compose.yml can be checked with the YAML validator.

Pattern syntax and differences from .gitignore

Patterns are always matched against the root of the context, not against the directory that holds the file. That is the first meaningful difference: in Git every subdirectory can carry its own .gitignore, while Docker only reads the .dockerignore at the context root. A single asterisk replaces part of a name within one path segment, a double asterisk crosses any number of directories, so **/*.log covers logs at every level. An exclamation mark creates an exception, and on conflict the last matching line wins, which is why *.md on one line and !README.md on the next keeps the README in the context.

What not to exclude

Dependency lock files have to stay in the context. If you exclude package-lock.json or composer.lock, then npm ci and composer install have nothing to work from, and the build either fails or installs different library versions than the ones you tested.

The documentation group excludes tests and *.md. That is a sound default for a production image, but if you run tests inside the image or your composer.json maps the test directory through autoload-dev, drop that pattern from the output.

Layer cache and the order of copying

You gain the most by combining .dockerignore with a sensible instruction order: dependency manifests first, then the install, then the source:

COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

The npm ci layer then stays in cache until the manifests change. Without a .dockerignore this layout gains little, because the local node_modules lands in the context and invalidates the COPY . . layer on every package install.

Frequently asked questions

Does .dockerignore work like .gitignore?

The syntax is very close: the same wildcards, directories and exclamation mark for exceptions. There are two differences. Docker reads a single file, at the context root. And there is no notion of a tracked file here, so a change to the patterns applies from the very next build.

Should I exclude the Dockerfile from the context?

You can, and it is a common choice. Docker reads the Dockerfile separately, before the context is packed, so excluding it does not break the build. What you gain is that a small edit to the Dockerfile or to the Compose files no longer invalidates the COPY . . layer.

Does .dockerignore make the final image smaller?

Indirectly, but noticeably. The file itself removes nothing from the image; it decides what may be copied in the first place. With a COPY . . instruction everything that was not excluded goes into the layer, and excluding .git plus node_modules is usually a few hundred megabytes saved.

Can one file serve several Dockerfiles?

By default yes: one .dockerignore at the context root covers the whole context. BuildKit lets you keep separate lists though, and a file named YourDockerfile.dockerignore next to a given Dockerfile takes precedence for builds started with that file.

Does .dockerignore protect secrets?

Only as prevention. It blocks an accidental copy of .env or private keys through COPY . ., but it will not help if you name the file explicitly, and it removes nothing from the layers of an image that already exists. Pass credentials as environment variables at run time or through the BuildKit secrets mechanism, and if a key ever reached a published image, treat it as disclosed and rotate it.