5.1.1.5 Context Transfer Cost
A focused guide to Context Transfer Cost, connecting core concepts with practical Docker and container operations.
Context transfer cost is the time and resource overhead incurred specifically from packaging and sending the build context to the Docker daemon before a build's instructions even begin executing, a cost that scales directly with how much content the context actually includes.
Where This Cost Comes From
Before any Dockerfile instruction runs, the entire build context is archived and transferred — for a local daemon this overhead is small, but it still scales with context size, and for a remote daemon (or one accessed over a slower connection) it can become genuinely significant.
docker build -t myapp .
Sending build context to Docker daemon 892.4MB
A reported transfer size this large, for a project whose actual relevant source code is a fraction of that, is a strong signal that something unnecessary is being included in the context.
Identifying What's Driving Up the Cost
Investigating exactly what occupies the bulk of a large build context reveals what specifically needs to be excluded to bring the transfer cost down.
du -sh * | sort -rh | head -10
Running this within the context directory quickly surfaces the largest contributors, which are often things like dependency directories, build artifacts, or version control history that have no business being part of the transferred context at all.
Reducing Transfer Cost With .dockerignore
Excluding identified unnecessary content directly addresses the transfer cost at its source.
node_modules
.git
dist/
*.log
Measuring the Improvement
Comparing the reported context size before and after adding appropriate exclusions provides direct, measurable confirmation of the improvement.
docker build -t myapp . 2>&1 | grep "Sending build context"
Why Context Transfer Cost Matters
This overhead applies to every single build, regardless of how much or how little actually changed since the last one — keeping context size under control through deliberate exclusion is one of the simplest, most broadly applicable ways to keep this fixed, recurring cost as small as possible across a project's entire development lifecycle.