🍱 Lunchbox Hands

.dockerignore Generator

Pick your stacks and generate a curated .dockerignore file

Pick the stacks your project uses and get a curated .dockerignore — a general base (.git, env files with a !.env.example exception, editor/OS cruft, CI configs) plus per-stack sections for Node, Python, Go, Rust, Java, .NET, Ruby, and PHP. Sections are deduped and ordered consistently no matter what order you pick stacks in. Building a project already? Try the .gitignore Generator or the .editorconfig Generator next, or convert a running container's setup with the docker run → Compose converter — see the docker run to Compose guide for more. Everything runs locally in your browser.

Stacks (General base is always included)

# General
# Version control
# .dockerignore/Dockerfile can be excluded here — they are still sent to the
# builder (it needs them to run the build), they just won't be copyable into
# the image via ADD/COPY/bind mounts.
.git
.gitignore
.dockerignore
Dockerfile*

# Docs
README*
docs/
*.md

# Editor / tooling config
.editorconfig

# CI configs
.github/
.gitlab-ci.yml
.circleci/
.travis.yml

# Env files and secrets — never bake these into an image layer
.env
.env.*
!.env.example
*.pem
*.key

# Editor / OS cruft
.vscode/
.idea/
.DS_Store
Thumbs.db

# Tests / coverage (uncomment if you don't need them in the image)
# test/
# tests/
# coverage/
# *.test.*
# *.spec.*

# Node
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
.npm/
.yarn/cache/
.pnpm-store/
# dist/ and build/ are commented out by default since some setups copy a
# pre-built output into the final stage instead of building in-container.
# dist/
# build/

Frequently asked questions

Why should I ignore .git in a .dockerignore file?

The .git directory holds your full commit history, which can be large and has nothing to do with running the app. Docker's official build-context docs recommend excluding it so it never gets sent to the builder or copied into an image layer — smaller build context, faster builds, and no accidental history leakage into a shipped image.

Does .dockerignore use the same syntax as .gitignore?

Close, but not identical. Both support "#" comments, "!" negation, and "**" for matching across directory levels. The key difference, per Docker's docs, is that .dockerignore matching is done using Go's filepath.Match rules (with a filepath.Clean preprocessing step that trims whitespace and strips "." and ".." segments), rather than Git's own pattern engine. Leading and trailing slashes are disregarded, so "/foo/bar" and "foo/bar" match identically — and for negation, the last line that matches a given file wins, so you generally can't re-include a file inside a directory an earlier pattern already excluded.

Why exclude node_modules if I use a multi-stage build?

Even in a multi-stage build, the build context (everything not excluded) is sent to the Docker daemon before any stage runs, and a large local node_modules/ just slows that transfer down for no benefit — the build stage runs its own install into its own node_modules anyway. Excluding it keeps the context small and avoids ever accidentally COPYing a host-specific node_modules into an image.

Does this tool send my file structure anywhere?

No. This is a static picker — nothing about your project is read or uploaded. The generated .dockerignore is built entirely from the templates you select, in your browser, and never leaves your machine.

Get weekly dev tools and tips