.dockerignore and a Small Context

When you run docker build ., that directory becomes the build context — the set of files the builder is allowed to read. A .dockerignore file is the allow/deny list that keeps that context small: it stops .git, node_modules, local virtualenvs, and stray secrets from being sent to the builder and, worse, from being swept into the image by a careless COPY . ..

It is the cheapest fix in this chapter and the one most often skipped. One file beside the Dockerfile saves a slow context upload and closes the most common secret-leak path in a single move.

What the Build Context Is

The build context is the directory you point docker build at, and its files are what the builder is allowed to pull in. BuildKit — today's default builder — sends only the files the build actually needs and reuses unchanged files between builds, rather than tarring up the whole directory and uploading all of it on every build the way the legacy builder did. But the context still defines what is available: leave a 400 MB .git history and a local node_modules in scope and a careless COPY . . sweeps all of it into the image, while large unignored files still cross the wire. The context is what you expose to the build, not the subset the Dockerfile happens to reference.

.dockerignore Syntax and Behavior

.dockerignore sits beside the Dockerfile and uses gitignore-style patterns — **/__pycache__, .git, *.env, node_modules — to exclude paths from the context entirely. An excluded file cannot be COPY'd, because the daemon never receives it in the first place. The exclusion happens at the boundary, before the build sees anything, which is what makes it both a speed and a security control.

.git
.venv
__pycache__
**/__pycache__
*.pyc
*.env
.env
tests/fixtures
node_modules

Each line drops a path from the tar the daemon receives. The patterns mirror the things that are large, machine-specific, or sensitive — version history, the local virtualenv, byte-compiled caches, and any environment file that might hold a credential.

The Secret-Leak Path

Without .dockerignore, a COPY . . happily bakes .env, the full .git history with any committed secrets, SSH keys, and cloud credentials into a layer. docker history and a layer extraction then hand all of it to anyone who pulls the image. The file is the primary defense against the "I copied my whole repo into the image" leak — the kind that surfaces months later when someone scans a published image and finds an active token in a layer.

Smaller Context, Faster Builds

A lean context uploads faster and keeps BuildKit's cache valid. If node_modules is in the context, touching one dependency changes the context hash and can invalidate cache that should have held — BuildKit cannot tell the relevant change from the irrelevant one when both are in the same tar. Excluding the noise means the context hash only moves when something the build actually copies has moved.

The Driftwood Context

Driftwood's .dockerignore excludes .git, .venv, __pycache__, *.pyc, .env, and the test fixtures, so the context sent for the multi-stage build is the source tree and requirements.txt only. The developer's local .venv never reaches the daemon, which matters doubly: it would otherwise be copied over the freshly built one and ship a machine-specific dependency tree on top of the wheels the builder stage just compiled.

The result is a context measured in a few megabytes instead of the hundreds the bare repo would send, with no credential file anywhere in it — the multi-stage build of topic 28 fed a clean, small input.