This is a baseline, not a universal winner. The comparison uses the smallest official Docker images that can be pulled by tag, then records what is actually inside them. It does not turn a container footprint into a claim about runtime speed, security, or every possible server installation.
Review scope: one read-only inspection pass on 2026-08-11, in disposable containers, with no vendor access, sponsorship, or commercial relationship. The tested point releases are exact: Debian GNU/Linux 13.6 (trixie) and Alpine Linux 3.24.1. Debian lists 13.6 as its latest stable update; Alpine lists 3.24.1 as the current 3.24 release.
Reproducible references
The images and digests were:
| Distribution | Image reference | Digest | Docker-reported image size |
|---|---|---|---|
| Debian 13.6 | docker.io/library/debian:13.6 |
sha256:34cd9e9fd437c0a095ec39cb2e73422c9f30821b0d0848ed74fd0d43bae4d958 |
120 MB |
| Alpine 3.24.1 | docker.io/library/alpine:3.24.1 |
sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b |
8.42 MB |
The digest is the identity used for the lab; a mutable tag is only the lookup
key. The Docker size is image metadata, not a promise about a running
container’s writable layer. A read-only du -sh / measured 128M for Debian and
8.6M for Alpine in these containers, but that root walk includes filesystem
implementation details and should not replace the image-size comparison.
Criteria and evidence
The following rows use the same commands in both images. Package and docs counts describe these deliberately minimal images, not the complete Debian or Alpine repositories.
| Criterion | Debian 13.6 | Alpine 3.24.1 | What the evidence means |
|---|---|---|---|
| Image size | 120 MB | 8.42 MB | Alpine has a much smaller starting image in this official pair. |
| libc | glibc 2.41-12+deb13u3 (ldd 2.41) |
musl 1.2.6-r2 (ldd 1.2.6) |
Native and prebuilt binary compatibility is a workload constraint, not a preference. |
| Package database | 78 installed packages; dpkg, apt-get |
16 installed packages; apk |
The base contents and package tooling differ sharply. Neither count is a repository-size metric. |
| Init in the tested image | /sbin/init absent; no ps applet or procps package |
/sbin/init links to BusyBox; BusyBox ps works; OpenRC absent |
Both official base images are container roots, not complete service hosts. |
| Documentation footprint | /usr/share/doc: 8.0M, 77 directories |
/usr/share/doc: absent |
The base image chooses footprint over local manuals. Use the official web handbooks for setup and operations. |
| Maintenance | Stable support through 2028-08-09; Debian LTS through 2030-06-30 | v3.24 support listed through 2028-06-01 | These are different support policies and dates; pin a branch and monitor its advisories. |
libc and packages
Debian’s output identified glibc 2.41 and package libc6:amd64 2.41-12+deb13u3. Alpine identified musl 1.2.6-r2. A binary or vendor package
that assumes glibc is not automatically portable to musl; conversely, a small
musl target does not prove that every glibc-oriented build will run there. Test
the actual artifact, especially if it uses a dynamic loader, NSS module, or
precompiled extension.
The package tools reflect the same boundary:
# Debian: inspect, do not change the image
dpkg-query -W base-files
apt-cache policy base-files
# Alpine: inspect the local database and cache
apk info
apk policy busyboxIn the pinned base images those commands returned base-files 13.8+deb13u6
and busybox 1.37.0-r31, respectively. Alpine warned that remote indexes were
not cached; the command still reported installed packages. No package update or
installation was run for this comparison.
Init and service model
The container entrypoint matters more than a distribution stereotype. In the
tested Debian image /bin/sh was PID 1 and /sbin/init did not exist. In the
tested Alpine image /bin/sh was PID 1 and /sbin/init pointed to BusyBox.
Neither image had a running service manager. A full Debian installation may use
systemd; Alpine documents OpenRC for service management. Those are full-install
boundaries, not results silently inferred from the two base images.
If the workload is one foreground process, the image entrypoint may be enough. If it needs service supervision, boot ordering, timers, or local journal semantics, choose and test the service model explicitly rather than adding commands to a base image until it resembles a VM.
Documentation and maintenance
The local docs counts are a measurement of the base image, not a quality score.
Debian’s larger base includes package metadata and documentation directories;
Alpine’s base does not create /usr/share/doc. Both projects publish primary
handbooks, package indexes, release notes, and security information. A small
image still needs an operational documentation plan.
As of this test date, Debian’s release page lists 13.6 as stable and gives its full-support and LTS dates. Alpine’s release table lists 3.24.1 and an end of support of 2028-06-01 for the v3.24 branch. Those dates can change with policy updates; pin the release and re-check the upstream pages before a long-lived deployment.
Workload decision matrix
| Workload evidence | Starting point | Why |
|---|---|---|
| Vendor binaries or extensions published for glibc; broad Debian package assumptions | Debian 13.6 | glibc and the Debian package ecosystem reduce compatibility surprises; the trade-off is a larger image. |
| A tested application supports musl and the image/pull budget dominates | Alpine 3.24.1 | The pinned image is 8.42 MB and the package database is small; the team owns musl compatibility checks. |
| A host-style service stack needs systemd semantics | A full Debian installation, or an explicitly tested systemd image | Neither tested base image runs a service manager, so a base-image comparison cannot answer this requirement. |
| An OpenRC-managed service stack is the contract | A full Alpine installation, or an explicitly tested OpenRC image | Alpine’s documented service model is OpenRC, but OpenRC was absent from this base image. |
| Unknown native dependencies or performance-sensitive workload | Neither by default | Build and run the actual artifact, measure startup and steady-state behavior, then select the smallest compatible baseline. |
No benchmark was run. The lab does not support claims about throughput, latency, boot speed, attack surface, package freshness, or memory under load. Those are separate experiments with pinned workloads and resource limits.
The useful conclusion is conditional: choose Debian when compatibility and a fuller general-purpose baseline are the measured constraints; choose Alpine when a tested musl workload benefits from a much smaller image. Keep the image digest, libc, package database, init model, support date, and workload test in the deployment record so a future point-release change is visible.
Continue the signal
