About Saphira Linux

Why it exists

Saphira Linux is booting — Made in England.

Saphira Linux is a from‑source, deterministic distribution built around musl libc. Every binary is compiled on your machine from pinned source archives. There are no prebuilt packages to install and nothing arrives without a recorded origin. The cost is build time. What you get back is a machine whose contents you can account for.

Saphira Linux keeps OpenRC as its original boot path, while Saphira-D has booted systemd on Linux 7.2.2. An in-place upgrade can add the systemd path without rebuilding the whole operating system; init=/sbin/openrc-init still selects OpenRC on the same machine. musl libc and systemd are optional choices, not a forced migration.

systemd-nspawn is working, with user-mode operation approaching validation. Saphira is booted on hardware and virtual platforms; ZFS version 5000 has been tested and remains under test. pppd and rp-pppoe are added and await a planned maintenance-window test.

The package subsystem uses apk-tools and a cports‑inspired recipe tree, but this is not Alpine Linux, and it is not Linux From Scratch. It is a musl‑based server distribution with its own toolchain, its own build controller, and its own standards contract. It assumes an operator who wants to know how the system was assembled, and it is not built to be the quickest route to a running server.

Server roles

The Saphira server stack

Version 0, Saphira, is the first Saphira Linux release. The package set covers the roles a production server actually fills. Anything outside that set is built by the operator into /usr/local or packaged into Stage4.

Deployment guides for each role, from starting the daemon through production configuration, are on the Server stacks page.

Runtime languages

Runtimes and compilers

Perl 5, Python 3, Node.js, and PHP 8.5 are built from source, each with its package manager (CPAN, pip, npm) installing into /usr/local. GCC 16.1.0 is the same compiler that built the distribution, so C and C++ can be compiled directly on the machine. LLVM, Clang and libclang 22.1.8, Rust 1.97.1 and bindgen 0.72.1 are also packaged in Stage4.

Full walkthroughs for each runtime (CPAN shell, virtual environments, npm workflow, and compilation) are on the Runtime stack page.

The boundary

/usr is Saphira. /usr/local is yours.

The distribution manages /usr. Everything underneath it is built by the deterministic toolchain from pinned sources. /usr/local is the operator's space. CPAN modules land in /usr/local/lib/perl5. pip packages land in /usr/local/lib/python3 or your virtual environments. npm global installs go to /usr/local/lib/node_modules. Compiled binaries go to /usr/local/bin.

/usr/local can be mounted from a separate volume, copied to another Saphira machine, or backed up independently. Where two servers share the same Saphira base, a /usr/local tree moved between them does not need to be reinstalled or recompiled, because the library paths and ABI underneath it are identical.

Deliberate exclusions

What is not here, and why

No PAM. Pluggable Authentication Modules are not installed. This is a server operating system and its own services do not require PAM. If your application requires PAM, build it into /usr/local. The compiler and headers are present.

No NFS. No SMB. There is no NFS client or server and no Samba. Use rsync, or an rsync daemon, to synchronise files, and scp or sftp over SSH to copy them. If you need NFS or SMB, build them into /usr/local or package them into Stage4.

No /usr merge. Saphira Linux is deliberately non‑usrmerged. /bin, /sbin, /usr/bin, and /usr/sbin are distinct directories. Early‑boot OpenRC executables live in /sbin. Init scripts use #!/sbin/openrc-run. This is the traditional FHS contract; we intend to keep it.

No desktop. No graphical management stack. No X11. No Wayland. Every package on a Saphira machine serves a server purpose. libvirtd is being added for headless hypervisor operation, not for a graphical desktop. The console, SSH, and APIs are the interface.

Privilege and provenance

Ownership all the way down

Compilation runs as the invoking builder. Root privilege is restricted to installation into the target rootfs. Installed files become root:root while source and build trees stay builder‑owned.

Completion markers are accepted only when the recorded build policy and the Stage2‑input fingerprints match, so completion evidence cannot be written unless the unit actually completed under the policy it claims. Every binary traces back to a pinned source archive and the fixed reproducibility epoch 1753401600.

Each unit is validated as it is built, and the tree carries standing tests for source and version parity, archive digests, dependency and catalogue consistency, toolchain ownership, package fingerprints, profile exclusions, network configuration, and service accounts.

Generation lineage

One Dragon, a repeatable test loop

Saphira v0.1 is the first Dragon. It made Egg; Egg made Hatchling; Hatchling hatched Hatched. This is the process by which the project builds and proves packages, not a ladder of commercial editions.

• Egg: builds the next packages while the trusted Saphira system remains intact.
• Hatchling: is the disposable package-validation environment for installs, upgrades, ownership and boot tests.
• Hatched: stress-tests the assembled system and package set. A fault returns to Egg, then goes through the loop again.
• Spawn of Saphira: is in progress: Saphira building Saphira with the complete native tooling and a proper installer.

This loop serves the original OpenRC Saphira and the systemd Saphira-D sibling. It is how the project moves work forward without claiming that unfinished work is released.