Alpine is probably already running on your machines. It is the base of an enormous number of container images, because the official one is under 4 MB compressed — an order of magnitude smaller than a slimmed-down Debian. But it is not a small Debian. It replaces three components most distributions share, and each replacement has consequences.
What is actually different
| Component | Most distributions | Alpine |
|---|---|---|
| C library | glibc | musl |
| Core utilities | GNU coreutils | busybox |
| Init | systemd | OpenRC |
| Packages | apt / dnf / pacman | apk |
The C library is the one that matters. Almost every program on a Linux system is linked against it, so swapping glibc for musl means every binary must be built for Alpine specifically — which is why a program downloaded as a prebuilt Linux binary often simply will not run there.
busybox is a milder difference but a real one: one small binary providing cut-down versions of the usual commands. Most of the time you will not notice; occasionally a flag you expect is missing, and the fix is apk add coreutils findutils grep to get the GNU versions.
Releases and the support window people misread
Alpine cuts a stable branch from edge roughly every six months. The current stable release is 3.24, from June 2026, with security support until June 2028. Older branches remain supported for about two years each.
That two-year window only covers the main repository. Packages in community — which is where a great deal of what you actually install lives — are supported only until the next stable release, about six months. If your production image pulls from community and you planned to stay on one Alpine version for two years, you are unpatched for eighteen months of it. Check which repository each package comes from before you rely on the longer number.
apk
Alpine’s package manager is noticeably faster than apt or dnf, largely because there is so much less of everything. Version 3 of the tooling arrived with Alpine 3.23, bringing a new index format and Zstd compression — but the commands you already know were deliberately kept working.
apk update # refresh the index
apk add nginx curl # install
apk del nginx # remove
apk upgrade # upgrade everything
apk info -L nginx # what a package installed
apk query nginx # newer, with JSON and YAML output
apk add --no-cache curl # in a Dockerfile: never leaves a cache behind--no-cache is the one to remember for images. Without it you need an rm -rf /var/cache/apk/* in the same layer, and forgetting that is how a 5 MB base image becomes a 60 MB one.
Repositories are configured in /etc/apk/repositories, one URL per line. Mixing an edge line into a stable install is possible and is the usual way people break an Alpine system — the same caution as any other mixed-source install.
The musl problems you will actually hit
musl is not worse than glibc. It is smaller, stricter and different, and the differences surface in a handful of predictable places.
- DNS is queried in parallel. musl asks every nameserver at once and uses the first answer; glibc asks them in order. On a split-horizon setup — an internal resolver plus a public one — that means intermittent, maddening failures to resolve internal names, depending on which server replies first.
- Search domains behave differently. A name that meets the
ndotsthreshold is tried only as written, with no fallback through the search list. This is the root of the well-known Kubernetes problem where loweringndotsbreaks Alpine pods while Debian pods carry on working. - Thread stacks are small. 128 KB by default against glibc’s multiple megabytes. Software ported from a glibc system can overflow its stack and crash in ways that look like memory corruption.
- Prebuilt binaries usually will not run. Anything shipped as a glibc binary — vendor agents, proprietary tools, older JDK builds — needs a musl build or a compatibility shim. Java is workable today: Alpine ships OpenJDK, and musl-native JDK images are published.
dlclosedoes nothing, and the default locale isC.UTF-8rather thanC. Both are occasionally the answer to a puzzling bug report.
None of these are reasons to avoid Alpine. They are reasons to recognise the symptom — “it works on Debian, not on Alpine” — and know where to look first.
The Python question
Alpine used to be a bad choice for Python images. Binary wheels on PyPI were built for glibc, so pip install fell back to compiling from source — turning a thirty-second build into half an hour and producing a larger image than the Debian-based one, because the compilers had to come along.
That is now mostly fixed. The musllinux wheel standard exists and major packages including NumPy, Pandas and Matplotlib publish them. “Mostly” is doing real work in that sentence, though: coverage is not universal, and it is thinner on aarch64 than on x86-64. Before committing a project to Alpine, build the image once and see. If one dependency has no musl wheel, you get the old behaviour back in full.
Outside containers
Alpine on real hardware has one genuinely unusual feature: it can run entirely from RAM. The installer offers three modes, and the first two are not options most distributions have.
| Mode | What it does |
|---|---|
| diskless | Runs from RAM; you save configuration deliberately with lbu commit. Nothing else persists. |
| data | System in RAM, /var on disk. Good for a router or firewall that writes logs. |
| sys | A conventional install to disk, like any other distribution. |
Diskless mode makes Alpine excellent on flash media and single-board computers, where writes wear the storage out — the same problem that afflicts SD cards in a Raspberry Pi. Run setup-alpine to install; it asks about a dozen questions and is finished in a couple of minutes. Services are managed with rc-service and rc-update rather than systemctl.
It will run in 128 MB of RAM, which makes it one of the few current distributions that is genuinely comfortable on hardware everything else has abandoned.
Who should run Alpine
- Anyone building container images where size and attack surface matter — fewer packages means fewer things to patch.
- Routers, firewalls, VPN endpoints and appliances, especially on flash storage.
- Very small VMs, and hardware with a few hundred megabytes of RAM.
- People who want to see what a Linux system looks like without systemd or GNU userland, and are curious rather than annoyed about it.
Who should not
- Anyone wanting a desktop. It is possible and it is not the point. Run Debian or Linux Mint.
- Anyone who needs vendor software. Monitoring agents, database clients and licensed tools are shipped as glibc binaries. Use Debian or Rocky and stop fighting.
- Anyone who wanted a small image but does not need one. A
-slimDebian image is a few tens of megabytes, behaves exactly like every other machine you own, and removes this entire page from your life. Choose Alpine when the size or the reduced surface is worth something to you — not by reflex. - Teams whose debugging time is expensive. A weekly “why does this only fail in the Alpine image” is a real cost. It is often the right cost; it is never zero.
Related
- Containers — what an image actually is, and why base image size matters less than it looks
- How Packages Work — sonames, glibc compatibility and why binaries are not portable
- Debian — the conventional small server, and the usual alternative
- Docker Basics — building images, including what
--no-cachesaves you