Why is a .dockerignore important for security?

Without it, docker build sends your entire directory into the image build context, and a careless COPY . . can bake your .env file, .git history, SSH keys, and cloud credentials straight into an image layer - where anyone who pulls the image can extract them, even if you delete the file in a later step. A .dockerignore excludes those files from the context entirely, so they can never end up in the image. It is one of the highest-value, lowest-effort things you can add to a Docker build.

Does it also make images smaller and builds faster?

Yes. Excluding node_modules, virtualenvs, build output, .git, and test fixtures shrinks the build context that gets sent to the Docker daemon, which speeds up builds and avoids copying huge, unnecessary directories into the image. Smaller context, faster builds, smaller images.

Should .dockerignore match .gitignore?

They overlap but are not the same. .gitignore controls what is committed; .dockerignore controls what enters the image build. You almost always want both to exclude secrets and build artifacts, but .dockerignore should also exclude things you do commit but do not want in the image - like the .git directory itself, tests, docs, and CI config.

Free tool · Runs in your browser

Keep secrets out of your image.

A careless COPY . . can bake your .env, .git history, and SSH keys straight into a Docker layer — where anyone who pulls the image can read them. Pick your stack and get a .dockerignore that keeps secrets and bloat out of the build.

Stack

Exclude secrets & .env (strongly recommended) Exclude .git & CI config Exclude editor / OS junk Exclude tests & docs

The secret you didn’t mean to ship

It happens constantly: a Dockerfile with COPY . ., a .env full of real credentials sitting in the project root, and now that file is a permanent part of an image layer — readable by anyone who can pull it, even after you “delete” it in a later RUN step, because layers keep history. Scanners and researchers find exactly these leaks in public images all the time. A .dockerignore closes the door before it can happen, and it costs you one file.

It’s a small instance of a constant: secrets end up in places you didn’t intend, and the only real defense is keeping them out by default and being able to prove where they are. Managing secrets and build artifacts cleanly across the backend you own is part of what a control plane keeps honest.

Related free tools

Deploy to your own serverPush-to-deploy, your box systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS DNS records helperPoint your domain

All free tools →

Secrets belong in a vault, not a layer.

Infraveil runs your backend on servers you own with secrets managed and access audited — so credentials live in one controlled place, not scattered through images, configs, and chat logs.

See how it works

Get the secure-build playbook

Dockerfiles, secrets, and image hygiene for a backend you run yourself. No spam.