Docker Image Size Savings Calculator

How Docker Image Size Affects Registry Costs

When you push images to a registry such as Docker Hub, Amazon ECR, Google Artifact Registry, or GitHub Container Registry, the provider stores the compressed layers and charges for the total gigabytes stored. Every time you pull the image to a node, cluster, or CI agent, those compressed layers are transferred over the network and count toward your data transfer or egress bill.

• Storage costs: charged per GB per month for storing images and their layers.
• Transfer costs: charged per GB of data transferred out of the registry or region.

Smaller images mean fewer megabytes stored per tag and fewer megabytes transferred for each pull. When images are pulled frequently by CI pipelines, autoscaling clusters, or multiple environments, even a reduction of a few hundred megabytes per image can translate into meaningful monthly savings.

Savings Formulas

The calculator assumes you enter compressed image sizes in megabytes (MB), as reported by your registry or build tooling. It then converts these to gigabytes (GB) using 1 GB = 1,024 MB and applies your pricing inputs.

Let:

• S_c = current image size (MB)
• S_o = optimized image size (MB)
• P = monthly pulls
• r_t = data transfer cost per GB
• r_s = storage cost per GB per month

First compute the size reduction in gigabytes:

This gives in gigabytes saved per image.

Transfer savings per month are:

Storage savings per month are:

Total estimated monthly savings:

The calculator uses equivalent arithmetic with your form inputs and surfaces the total in currency units (for example, US dollars) based on the rates you provide.

Worked Example

Consider a typical optimization:

• Current image size: 800 MB
• Optimized image size: 300 MB
• Monthly pulls: 200
• Data transfer cost: $0.10 per GB
• Storage cost: $0.02 per GB per month

1. Compute the size reduction in GB:

ΔS = (800 − 300) / 1024 = 500 / 1024 ≈ 0.488 GB

2. Transfer savings per month:

0.488 GB × 200 pulls × $0.10 ≈ $9.76

3. Storage savings per month:

0.488 GB × $0.02 ≈ $0.01

4. Total estimated monthly savings:

$9.76 + $0.01 ≈ $9.77 per month

For a single service, this may seem modest, but as you add more services, environments, and CI jobs, the savings accumulate. The same pattern applies when switching from a full Linux distribution to a minimal or distroless base image, or when aggressively removing unused build tools with multi-stage builds.

Comparing Storage-Heavy and Transfer-Heavy Scenarios

Different workloads benefit in different ways from image optimization. The table below contrasts a storage-heavy case with a transfer-heavy one, assuming the same pricing.

In the first scenario, most savings come from reducing a very large image, even though it is pulled infrequently. In the second scenario, the per-pull savings are smaller, but the high pull volume makes transfer savings dominate. The calculator allows you to plug in your own numbers to see which effect matters more in your environment.

Interpreting the Results

The output of the calculator is an estimated monthly savings figure. Use it as a planning tool rather than an exact bill prediction:

• If the result is small (cents or a few dollars), focus optimization efforts on other, higher-impact images or services.
• If the result is in the tens or hundreds of dollars per month, it may justify work to adopt multi-stage builds, slimmer base images, or automated cleanup.
• Combine this estimate with the number of similar services you run to approximate the total platform impact.

You can also compare multiple scenarios—for example, one optimized size using Alpine and another using a distroless base—to see which delivers the best cost reduction for your registry and workload patterns.

Assumptions and Limitations

To keep the calculation simple and broadly applicable, several assumptions are made. Be aware of these when comparing the estimate to your actual invoices:

• No layer caching modeled: every pull is treated as downloading the full compressed image size. In reality, cached layers may reduce transfer for some pulls.
• Compressed sizes only: inputs should reflect compressed image sizes as stored in the registry, not uncompressed runtime size on disk.
• Outbound transfer only: inbound traffic and free intra-region transfer are ignored. If your provider offers free egress in some cases, your real savings may be lower.
• Flat pricing: the calculator assumes a single transfer and storage rate, without modeling tiered or region-specific pricing discounts.
• Single image and retention pattern: the storage savings estimate applies to one image. If you keep multiple tags or long retention windows, you can multiply the result accordingly.

These simplifications are intentional so you can quickly explore “what if” scenarios. For a detailed cost analysis, export usage metrics from your registry or cloud provider and combine them with its full pricing model.

Who This Calculator Is For

This tool is especially useful for:

• DevOps and platform teams estimating the payoff from moving to lighter base images or refactoring Dockerfiles.
• SREs and cost-optimization engineers who need to translate megabytes and pull counts into budget impact.
• Engineering leaders preparing business cases for container optimization, registry cleanup, or CI pipeline tuning.

Use the calculator as a quick way to communicate the value of keeping Docker images slim, monitoring their growth over time, and automating size checks in your CI/CD workflows.