What is a good Docker image size?

For production: under 100 MB is excellent, 100–300 MB is acceptable, 300–500 MB is large but manageable, over 500 MB indicates optimization opportunities. Language-specific benchmarks: Go/Rust static binaries can be under 20 MB, Node.js apps typically 100–300 MB, Python apps 200–500 MB.

What is a multi-stage build?

Multi-stage builds use multiple FROM statements. Earlier stages compile/build the application, and the final stage copies only the runtime artifacts. Build tools, compilers, and intermediate files are excluded, dramatically reducing final image size.

Does image size affect startup time?

Yes, but primarily through pull time. A 500 MB image takes 10–30 seconds to pull on a 100 Mbps network. On Kubernetes, this impacts pod scheduling during scale-up events. Container runtime startup itself is usually sub-second regardless of image size.

Should I use Alpine or Debian slim?

Alpine (5 MB) is smallest but uses musl libc, which can cause compatibility issues with some packages. Debian slim (25–60 MB) uses glibc and has better compatibility. Use Alpine for simple, well-tested workloads; Debian slim for complex dependencies.

How does image size affect registry costs?

Registries charge by storage. A 500 MB image with 10 tags uses 5 GB (if not deduplicated) or less with layer deduplication. Reducing image size by 50% directly reduces storage costs. Also reduces transfer costs for pulls.

What about distroless images?

Google's distroless images contain only the application runtime (no shell, package manager, or utilities). They're the smallest and most secure option. Sizes range from 2 MB (static) to 20 MB (base). The trade-off is inability to exec into containers for debugging.

Docker Image Size Calculator

Estimate Docker image size from base image, dependencies, application code, and build artifacts. Optimize layer efficiency.

Base ImageAlpine ~5, Debian ~50

System Dependencies

App Dependenciesnode_modules, pip pkgs

Application Code

Build ArtifactsCompilers, build tools

Multi-Stage Build

Deploy Replicas

Registry Compression

Registry Price

$/GB

Final Image Size

300.00 MB

Multi-stage build

Compressed Size

180.00 MB

0.60% compression ratio

Multi-Stage Savings

200.00 MB

40% reduction vs single-stage

Pull Time (Slow)

36.00 sec

At 5 MB/s (cross-region)

Pull Time (Fast)

1.80 sec

At 100 MB/s (same-region)

Total Pull Traffic

0.88 GB

5.00 replicas pulling image

Storage Cost / Month

$0.53

~30 image tags retained

Single-Stage Size

500.00 MB

All layers including build artifacts

Layer Breakdown

Base Image

50.00 MB

System Deps

80.00 MB

App Deps

150.00 MB

App Code

20.00 MB

Base Image Comparison

Base Image	Typical Size	Your Final Size	Pull Time (5 MB/s)	Pull Time (100 MB/s)
scratch	0.00 MB	250.00 MB	30.00s	1.50s
Alpine	5.00 MB	255.00 MB	30.60s	1.53s
Debian Slim	50.00 MB	300.00 MB	36.00s	1.80s
Ubuntu 22.04	75.00 MB	325.00 MB	39.00s	1.95s
Node 20-slim	120.00 MB	370.00 MB	44.40s	2.22s
Python 3.12-slim	130.00 MB	380.00 MB	45.60s	2.28s
Ubuntu Full	200.00 MB	450.00 MB	54.00s	2.70s

Optimization Techniques

Technique	Typical Savings	Difficulty	When to Use
Multi-stage build	30–60%	Easy	Always for compiled languages
Alpine base image	50–90%	Medium	When musl libc is compatible
Distroless base	60–85%	Medium	Production containers
.dockerignore	5–20%	Easy	Always (exclude .git, tests)
Layer ordering	Cache hits	Easy	Always (deps before code)
Combine RUN steps	10–30%	Easy	When layer count is high
Scratch base (Go/Rust)	95%+	Hard	Static binaries only

Planning notes, formulas, and examples

About the Docker Image Size Calculator

Docker image size directly impacts pull times, registry storage costs, deployment speed, and container startup time. Smaller images deploy faster, cost less to store, and have a smaller attack surface. Understanding what contributes to image size is the first step toward optimization.

This calculator estimates total image size from its components: base image, system dependencies, application dependencies, application code, and build artifacts. It also models the savings from multi-stage builds, which separate the build environment from the runtime environment.

Common optimizations include using slim or Alpine base images (5–50 MB vs. 200–900 MB for full images), multi-stage builds to exclude build tools, proper layer ordering to maximize cache hits, and using .dockerignore to exclude unnecessary files.

When This Page Helps

Large Docker images waste storage, slow deployments, and increase attack surface. This calculator helps estimate image size and quantify savings from optimization strategies like multi-stage builds and slim base images.

How to Use the Inputs

Enter the base image size (e.g., 5 MB for Alpine, 130 MB for Debian slim).
Enter the size of system dependencies installed via apt/apk.
Enter the size of application dependencies (node_modules, pip packages).
Enter the application code size.
Enter the build artifacts size (if using single-stage build).
Toggle multi-stage build to see savings.

Formula used

Single-Stage Size = base + system_deps + app_deps + app_code + build_artifacts
Multi-Stage Size = base + system_deps + app_deps + app_code
Savings = build_artifacts (excluded in multi-stage)

Example Calculation

Result: Single: 500 MB, Multi-stage: 300 MB (40% smaller)

Single-stage: 50 + 80 + 150 + 20 + 200 = 500 MB. Multi-stage excludes build artifacts: 50 + 80 + 150 + 20 = 300 MB. That's 200 MB saved (40% reduction), which translates to faster pulls and lower registry costs.

Tips & Best Practices

Use Alpine base images (5 MB) instead of Ubuntu (70+ MB) when possible.
Multi-stage builds can reduce image size by 40–70% for compiled languages.
Order Dockerfile layers from least-changed to most-changed for cache efficiency.
Use .dockerignore to exclude .git, node_modules, test files, and docs.
Combine RUN commands to reduce layer count and intermediate artifacts.
Use docker image history to identify which layers contribute most to size.

Anatomy of a Docker Image

A Docker image is a stack of read-only layers. Each Dockerfile instruction creates a new layer. The base image is the foundation (Alpine, Debian, scratch), followed by system dependencies, application dependencies, and finally the application code. Layer deduplication means shared base layers aren't re-downloaded.

The Multi-Stage Revolution

Before multi-stage builds, developers either shipped build tools in production images or maintained separate Dockerfiles for building and running. Multi-stage builds solved this elegantly: build in one stage, copy artifacts to a minimal runtime stage. This single improvement often reduces image size by 50–80%.

Image Size Optimization Workflow

Start with `docker image history` to identify large layers. Switch to a slim base image, add multi-stage build, combine RUN commands, add .dockerignore, and remove debugging tools. Each step typically reduces size by 10–40%.

Sources & Methodology

Last updated: February 8, 2026

Frequently Asked Questions

For production: under 100 MB is excellent, 100–300 MB is acceptable, 300–500 MB is large but manageable, over 500 MB indicates optimization opportunities. Language-specific benchmarks: Go/Rust static binaries can be under 20 MB, Node.js apps typically 100–300 MB, Python apps 200–500 MB.