Docker Build Time Estimator

Estimate total docker build duration from layer count, cache hits and build steps.

About Docker Build Time Estimator

Docker build time is driven by how many layers must actually execute versus how many are served from cache: time = layers × avg_layer_time × (1 − cache_hit_rate) ÷ parallel_factor. Ordering Dockerfile instructions so that frequently-changing steps (e.g. COPY source code) come after stable steps (e.g. installing dependencies) maximizes cache hit rate on incremental builds.

Formula

buildTime = (layers × avgLayerTime × (1 - cacheHitRate)) / parallelFactor

N: Number of layers
t_l: Average layer build time in seconds
h: Cache hit rate (0 to 1)
P: Parallel build factor
T: Estimated build time in seconds

Worked example

With the default values below, Docker Build Time Estimator returns Estimated Build Time of 120.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

Number of Layersaccepts 1–500 layers: 10 layers
Avg Layer Build Timeaccepts 0–36,000 seconds: 20 seconds
Cache Hit Rateaccepts 0–100 %: 40 %
Parallel Build Factoraccepts 1–32 ×: 1 ×

Results

Estimated Build Time: 120.0 seconds
Estimated Build Time: 2.00 minutes
Uncached Layers: 6 layers
Cached Layers: 4 layers
Time Saved by Cache: 80.0 seconds

Step by step

1Uncached fraction: 1 − cache hit rate= 0.60
2Sequential build time= 120.0s
3Build time with parallelism= 120.0s

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How do I improve my cache hit rate?

Order Dockerfile instructions from least to most frequently changing, copy dependency manifests (package.json, requirements.txt) before application source code, and use BuildKit's cache mounts for package manager caches.

What does the parallel build factor represent?

It models BuildKit's ability to build independent multi-stage build stages concurrently, or running multiple image builds concurrently in CI. A factor of 1 means fully sequential.

Why is a full cache miss so much slower?

Every layer must re-download dependencies, recompile, and re-execute from scratch — this is the classic 'cold cache' first build a CI runner experiences after cache eviction.

Does using a remote build cache help in CI?

Yes — CI runners often start with cold local caches; pulling a remote cache (registry cache or BuildKit --cache-from) before building restores a meaningful cache hit rate on ephemeral runners.