The .dockerignore File: Keep Your Build Context Lean

WHY IT EXISTS: When you run docker build, the Docker client archives your project directory (the "build context") and sends it to the Docker daemon. Without a way to filter this, you'd send everything—large dependency folders, secret keys, and version control history—making builds slow and insecure.

THE MENTAL MODEL: It's .gitignore for Docker. It's a simple text file that lists files and directories you want to exclude from the build context. The Docker daemon never even sees the files you ignore, resulting in faster, more secure builds.

HOW IT WORKS: Before a build begins, the Docker client looks for a .dockerignore file in the root of the build context. It reads the patterns in this file, which use a glob syntax similar to shell commands (e.g., *.log, temp/). It then creates the build context archive, omitting any files or directories that match these patterns. This smaller, cleaner archive is then sent to the daemon. You can even use ! to create exceptions to exclusion rules.

WHEN TO USE IT: Use it in every Docker project. It's essential for excluding: dependency directories like node_modules or vendor; build artifacts like dist or target; local environment files like .env; version control folders like .git; and any logs or temporary files. This keeps your build context small, your builds fast, and your final image secure.

WHEN NOT TO USE IT: It is almost never correct to omit a .dockerignore file. The only conceivable scenario is a "hello world" project with only a Dockerfile and one other file in the directory. Even then, adding one is good practice for forming good habits.

ONE CANONICAL EXAMPLE: A typical .dockerignore file for a Node.js project might look like this. It ignores the .git directory, log files, the massive node_modules folder, and local environment secrets.

.git npm-debug.log node_modules .env