Skip Navigation

Overview of Alpine Linux

Alpine Linux is a lightweight and security-focused Linux distribution that supports a wide variety of systems and architectures. It can be used for a variety of purposes, including containers, appliances, servers, desktops, laptops, Raspberry Pis, other single-board computers, and many other things. This document explains some of Alpine’s features and capabilities, as well as differences between Alpine and other distributions.

Page Contents

Basic Design

Alpine Linux is a distribution that is widely used in Docker1 containers due to its compact size and lightweight design. However, Alpine Linux is also fully usable as a general-purpose Linux distribution. Its primary differences from other distributions are that it uses the musl2 C library instead of the GNU C library (glibc), and that its system management software is OpenRC3 instead of systemd.

System management on Alpine Linux is accomplished by editing configuration files and using distribution-provided shell scripts that automate common tasks. For native packages, Alpine uses its custom-built Alpine Package Keeper (APK) package manager, which uses package files ending in the .apk extension.4 These packages are not the same as Android packages, which unfortunately also use the .apk extension, despite the first release of Alpine Linux predating Android by about 3 years.

Alpine Linux is a security-focused distribution with a relatively small attack surface compared to other distributions, due directly to the relatively smaller size of its installation. Binary packages on Alpine Linux are also compiled with various security features enabled by default, including support for address randomization (via position-independent executables) and stack-smashing protection.5

Small Installation Size

Alpine Linux is optimized for small installation size using a combination of packaging techniques and compiler optimizations that support generating smaller binary files. This smaller size results in an Alpine Linux installation requiring less space on persistent storage. While storage has become inexpensive in recent years, the move toward flash storage has made it desirable to leave a relatively large portion of the storage device unused for both performance and endurance reasons. As data are written to persistent flash storage, wear-leveling algorithms move the data around the physical storage media in order to avoid writing to one region of flash memory repeatedly, which can cause premature failure of the storage device. Wear leveling tends to be more effective when free space is readily available for new data writes, since it reduces the need to move around existing data (a phenomenon known as write amplification).

In addition to optimizing performance and reducing wear on solid-state media, Alpine Linux can also fit onto appliances that have extremely limited persistent storage, such as network devices. In this application, a complete installation can fit into a space under 150 MiB in size. When used in containers, which do not require a kernel and firmware, Alpine Linux can fit into around 8 MiB of space.5

The musl C Library

Unlike most Linux distributions, Alpine Linux uses the musl2 C library instead of the GNU C library (glibc)6. The GNU C Library dates back to the late 1980s and has accumulated some technical debt, including some non-standard deviations from the C programming specification (which are sometimes marketed as “features”).7 On the other hand, musl is a much newer implementation (first released in 2011) that is intended to be small, portable, and standards-conforming.2

Since most software on a Linux system is compiled from source, either by the distribution maintainer or the end user, it is normally possible to build applications against musl instead of glibc. However, sometimes it is necessary to run closed-source, commercial software that has been compiled against glibc. Without some compatibility tools, this software will not simply run on Alpine Linux, since it won’t be able to find its required C library.

Several solutions exist for running this kind of software. The gcompat library8 can be loaded (by setting the LD_PRELOAD environment variable) to supply the extra library routines that glibc-compiled software expects. Alternatively, it is possible to set up a chroot environment with a glibc-based distribution, and Alpine even provides scripts to use Arch Linux9 for this purpose. On desktop systems, glibc-based software is often available via Flatpak,10 while servers may be able to use glibc-dependent software inside a Docker1 container with a glibc-based distribution as its base.

Lack of systemd

The majority of Linux distributions have adopted systemd as their runtime initialization system and service manager.11 Had the systemd developers simply focused on an initialization and service management system using a loosely coupled, highly cohesive design, there might not be any advantage to omitting it from the system. However, the systemd developers instead decided to add unrelated functionality that goes far beyond system initialization and service management. This functionality is all over the place in terms of scope, including network management,12 DNS resolution with a history of security vulnerabilities,13 a totally unnecessary Network Time Protocol client,14 bootloader management,15 and even a replacement for home directories that allows them to be mounted in arbitrary locations for the subset of users who actually need this “feature.”16 The lead author of systemd also hasn’t done the project any favors by his dismissive attitude toward security vulnerabilities, leading to the project receiving the lamest vendor Pwnie Award in 2017 for making software that is easy to compromise.17

Linux systems using systemd have experienced various bugs and other kinds of breakage over the years.18 A major issue with the tightly coupled, non-cohesive design of systemd is that it is a massive code base that exceeded 1.2 million lines in 201919 and has only grown since. Most or all of this code runs as the root user with elevated privileges, making it a ripe target for exploits and attacks. A great deal of it also runs as PID 1 on the system, which is an especially privileged process started by the Linux kernel. If PID 1 crashes, the Linux kernel panics, resulting in a hard system lockup. Both software bugs and exploits against systemd are thus excellent candidates for launching denial of service attacks.

Alpine Linux uses OpenRC,3 which is certainly not without its own faults. However, the amount of code running in PID 1 is significantly smaller, and the OpenRC project is far more focused on delivering an initialization and service management system. All the other bells and whistles can be added (if they are even necessary for a given system) using other software packages.

Three Modes of Operation

Alpine Linux is capable of running in 3 different “modes”:

The diskless and data disk modes are useful for situations in which a relatively static version of Alpine Linux will be running on an appliance or server. Since writes to the storage device are significantly more limited in these modes, they are ideal for running from inexpensive flash memory. On the flip side, Alpine Linux is a bit more challenging to update, maintain, and customize using these two modes, since it is necessary to remember to run scripts after making changes.

System Disk mode works like any other Linux distribution once installed. Updates are made in place, files are saved on the persistent storage (hard drive, SSD, etc.), and no special steps are required when performing maintenance. The downsides to sys mode are the same as any regular Linux distribution: cruft accumulates in the persistent storage, it is easy to make a change and forget what you changed, and there is more wear on flash storage devices.

Notes and References


  1. Docker

  2. musl libc

  3. The OpenRC init system

  4. Alpine Package Keeper

  5. About Alpine Linux

  6. GNU C Library (glibc)

  7. Functional differences from glibc. musl libc wiki. 

  8. gcompat

  9. Arch Linux

  10. Flatpak

  11. systemd

  12. systemd-networkd. ArchWiki. 

  13. Shaun Nichols. “Don’t panic, but Linux’s Systemd can be pwned via an evil DNS query.” The Register. June 29, 2017. 

  14. systemd-timesyncd. ArchWiki. 

  15. systemd-boot. ArchWiki. 

  16. systemd-homed. ArchWiki. 

  17. Iain Thomson. “Systemd wins top gong for ‘lamest vendor’ in Pwnie security awards.” The Register. July 28, 2017. 

  18. No systemd

  19. Michael Larabel. “systemd Clocks In At More Than 1.2 Million Lines”. Phoronix. May 21, 2019. 

  20. Installation. Alpine Linux Wiki.