Your Docker Build Context Is Bigger Than You Think

When you run docker build ., you might think that dot just means “where the Dockerfile is.” But in Dockerland, . means: “send everything in this directory to the Docker daemon.” That includes your node_modules/, .git/, and anything else sitting in the folder—unless you explicitly tell Docker not to.

And if you haven’t set up a .dockerignore (let’s be honest—most of us forget), you’re probably shipping way more than you need. Think:

• Your entire Git history
• A bloated node_modules/ directory
• All of dist/ from previous builds
• Local development tools and secrets like .env and .vscode
• Log files and other noise

What Really Happens When You Run docker build .

Let’s demystify it:

1. Docker packages up everything in your current directory.
2. That package is sent to the Docker daemon (either local or remote).
3. The daemon unpacks it and uses it as the context for your build.

So, if your TypeScript project has hundreds of megabytes of dependencies and build artifacts, all of that gets sent—even if your Dockerfile never touches it.

Use .dockerignore to Avoid the Pain

Just like .gitignore, a .dockerignore file tells Docker what to leave out. Here’s a solid starting point for a TypeScript project:

node_modules
dist
.env
.git
.vscode
*.log

• node_modules – You’ll reinstall dependencies inside the image anyway.
• dist – This is your build output. Don't include it unless you're copying local builds.
• .env – Secrets don’t belong in your container context.
• .git – No one needs your commit history in the image.
• .vscode – Local editor config has no business in production.
• *.log – Old logs don’t help your build.

This one file can drastically reduce the size of your build context, speed up your builds, and help prevent the accidental leak of sensitive information.

Common Gotchas

• Large image builds – Wondering why your build takes forever? You're probably sending gigabytes of junk.
• Secret leaks – That .env file you committed "just temporarily" can get baked into your image.
• Flaky builds – Copying local node_modules can introduce platform-specific issues.

Pro Tips for TypeScript Devs

• Use multi-stage builds so your final image doesn't contain unnecessary packages like gcc.
• Keep your Dockerfile at the root of your project and be explicit with your .dockerignore, you want only what’s required to build your code.

Check your context size by running:

docker build . --progress=plain --no-cache

It’ll show you how much data is being sent.

Conclusion: Clean Context, Clean Builds

Your build context is the first step in every Docker image you create, so treat it like production code. A messy context leads to bloated images, slow builds, and potential security risks.

Set up your .dockerignore now. Keep it tight. Your future self (and CI pipeline) will thank you.