Always use a .dockerignore in your projects

This is one of those posts that really should not need to exist. The fact that it does means it is still necessary. At MarsBased, as a development agency, this is something we have encountered far too many times. Unfortunately, it is something we still run into today when new projects land on our desks: the lack, or misuse, of .dockerignore files.

The importance of the .gitignore analogy

Most engineers and developers know that, in any code repository, having a proper .gitignore file is essential. As you all know, .gitignore files are used to prevent certain files, usually specific to a developer's local environment, from being tracked and pushed to remote Git repositories like GitHub or GitLab. They also help avoid leaking credentials or other sensitive information that should never be committed.

.dockerignore files serve a similar purpose, but for Docker builds. They define which files are excluded from the Docker build context. Any file that is ignored will never be sent to the Docker daemon and therefore cannot be included in the image through ADD or COPY instructions.

Understanding the impact in practice

In many projects, not having a .dockerignore file does not seem like a big issue at first. At worst, it may cause some local annoyances when building images, such as accidentally copying folders that should not be there. In practice, the impact can be much bigger.

Even when Docker images are built exclusively in CI/CD pipelines, the entire build context is still sent to the Docker daemon. Without a proper .dockerignore, this can lead to unnecessarily large build contexts, slower builds, broken layer caching, and higher resource usage in CI environments.

Security risks and local builds

And while, in theory, Docker images should never be built on a developer's local machine, reality is often different. We still see companies that use Docker but build images locally. Sometimes this is due to cost constraints. Sometimes it is caused by security policies, VPNs, or compliance requirements that prevent CI/CD tools from accessing private Docker registries. There are plenty of valid reasons why this still happens.

The real problem is that without a proper .dockerignore file, anything in your project directory can end up in the build context: credentials, secrets, database dumps, local configuration files, or temporary artifacts. Even if those files are not explicitly copied into the final image, they are still sent to the Docker daemon, and mistakes in the Dockerfile can easily turn this into a data leak.

Our commitment to best practices

For this reason, we have included .dockerignore files in our internal project templates for a long time, and we actively advocate for their use in our guides and blog posts.

Now it is your turn. This is a good opportunity to review your projects and make sure every single one of them has a well defined .dockerignore file.