Distroless Alpine Scratch and Debian Slim for Rust Images

Four runtime base images for Rust containers, compared on size, libc, debugging, TLS certificates and security. A decision table and the failure each choice invites.

3 min read

Summarize in AI

Quick Summary

Use debian:bookworm-slim by default: it matches the glibc your binary was built against and has a shell for debugging. Use gcr.io/distroless/cc for a smaller, shell-less image with the same glibc. Use scratch or Alpine only with a static musl build, accepting musl differences and the lack of tools in scratch.

Key takeaways

A dynamically linked Rust binary needs glibc and libgcc, which Debian and distroless/cc provide.
scratch is empty, so the binary must be fully static, and TLS root certificates must be copied in or bundled.
Alpine uses musl libc, which differs from glibc in DNS behavior, memory allocator performance and some edge cases.
Distroless has no shell or package manager, which reduces attack surface and makes debugging harder.
Match the build and runtime libc, or the binary fails to start with a missing symbol error.

The base image decides three things at once: how big the image is, how hard it is to debug and what C library the binary runs on. The last one causes outages when it is wrong. This post compares four common choices for a Rust service and says when each is right. It extends a small Docker image for Rust in the packaging steps of shipping Rust to production.

Rust 1.90, Debian 12.

The comparison

	`debian:bookworm-slim`	`distroless/cc-debian12`	`alpine`	`scratch`
libc	glibc	glibc	musl	none
Shell and tools	yes (`sh`, `apt`)	no	yes (`sh`, `apk`)	no
Runtime size (base)	around 75 MB	around 25 MB	around 8 MB	0
Build target	`x86_64-unknown-linux-gnu`	gnu	`...-musl`	`...-musl` static
CA certificates	add package	included	add package	copy in
Debug in container	`docker exec sh`	needs debug variant	`docker exec sh`	needs a sidecar or copy

Sizes are approximate, vary by release and architecture, and are worth checking with docker images when you choose.

Debian slim

The unsurprising default. Build in rust:1.90-bookworm, run in debian:bookworm-slim. The same glibc on both sides eliminates a class of failures. You get a shell for docker exec, apt for a debugging tool and long security support.

Distroless cc

Dockerfile

FROM gcr.io/distroless/cc-debian12:nonroot
COPY --from=builder /app/target/release/myapp /myapp
ENTRYPOINT ["/myapp"]

It contains glibc, libgcc, certificates and tzdata, nothing else, and a nonroot user. A shell-less image cannot be exploited into spawning /bin/sh, and docker exec has nothing to run; use the :debug tag, which adds BusyBox, when you need to look inside. Health checks must be done by the orchestrator over HTTP, or by a subcommand of your own binary.

Alpine

Small and familiar, with apk. The catch is musl. DNS resolution has historically behaved differently, the default allocator is slower under multithreaded allocation, and crates that link C libraries may fail to build. If you pick it, build for x86_64-unknown-linux-musl in an Alpine builder stage. The trade-offs with static binaries are in static linking with musl.

scratch

Dockerfile

FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /app/target/x86_64-unknown-linux-musl/release/myapp /myapp
USER 10001
ENTRYPOINT ["/myapp"]

The smallest image: the binary plus certificates. No shell, no /tmp, no /etc/passwd, so USER 10001 works by number only. If the program writes temporary files, mount a volume at /tmp. Everything about timezones, locale and user names must be embedded or avoided.

Decision

Default, or if unsure: Debian slim.
Security-minded and comfortable without a shell: distroless cc.
Static binary, minimal everything, you have tested musl behavior: scratch.
Alpine only if you already depend on it elsewhere.

Failure modes

A glibc binary on Alpine: exec /myapp: no such file or directory, because the dynamic loader is missing. A binary built on a newer distribution than the runtime: GLIBC_2.38 not found. A scratch image calling an HTTPS API: certificate verify failed, with no roots. Test the image with a real outbound call, not only the health check. The images are documented in the distroless repository.

Taggeddocker distroless