The argument

Linux does not have to become more complicated every year.

Saphira exists because a general-purpose Linux system should still be something one person can hold in their head.

SIMPLE DOES NOT MEAN SMALL-MINDED

Saphira runs nginx, PHP, Node.js, Python, MariaDB, OpenSSH and GCC. It has been used for real server and development work, including modern development tooling. What it does not do is bury the operating-system plumbing under layers that only make sense to the tool that generated them.

Simplicity is an engineering constraint applied deliberately, not a list of features we forgot. Every layer removed is a layer that cannot fail in a way nobody can explain.

It's so Simple it Hurts.

What that means in practice

Keep the system understandable

You can read the boot path, the init scripts and the package manifests without tooling.

Keep boot simple

GRUB, a kernel, an init. No orchestration of an orchestrator.

Keep service management simple

OpenRC scripts are shell. Dependencies are declared. Failures are visible.

musl libc

Small, strict and predictable. Fewer surprises, smaller binaries, clearer errors.

APK packaging

Fast, atomic and honest about what it is doing to your filesystem.

Minimise unnecessary layers

If a component only exists to manage another component, it needs to justify itself.

Strong package boundaries

Split packages, explicit dependencies, no accidental transitive surprises.

Build from controlled sources

Every source input is pinned and hashed before it enters the build.

Reproducible build system

Staged, scripted and repeatable — a clean rebuild is routine, not an event.

Make failures visible

Loud, early and in a log you can find. Silent degradation is a bug.

Know what is installed

Manifests and fingerprints mean the package list is an answer, not a guess.

Capable, not minimal for its own sake

Servers, databases, compilers and development tooling all run today.

Built from scratch, in stages

Saphira is not a respin. It is bootstrapped from source through a staged build.

Stage0
Bootstrap toolchain
A minimal cross toolchain built from pinned sources, used only to build the next stage.
Stage1
Native toolchain
A self-hosting compiler and binutils built by Stage0, then rebuilt by themselves.
Stage2
Root filesystem
Core libraries and userland assembled into a clean root, with musl at the base.
Stage3
Image creation
The Stage3 build creates the base build image from which the Stage4 package build is run.
Stage4
Package builds
The Stage4 build uses the base image to build the package set; stage4packages contains the package profiles produced for the repository.
Validation
Boot and prove
The image is booted, packages are installed, and real workloads are exercised before publication.

Technical details

Source inputs are pinned by URL and hash before the build starts. Each stage runs in a clean environment and produces artefacts consumed only by the next stage, so no host toolchain leaks into the final system.

Packages carry manifests and fingerprints, which drive the dependency graph and allow targeted rebuilds: change one library and only its dependents are rebuilt. A full clean rebuild remains the reference — it is how the GCC 16.1.0 toolchain migration is validated.

Image generation is scripted from the catalogue, not from a hand-maintained filesystem, so an image is always reproducible from the package set that made it.

Frequently asked questions

Is Saphira based on Alpine?: No. It uses some familiar technologies such as musl and APK, but Saphira has its own staged build system, package catalogue and distribution architecture.
Why musl?: It is small, strict and predictable. Errors surface early, binaries stay lean, and the library itself is small enough to read.
Why OpenRC?: Service management should be legible. OpenRC scripts are shell with declared dependencies — you can follow what starts, in what order, and why it failed.
Why APK?: It is fast, atomic and honest about what it changes on disk, with signed indexes and strong package boundaries.
Why x86-64-v3?: It gives the compiler a modern instruction set to work with (AVX2 class, roughly 2015 CPUs onwards) without maintaining fallbacks for hardware nobody is deploying into new VMs.
Does it run on bare metal?: Bare metal is not the initial target. The Earlybird image is designed and tested for virtual machines with VirtIO devices.
Does it run on VMware?: It is expected to, where compatible device models are available. KVM/QEMU is the primary tested target; broader hypervisor testing is on the roadmap.
Does it run on VirtualBox?: Likely yes with VirtIO controllers selected, but it is not certified. Tell us how you get on.
Why is this marked beta?: Because it is. It boots, installs packages and runs real workloads, but the catalogue and toolchain are still being corrected. Beta means there may still be teeth.
Where are the packages?: In the Saphira APK repository at packages.akadata.ltd/saphira/main — around 481 packages for x86_64, browsable from the Packages page.
How do I verify a download?: Run sha256sum -c saphira.tar.xz.sha256 against the published checksum file before booting the image.
Can I contribute?: Yes. Bug reports and packaging requests are the most useful contributions right now — use the bug and contact pages.
Is Saphira itself running this website?: Yes. Saphira is hosting Saphira: a real Node.js SSR application on a Saphira Linux VM, with packages installed from the same repository you would use.

See the full feature set →