What is the build context, and what does .dockerignore do?
Quick Answer
The build context is the set of files sent from your machine to the Docker daemon when you run docker build — by default, every file in the directory you specify (commonly .), which the daemon needs in order to satisfy any COPY/ADD instructions. .dockerignore excludes specified files/patterns from that context entirely. This speeds up the build (less data transferred and hashed) and prevents accidentally including sensitive or unnecessary files — like .git, node_modules, or .env — in what's sent to the daemon or copied into the image.
Detailed Answer
What the build context actually is
docker build -t myapp .
That trailing . isn't just "look at the Dockerfile here." It specifies the build context: the entire directory tree Docker packages up and sends to the daemon before the build even starts. Any COPY/ADD instruction in the Dockerfile can then reference files from it. This matters even for a remote daemon — the whole context genuinely gets transferred over the network to wherever the daemon is running, not just referenced by path.
Sending build context to Docker daemon 245.7MB
This line prints at the start of every docker build, and it's worth paying attention to. A surprisingly large number here is a strong signal that unnecessary files are being included and transferred — an entire node_modules directory, a .git history, or large data files unrelated to the application.
.dockerignore — excluding files from the context
# .dockerignore
.git
node_modules
npm-debug.log
.env
*.md
Dockerfile
.dockerignore
This works like .gitignore. Patterns listed here are excluded from what gets sent as the build context at all — not just "not copied into the image," but genuinely never sent to the daemon in the first place.
Why this matters for more than just speed
Performance. A smaller context transfers faster, especially for a remote daemon or CI environment, and reduces the daemon's own overhead scanning and hashing the context for caching.
Avoiding accidental inclusion of sensitive data. A broad COPY . . instruction copies everything in the build context that isn't excluded. Without a .dockerignore excluding .env, a local secrets file, or .git, a careless COPY . . can bake credentials directly into an image layer. This is especially risky for .git, since it can hold historical commits with sensitive data even if the current working tree doesn't. Image layers are effectively permanent once built and pushed — removing a file in a later layer doesn't remove it from the earlier layer's stored data. So a leaked secret baked into an early layer is extremely hard to fully scrub, even if a later commit or layer "deletes" it.
COPY . . # without a .dockerignore, this could copy .env, .git, and other sensitive/unnecessary files
Avoiding cache invalidation from irrelevant files. COPY's cache key depends on the actual content of copied files. If .git or build artifacts are part of the context and change on every build, even without meaningful application changes, they can cause unnecessary cache invalidation for instructions that copy broad directories. Treat an unexpectedly large "Sending build context" number as a signal to check .dockerignore, not something to ignore.