VocalHyre
Sign up

Docker · Containers in practice

What does .dockerignore do and what should go in it?

Mediumdockerignorebuild contextsecurityUpdated Oct 2026
Quiz this track

Short answer

.dockerignore excludes files from the build context before they are sent to the builder. It speeds up builds and prevents secrets, dependencies and VCS data from being copied into images.

The file uses patterns similar to .gitignore. Anything matched is not sent to the daemon, so it cannot be copied by COPY or ADD and does not bloat the context. Excluding node_modules is especially important because it is large and should be rebuilt inside the image for the target platform.

text
node_modules
.git
.gitignore
dist
coverage
*.log
.env
.env.*
!.env.example
Dockerfile
README.md
Exclude local secrets and build output, but keep files the image genuinely needs.

What belongs there

  • Dependency directories that are installed inside the build
  • Version control metadata and editor settings
  • Local environment files and credentials
  • Test output, coverage reports and logs
  • Documentation that is not needed at runtime

Be careful with broad patterns. Excluding everything and then re-including a few paths is error-prone; prefer explicit exclusions. Also confirm that a required file is not excluded, which shows up as a confusing COPY failure.

.dockerignore does not remove a file from a layer if an earlier build already copied it. It only prevents the file from entering the context.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Does .dockerignore affect COPY --from in a multi-stage build?
  2. 2What happens if you exclude a file that the Dockerfile copies?
  3. 3Why is excluding .env not enough on its own?
  4. 4How do ignore patterns interact with negation?

Say it in the interview

The .dockerignore file filters the build context, so matched files are never sent to the builder. I exclude node_modules, .git, build output, logs and local env files. That keeps builds fast and stops secrets or local artifacts from being copied into an image. I keep the rules explicit, because a broad ignore can also break a COPY the build depends on.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

MediumWhat is the Docker build context and why does it matter?EasyHow do you write a Dockerfile?HardHow do you handle secrets in Docker builds and at runtime?

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Docker mock interview and get scored feedback on depth, clarity and confidence.

Start a free Docker interviewBrowse all questions