What is the build context and why use a .dockerignore file?

Question

Accepted Answer

When you run `docker build`, Docker sends the **build context** (the files in the build directory) to the daemon. A **.dockerignore** file excludes unneeded files from this context — speeding builds, reducing image size, and avoiding leaking sensitive files.

## The build context

```bash
docker build -t myapp .     # the "." is the build context — the directory sent to the daemon
# → Docker tarballs the ENTIRE context directory and sends it to the daemon BEFORE building
# → a big context (node_modules, .git, large files) = slow builds, more data transferred
```

The **build context** is the set of files Docker sends to the daemon to build the image. Everything in the build directory is included unless excluded — so a bloated context slows every build.

## .dockerignore — exclude unneeded files

```text
# .dockerignore (like .gitignore, for the build context)
node_modules        # don't send local deps (they're installed in the image anyway)
.git                # don't send version history
*.log
.env                # ⚠️ don't send SECRETS into the build context/image
Dockerfile
dist
.vscode
```

`.dockerignore` works like `.gitignore`, excluding files from the build context.

## Why it matters (three benefits)

```text
✓ FASTER builds — a smaller context transfers faster; fewer files to process
  (also helps caching: COPY . . won't be invalidated by irrelevant file changes)
✓ SMALLER images — excluded files (node_modules, .git) don't get COPYed into the image
✓ SECURITY — keep SECRETS (.env, keys, credentials) out of the context AND the image
  (a COPY . . could otherwise copy a .env file into the image — a real leak risk)
```

## Why it matters

Understanding the build context and `.dockerignore` is valuable for **efficient and secure Docker builds**, so it's practically useful knowledge.

Many developers don't realize that `docker build .` sends the **entire build-context directory to the daemon** before building — so a bloated context (containing `node_modules`, `.git`, build artifacts, large files) makes **every build slower** (more data to transfer and process) and risks copying unwanted files into the image.

The **`.dockerignore`** file (working like `.gitignore`) addresses this with three concrete benefits: **faster builds** (a smaller context transfers and processes faster, and also improves layer caching since `COPY . .` won't be invalidated by changes to irrelevant files), **smaller images** (excluded files don't get copied in — e.g. not bundling local `node_modules` that get reinstalled anyway), and crucially **security** (keeping **secrets like `.env` files, keys, and credentials out of the build context and image** — since a `COPY . .` would otherwise copy a `.env` into the image, a real and common credential-leak risk).

This security benefit is particularly important, as accidentally baking secrets or sensitive files into images via an over-broad copy is a genuine mistake `.dockerignore` helps prevent.

Since builds happen constantly and build efficiency, image size, and avoiding secret leaks all matter, and since understanding the build context and using `.dockerignore` directly improves all three, understanding the build context and `.dockerignore` is valuable, practically-relevant Docker knowledge — a simple but important practice for fast, lean, and secure builds that's easy to overlook yet meaningfully impactful, especially for preventing the accidental inclusion of secrets in images.