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

Question

IT Interview Practice · 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.

The build context

.dockerignore — exclude unneeded files

Why it matters (three benefits)

Why it matters

Related questions