This episode traces the origins of Alpine Linux back to 2010 as a distro for small routers, the Small Simple Secure philosophy, and its major release history. You'll also understand why its minimal image size, low RAM footprint, and security design make Alpine a popular choice for containers and firewalls.

Before writing any configuration, it's important to understand where Alpine Linux comes from and why its design looks "different" from other distros. Episode 1 traces the birth history of Alpine, the philosophy that shaped it, its major release history, and the practical reasons why so many people now need it.
A question that always comes up: why choose Alpine over Ubuntu or Debian? The answer isn't about having the newest version, but three design pillars: small, simple, and secure. Let's unpack each of them one by one.
Alpine Linux was born in 2010 out of a small router project that wanted an extremely compact yet still maintainable Linux system. The project grew out of a base system called LEAF (Linux Embedded Appliance Framework), and was then rebuilt into the standalone distro we know today. Its original focus was indeed embedded and networking devices: routers, firewalls, and small appliances.
That's why Alpine isn't built on the heavy GNU toolchain. Instead, Alpine uses musl libc as its C library and BusyBox as its utility set — two fundamental decisions that persist to this day and that we'll examine in episode 2.
Alpine Linux's official motto is "Small. Simple. Secure." These three words aren't just a slogan; they're design criteria:
Choosing musl and BusyBox reduces size while also reducing the amount of exploitable code. This is the main reason Alpine is often used as a secure container base image.
Beyond that, Alpine follows a disciplined semi-annual release model: a new version ships around May and December, with a support cycle of about two years per major version. That means you can always use a fresh stable version without waiting too long, and you have plenty of time to plan migration between versions. This release behavior is also why so many cloud tools and container images use Alpine as their foundation.
Alpine ships a major version twice a year, and some of them bring significant changes:
linux-edge with linux-stable.Besides the releases above, Alpine also maintains an always-active edge branch: where the latest package development happens before being pushed into the next stable release. For general users, edge is useful for sampling new features, but for production you should stay on a stable release.
Check your release version with the following commands:
cat /etc/alpine-release
apk --version
uname -rFrom the apk --version output, you can see whether you're using apk v2 or v3 — we cover this difference fully in episode 4. For context, Alpine 3.23 and 3.24 use apk v3, while all releases before 3.23 use apk v2. Even though the everyday command syntax is the same, the index format and dependency resolution speed differ significantly.
It's also important to note that every Alpine major version is supported for about two years. This means you can stay on one version for a long time, but you still need to plan the migration before the support window ends. The endoflife.date website always carries Alpine's release and end-of-support schedule for production planning.
Alpine is one of the most resource-efficient distros. The alpine:latest container image is only about 5 MB, so image pulls are fast, disk usage is low, and container cold-start times are short. On both physical servers and VMs, Alpine's RAM requirements are very low — it runs comfortably on devices with 256 MB of RAM. This makes it a top choice for cloud, edge, and embedded devices.
Security in Alpine is designed in from the start, not bolted on later:
-fstack-protector-strong and PIE by default.Check the system's basic security with:
id
ps aux | wc -lThe output of ps aux | wc -l on Alpine is usually far fewer lines than on systemd-based distros because so few components are running. Also try ps aux --sort=-rss | head -5 to see which processes use the most memory — on Alpine you'll notice there are no resource-hungry daemons.
Alpine's two biggest use cases are:
alpine:latest is used by millions of containers worldwide because it's small and fast.In episode 10 we'll build an nftables firewall, and in episode 16 we'll use Alpine as a base image. Both of these use cases come directly from the design decisions covered in episode 1.
For developers coming from the container world, there's one more practical reason: Alpine uses lightweight namespaces and tooling, so starting a container takes very little time and resources. When you run hundreds of containers on a single node, saving a few MB per container quickly accumulates into big savings in memory and disk.
Tip
If you're coming from Ubuntu or Debian, don't be surprised to find no systemctl or sudo in Alpine. This isn't a shortcoming, but a design decision we'll understand in episodes 5 and 6.
Episode 1 explains where Alpine comes from and why its design is unique: born in 2010 for small routers, built on musl libc and BusyBox, guided by the Small Simple Secure motto, and now the distro of choice for containers and network devices.
Key takeaways:
In the next episode, episode 2, we'll discuss Alpine's core concepts and main architecture — the deep differences between musl libc and glibc, how BusyBox and its applets work, apk's architecture with the main, community, and testing repositories, and the role of the linux-lts and linux-stable kernels.