Daniel sent us this one — what's the smallest Linux system that can actually do something useful? Serve a web page, run a health check, act as a DNS resolver. He wants to know how barebones we can get, where BusyBox fits in, and how these stripped-down systems become the secret sauce behind efficient Docker stacks in production. There's a whole ladder of minimalism here and most people don't realize how far down it goes.
The ladder goes all the way to literally nothing. The FROM scratch image in Docker is not a small Linux — it is zero bytes. No shell, no libc, no filesystem tools. You bring a statically compiled binary and that's your entire container. I've seen Go HTTP servers in scratch containers that clock in at about five megabytes total. The kernel, plus five megabytes of binary. That's the whole runtime.
My leaf medicine reference charts are larger than that. And the thing actually serves traffic?
And here's why — the Linux kernel doesn't need a userland to run a process. When you call execve on a binary, the kernel loads the ELF, maps it into memory, and jumps to the entry point. If that binary was compiled with the -static flag, every library function it needs is baked right into the executable. No dynamic linker, no shared objects. The kernel handles system calls directly. You don't even need a filesystem beyond what Docker gives you — just the binary and maybe /proc and /sys that the kernel synthesizes anyway.
The entire concept of a "Linux system" — init system, shell, coreutils, package manager — that's all optional window dressing. The kernel will happily run a single binary and call it a day.
This is what most people miss about containers. A container is not a virtual machine. There is no second kernel, no boot process, no init. Docker sets up namespaces and cgroups, hands the process to the host kernel, and says "run this." The "operating system" in the container is purely the userland you chose to include. You can include none of it.
Scratch is the floor. But Daniel mentioned BusyBox, and that's the next rung up. What actually is BusyBox?
BusyBox is a single binary that reimplements over three hundred Unix utilities. The static build is about one megabyte. One megabyte gives you sh, grep, sed, awk, wget, ping, nc, cron, tar, gzip, and about two hundred ninety more. The BusyBox website describes itself as "The Swiss Army Knife of Embedded Linux," and for once the marketing is accurate.
Three hundred utilities. How does that work mechanically?
The multi-call binary trick. The BusyBox binary checks argv[0] — the name it was invoked as — and branches to the appropriate internal function. You create a symlink: /bin/grep points to /bin/busybox. When someone types grep, the kernel launches busybox, busybox sees "I was called as grep," and runs its internal grep implementation. Same binary, three hundred different entry points. The filesystem is just a tree of symlinks all pointing back to the same file.
It's like one person who, depending on which hat they put on, becomes a plumber or an electrician or a chef. Same person, different hat, different job.
It works because most Unix utilities share a huge amount of common code — argument parsing, file I/O, string manipulation. BusyBox deduplicates all of that into a single codebase. The GNU coreutils approach is separate binaries for everything, each linking against glibc, each carrying its own copy of common routines. BusyBox says "put it all in one binary and share the code." That's how you get three hundred utilities into one megabyte.
What's the catch?
BusyBox utilities are feature-light. No --color=auto for grep. Limited regex support — basic and extended work, but Perl-compatible regex doesn't. Some esoteric flags on standard tools are missing. The awk implementation is a subset. But for what you do in a container — parse logs, check ports, run a cron job, fetch a health endpoint — you almost never hit those limitations.
It's not GNU coreutils, it's the IKEA version. Flat-packed, missing some ornate trim, but functionally still a bookshelf.
In many cases it's faster. Some BusyBox utilities have hand-tuned assembly for common operations. The grep in BusyBox can be faster than GNU grep for simple pattern matching because it doesn't carry the optimization overhead for complex patterns. The BusyBox developers have been optimizing this for embedded systems since the mid-nineties — routers, phones, set-top boxes. If your device had a Linux kernel and less than sixteen megabytes of flash, you were probably running BusyBox.
How does this translate to Docker? Daniel's question is specifically about Docker stacks.
The official Docker BusyBox image is about one point two megabytes compressed. You pull it in under a second on any reasonable connection. Compare that to the Ubuntu base image — around seventy-seven megabytes compressed for the slim version, closer to two hundred for the full image. On a cold Kubernetes node, pulling Ubuntu might take thirty seconds. Pulling BusyBox is effectively instant.
That pull time isn't just about convenience. If you're autoscaling, cold start latency is everything.
When your cluster needs to spin up new pods to handle a traffic spike, every second spent pulling images is a second your users are waiting. A one-point-two-megabyte image means your health-check sidecar is running before the orchestrator finishes scheduling the next pod. This directly impacts your SLOs. It's not about disk space — disk is cheap. It's about time and attack surface.
Let's talk about attack surface. Fewer binaries means fewer CVEs.
In 2025, the Ubuntu base image averaged around forty critical CVEs at any given time — that's the baseline before you even install your application. Every one of those is a binary sitting in your container, whether you use it or not. The BusyBox image averaged two to three critical CVEs over the same period. That's an order of magnitude reduction in your vulnerability baseline.
The BusyBox codebase is smaller, so the maintainers can actually audit the whole thing.
The entire BusyBox source tree is something a single competent developer can read and understand. The full Ubuntu package set? Nobody audits that end to end. You're relying on the distribution's security team to triage and patch, and they do good work, but the surface area is enormous. With BusyBox, you know exactly what's in there because there isn't much.
We've got scratch at the absolute floor — no userland, just a static binary. Then BusyBox at one megabyte — three hundred utilities, no package manager. What's the next rung?
And this is where people get confused, because Alpine uses BusyBox as its userland, but it's not "just BusyBox with a package manager." Alpine makes a much bigger change under the hood — it replaces glibc with musl libc.
That's the thing that breaks.
musl is a from-scratch implementation of the C standard library. It's smaller, simpler, and more standards-compliant than glibc in many ways. But it's not a drop-in replacement. Binaries compiled against glibc expect specific symbol versions, specific thread-local storage layouts, specific memory allocator semantics. If you take a precompiled Python wheel built on Ubuntu and try to run it on Alpine, it might segfault because it can't find the glibc symbols it expects.
The tradeoff for Alpine's five-megabyte base image is that you might have to recompile your stuff.
Or use the Alpine-packaged versions, which are compiled against musl. apk add python3 gets you a Python built for musl. The problem is third-party binaries distributed only as glibc-linked builds. Then you're either recompiling from source or not using Alpine.
This is why you see teams go from scratch to BusyBox to Alpine to Debian-slim to full Ubuntu, each step adding compatibility at the cost of size and surface area. It's a genuine engineering tradeoff, not a purity test.
The ladder exists for a reason. Start at scratch — if your app is Go or Rust and you can compile static, you're done. Five megabytes, zero attack surface beyond your own code. Need a shell for debugging? Need a package manager because you have runtime dependencies? Need glibc compatibility because something won't compile against musl? Need the full Ubuntu userland for a complex legacy application? Fine, use Ubuntu. But you should know why you're at each rung.
There's a pattern I've seen in production — the multi-stage build where the final image is scratch or distroless, but the build stage is a full Debian image with all the compilers and headers.
That's the standard pattern. Your build stage pulls in gcc, make, libssl-dev — that image might be five hundred megabytes. It compiles your Go or Rust binary, and then the final stage is FROM scratch, COPY --from=builder /app/server /server, CMD ["/server"]. The build image gets thrown away. Your production artifact is just the binary.
If you need a shell for debugging in production?
This is where the operational tradeoff bites. With scratch or distroless, you can't kubectl exec into the container and poke around. There's no shell to exec into. If something goes wrong, your debugging surface is logs and metrics — which should be sufficient. But it requires a different operational maturity. You can't just hop in and curl localhost.
That's why I see teams run a BusyBox sidecar alongside their distroless app container.
The app container runs the service — minimal, secure, no shell. The sidecar runs BusyBox and has wget, nc, ping, curl. If you need to check connectivity, you exec into the sidecar, not the app container. The sidecar shares the pod's network namespace, so nc -vz localhost 8080 from the sidecar hits the app container's port. You get debugging without bloating your production image.
Walk me through a real production stack that uses this approach.
Nginx reverse proxy on Alpine — about fifteen megabytes total. Behind it, a Python API service on a distroless image — Google's distroless Python includes the runtime and your code, but no shell, no package manager. Maybe fifty megabytes. Redis on Alpine — another fifteen megabytes. Then a BusyBox sidecar in the API pod for log rotation and health checks. The whole stack is under a hundred and fifty megabytes. A single Ubuntu-based monolith would be triple that before you wrote a line of application code.
The BusyBox sidecar is doing what exactly?
Health checks are the most common pattern. wget --spider http://localhost:8080/health on a cron schedule. If the health endpoint stops responding, the sidecar can trigger an alert. It can also handle log rotation — crond plus a shell script that compresses and ships logs. Or act as a network debugger — nc -vz db 5432 to verify database connectivity.
Kubernetes has standardized on BusyBox for debugging. kubectl run --rm -it --image=busybox is the default incantation for checking network connectivity from inside the cluster.
Because it's the smallest thing that gives you a shell and networking tools. You don't want to pull a two-hundred-megabyte Ubuntu image just to run ping.
Let's talk about distroless, because it's a different philosophy from BusyBox.
Distroless images take the opposite approach. BusyBox says "here's a tiny toolbox with everything." Distroless says "here's the absolute minimum to run your specific runtime — and nothing else." A distroless Python image includes glibc, the Python interpreter, and your code. No shell, no ls, no cat, no package manager. You can't even docker exec into it.
It's scratch, but with the runtime pre-installed. You don't have to compile your Python app statically — which you can't really do — but you also don't get any operating system cruft.
The security profile is excellent because there's literally nothing to exploit except your application and the Python runtime. No wget that could exfiltrate data, no nc that could open a reverse shell, no package manager that could install malware. If an attacker compromises your app, they're stuck in a room with no tools.
The downside being that when your app breaks at 3 AM and you can't exec in to debug it, you're going to curse whoever chose distroless.
That's the genuine tension. The security team loves distroless. The on-call engineers want a shell. The BusyBox sidecar pattern is the compromise — secure app container, debuggable sidecar. But it adds complexity to your pod spec, and now you have two containers to maintain instead of one.
There's no free lunch. But the lunch is at least cheaper with BusyBox.
And there's one more dimension people miss — the CVE response cycle. When a critical vulnerability drops in glibc or OpenSSL, every container with those libraries needs to be rebuilt and redeployed. With a scratch image, you don't have glibc or OpenSSL in the container at all — your Go binary statically linked them, so you rebuild your app with the patched version and you're done. The attack surface reduction isn't just about fewer vulnerabilities — it's about faster remediation when they do occur.
In a world where CVEs are dropping constantly, that remediation velocity matters.
It matters enormously. And even the two to three CVEs in BusyBox might not apply to your use case. If the vulnerability is in BusyBox's telnet implementation and you're not using telnet, you're not affected. With a full distro, you have the vulnerable code on disk even if you never use it, and your security scanner is going to flag it.
Your compliance team is chasing ghosts because the base image shipped with libpng and there's a CVE in libpng, even though your container is a Go API server that never touches image files.
That's the operational cost of bloat. Every unused package is a false positive in your vulnerability scanner, a line item in your compliance review, a thing you have to explain to auditors. Multiply that by forty CVEs across fifty microservices and your security team is spending half their time writing exemption memos.
Let's get practical. What's the rule of thumb for someone looking at their own Docker stacks?
Audit your base images first. Run docker images and look at the size column. If you have a simple Go service on a seven-hundred-megabyte Ubuntu image, something's wrong. That service could be five megabytes on scratch. Then ask what you actually need from the base image. If your app is compiled — Go, Rust, C with static linking — start with FROM scratch. If you need a shell for debugging, try FROM busybox. If you need a package manager, try FROM alpine. Only reach for Debian or Ubuntu when you have a specific dependency that requires glibc or a package unavailable on Alpine.
For teams on Kubernetes, standardize on BusyBox for debug and init containers.
The BusyBox image is so small and so universally used that it's probably cached on every node in your cluster already. Your init container that waits for the database — busybox sh -c 'until nc -z db 5432; do sleep 1; done' — that's pulling from cache, starting instantly, costing you almost nothing.
I want to go back to the multi-call binary architecture. You said it deduplicates shared code. How much shared code are we talking about?
A surprising amount. grep, sed, and awk all read files line by line, parse patterns, write output. In the GNU world, each has its own implementation of line reading, its own argument parser, its own memory management. BusyBox has one line-reading routine, one argument parser, one set of memory allocation wrappers. The deduplication is aggressive. Plus the BusyBox developers are maniacal about code size — they'll write something in assembly if it saves a few hundred bytes.
This was originally built for embedded systems where every kilobyte mattered.
Routers with four megabytes of flash. Phones with sixteen megabytes of storage. The entire Linux userland had to fit in whatever space was left after the kernel. BusyBox was the answer. It still is — if you have a smart thermostat or a WiFi router running Linux, it's almost certainly running BusyBox under the hood. The Docker use case is just the cloud-native world discovering what embedded engineers have known for thirty years.
There's something philosophical here. We spent decades building increasingly complex operating systems — init systems, service managers, logging daemons, package managers — and now we're stripping it all away. Containers are taking us back to the Unix philosophy of "do one thing well," but at the OS level.
The kernel never needed any of that. The kernel's job is to manage processes, memory, and devices. Everything else is userland convention. Containers make that separation explicit. You can run a process on the Linux kernel with no userland at all. That's not a hack — it's the design.
What's the weirdest minimal container you've seen in production?
A team ran a DNS resolver in a scratch container. The binary was a custom Go build implementing a caching DNS forwarder. No shell, no utilities. It handled something like fifty thousand queries per second. The entire container was smaller than the Ubuntu base image they'd been using before they even installed BIND. And because it was scratch, the only thing that could break was their own code. No CVE in some random library was going to take down their DNS.
That's the dream. Your infrastructure is just your code, running directly on the kernel, with nothing in between to surprise you.
It's increasingly achievable. Go and Rust both compile to static binaries by default now. Ten years ago, static linking was a pain — you'd fight with library paths and symbol resolution. Now go build just does it. The ecosystem has moved toward minimalism.
Let's address the misconception I know is coming. Someone listening is thinking "Alpine is just BusyBox with a package manager.
Alpine uses BusyBox as its userland, yes. But it also replaces glibc with musl libc, and that's the bigger change. musl is a completely independent implementation of the C standard library — not a fork, not a stripped-down glibc. It's written from scratch with different design goals. Smaller, simpler, stricter standards compliance. But because it's different, binaries compiled against glibc don't always work. The dynamic linker expects different symbol versions. Thread-local storage works differently. The memory allocator has different performance characteristics.
When someone says "my Python app doesn't work on Alpine," it's usually not a BusyBox problem. It's a musl problem.
The classic failure mode is a precompiled wheel built on a glibc system. pip install grabs the wheel, tries to load it, and the dynamic linker fails because it can't find `GLIBC_2.The fix is to install the Alpine-packaged version or compile from source. But that's friction, and not every team wants to deal with it.
Which is why Debian-slim exists. It's the "I give up, just give me glibc and apt" option.
That's fine. The point isn't to be a minimalist purist. The point is to make conscious choices about what you're shipping. If you need glibc, use a glibc-based image. But know that's the reason you're at that rung, and understand what you're trading off.
You mentioned docker history and dive as tools for auditing image bloat. How would someone actually do that audit?
docker history shows you every layer in your image and how much space each one adds. You'd be shocked how often you see a layer that's "install build-essential" adding three hundred megabytes, and that layer is in the final image because someone didn't use a multi-stage build. dive is a third-party tool that gives you a more interactive view — what files were added in each layer and where the wasted space is. Between those two, you can usually find the bloat in about five minutes.
The fix is usually a multi-stage build.
Build in a fat image, copy the artifact to a slim image. It's the single highest-leverage Docker optimization and it's been supported since Docker seventeen point oh five. There's no excuse not to use it.
We've climbed the whole ladder. Scratch at the bottom — kernel and a static binary. BusyBox at one megabyte — three hundred utilities, no package manager. Alpine at five megabytes — BusyBox plus musl plus apk. Distroless — runtime only, no shell. Debian-slim — glibc and apt, stripped down. And full Ubuntu at the top — everything including the kitchen sink.
The right answer depends on your application. The important thing is to know the ladder exists and to climb down it as far as your dependencies allow. Every rung you descend reduces your attack surface, speeds up your deployments, and simplifies your compliance story.
One open question — where does this go next? We've got WASM and unikernels emerging as even more minimal alternatives. Does the BusyBox-style minimal container become obsolete?
I don't think so, not for a long time. WASM and unikernels solve a narrower problem. They're great for edge functions, serverless, highly constrained environments. But the Docker and Kubernetes ecosystem is built around Linux containers. The tooling, the orchestration, the monitoring, the debugging workflows — all of it assumes a Linux process model. BusyBox and Alpine and distroless fit into that model perfectly. They're not competing with it. They're the most efficient way to use it.
For the foreseeable future, the ladder holds.
The ladder holds. And most teams are still way higher up it than they need to be. So here's my challenge to anyone listening — pull your most-used Docker image, check the base, and ask yourself honestly: do I really need all of that?
Good place to land.
And now: Hilbert's daily fun fact.
Hilbert: In the early fifteen hundreds, the guild of pin-makers in Nuremberg required apprentices to produce a "masterpiece" pin entirely without the use of tongs — using only their fingers — as proof of skill. The ritual was called the Fingerprobe, and failing it meant the apprentice could never open his own workshop. The English word "probe" traces back through this same Germanic root, which originally meant "to test by touch.
...huh. Fingerprobe.
I'm not sure what to do with that information but I'm glad I have it.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. If you enjoyed this, pull your Docker images and audit your base layers — and then tell us what you found. Email the show at show at my weird prompts dot com.
We'll be back next week.
