.dockerignore Cheatsheet - Docker Build Context Ignore Rules

Everything in the current directory, unfiltered. The build context is the whole tree handed to the daemon, and the only exclusions are the entries listed in .dockerignore. So a repository with no ignore rules ships its .git history, node_modules, build output, local logs and even .env — the slowdown is only the first symptom, and the real problem is that secrets end up baked into image layers: deleting the file later does not remove the layer. Start from a template covering three groups, namely dependency directories, version control metadata, and local configuration.

The trailing separator is what restricts the match to the root. tmp/ with its slash matches only the tmp directory directly under the build context root, whereas tmp without a slash matches a same-named file or directory at any depth. **/tmp states the cross-depth intent explicitly — semantically the same as the bare form — but it reads better in deeply nested projects and makes the intent obvious at a glance. Choose by intent: tmp/ for a scratch directory at the build root, and the slashless or ** form to exclude every same-named directory wherever it appears.

No. The syntaxes resemble each other but the semantics are separate: .gitignore governs version control and .dockerignore governs the build context. Docker never reads .gitignore and git never reads .dockerignore, so sharing one file leaves the other scenario with no exclusions at all. The practical difference also shows up in negation: ! re-includes previously ignored paths, but it can only resurrect something a rule already excluded — with no prior matching rule, the negation is a no-op.

Almost always because the negation sits too early, or because no preceding rule ever matched the path. Negation undoes an existing exclusion rather than explicitly including something: if .env was never excluded to begin with, !.env is a redundant line, and if a later exclusion rule covers the path again, the negation is overridden. Rules match top to bottom with later entries winning, so a negated path must come after the rule that excluded it. Remember too that negation only affects what enters the context — it does not relax what COPY may target.

Watch the context-transfer step of the build output, and cross-check the image size through its layer history. With many rules the usual failure is a pattern that looks right but anchors at the wrong depth, so the file still ships; rebuilding after each edit is far more reliable than reasoning from memory. For size, docker history shows per-layer volume and identifies which layer introduced the bulk, which you then translate back into a new rule. A solid starting set covers .git, dependency directories, local configuration, test and coverage output, and cache directories; add from there.