Saphira Linux · an AKADATA project

About Saphira Linux

The design principles, server roles, deliberate exclusions, and release lineage behind the distribution.

Saphira, the Version 0 mascot
Technical preview

Saphira Linux

Saphira Linux has a home of its own

Saphira Linux is AKADATA’s source-built, musl/OpenRC server distribution for self-hosted infrastructure. Development, downloads, documentation, packages and the Dragon feature sets now live on the dedicated Saphira Linux website.

Visit Saphira Linux saphira.vm2.uk


Why it exists

Saphira Linux is booting. It's so simple it hurts.

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.

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 Akadata. /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 Akadata 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 X11. No Wayland. Every package on a Saphira machine serves a server purpose. There is no graphical environment. The console is 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.


Release lineage

Saphira Linux releases

Saphira Linux is one deliberately simple server operating system. Every release uses musl libc, OpenRC, a proper non‑usrmerged filesystem and an x86-64-v3 baseline.

Release names come from dragons. They do not represent editions, performance tiers, storage roles or specialised products.

  • Version 0 — Saphira: The first Saphira Linux release.
  • Version 1 — Vermithrax: Planned release name.
  • Version 2 — Ancalagon: Planned release name.
  • Version 3 — Smaug: Planned release name.

The architecture and build documentation are public now. Images remain gated until acceptance, measured sizes, checksums, detached signatures, signing identity, and release notes agree.

View release status