Docker Container Size Calculator

A container image is a stack of immutable filesystem layers, one per Dockerfile instruction, combined at runtime by a union filesystem. Total size is therefore additive across layers, and crucially subtractive operations do not shrink it: deleting a file in a later layer only records a whiteout marker, leaving the original bytes in the earlier layer. This is why the compose of base image, dependency layers and application code gives a usable estimate, and why cleanup must happen in the same RUN instruction that created the temporary files. Base image choice dominates the total in practice, spanning roughly 5 MB for Alpine Linux, 30 to 80 MB for Debian and Ubuntu slim variants, several hundred megabytes for full distributions, and 2 to 20 MB for distroless images that ship only a runtime. Disk accounting differs from image size because layers are shared. Ten containers from one image store the read-only layers once under the overlay2 driver and add only a thin writable upper layer each, which is why total host usage grows far more slowly than container count suggests. Registry figures differ again: layers are gzip-compressed on push, typically to 40 to 60 percent of uncompressed size, with text and source code compressing well and already-compressed binaries or media barely at all. The 45 percent factor used here is a mid-range assumption, so verify against your own manifests. Two further caveats matter: pull bandwidth tracks the compressed size while disk consumption tracks the uncompressed size, and the writable layer is unbounded unless you cap it, so runaway logs inside a container are a common cause of host disk exhaustion.

The isolation primitives underneath containers predate Docker by a decade. Linux namespaces began appearing in the kernel from 2002, and control groups were developed at Google by Paul Menage and Rohit Seth from 2006, merged into the mainline kernel in 2008 as the mechanism for limiting CPU and memory per process group. LXC packaged these into usable containers from 2008. Docker, released by Solomon Hykes of dotCloud in March 2013, added the piece that changed adoption: a layered image format with a build file and a public registry, which turned a filesystem into something shareable and versioned. Early Docker used AUFS for layering, later moving to OverlayFS, which entered the mainline Linux kernel in version 3.18 in 2014; the overlay2 driver became the default and remains the recommended storage backend. Governance was moved to the Open Container Initiative, founded in June 2015 by Docker, CoreOS and others under the Linux Foundation, which published the image and runtime specifications at version 1.0 in July 2017 and made the layer format vendor-neutral. Size optimization became a first-class concern as images spread: multi-stage builds landed in Docker 17.05 in May 2017, letting a build stage carry compilers that never reach the final image, and Google published the distroless base images around the same period to strip images down to a runtime and its libraries. BuildKit, with better caching and parallel stage execution, became the default builder in Docker 23 in 2023.