Direction
Roadmap
What is finished, what is being built, what comes next, and what Saphira deliberately has no intention of becoming.
-
Complete
Earlybird Beta image and public repository
A bootable Saphira image, 481 packages, and a public APK repository that real systems can install from.
-
In progress
GCC 16.2.0 toolchain migration
Rebuilding the native compiler stack around GCC 16.2.0, with broader language support and musl-specific compatibility work.
-
In progress
Full clean reproducibility rebuild
The staged, scripted build system makes a clean full rebuild a routine, reproducible operation; the GCC 16.2.0 milestone already exercised the full Stage0 → Stage4 path. The current work is completing the full distribution rebuild on 16.2.0 and keeping every stage reproducible.
-
In progress
Package-quality fixes from real use
Dependencies, package splits, runtime libraries, service scripts and configuration corrected as real workloads expose problems.
-
In progress
Expanded compiler and language support
C, C++, Fortran, Ada, Go and other GCC-supported languages are being brought into the native toolchain rather than treated as optional afterthoughts.
-
In progress
Package validation
More package-level smoke testing, runtime checks and dependency validation before packages are considered complete.
-
In progress
Installation tooling
A guided TUI installation path for installing Saphira onto a machine without requiring users to manually import a prepared disk image.
-
Planned
Virtualisation compatibility
Formal testing beyond KVM/QEMU, including other common hypervisors where the required virtual hardware interfaces are available.
-
Planned
Physical hardware support
Saphira is intended to run beyond virtual machines. Earlybird itself remains VM-first, but physical x86-64 systems and the broader architecture profiles, older x86-64 generations, 32-bit x86 and AArch64, are active roadmap directions. Hardware installation, storage and network discovery will expand as testing on real machines grows.
-
In progress
NVIDIA Open Kernel Modules
nvidia-open 610.57.04 is now staged in the hatchling repository. On Hatchling, the modules load and NVRM initialises; with no GPU present, PCI probing reports that fact and the driver unwinds cleanly. The next proof is the prepared USB-safe test with the RTX 3060 / GA106 on Homer. CUDA and NVIDIA userspace remain a container design, not a tested Saphira feature.
-
In progress
Saphira administration tools
Small inspectable tools for web, DNS, mail and other server administration without introducing a proprietary control plane.
-
In progress
mailDragon
Packaging and refining the self-hosted mail stack, its shell-based administration and the supporting documentation for operating mail on infrastructure you control.
-
In progress
dnsDragon
Expanding the practical BIND 9 and DNSSEC guidance, with room for future administration tooling while keeping the underlying DNS configuration understandable.
-
In progress
vpnDragon
Building out the WireGuard guide and its future management path: first-client setup, peer lifecycle, QR configuration and routed IPv6 connectivity on networks you control.
-
In progress
aiDragon
A working agent-led Saphira workspace. Agents and models are installed or used through their existing services and APIs, while native CPU inference is now also proven with BitNet on Hatchling. GPU CUDA remains a separate, untested container design rather than a requirement for local AI work.
-
In progress
Native BitNet CPU inference
bitnet-cpp is shipped in hatchling as a native musl/x86-64-v3 package. CPU inference, the system-wide Python 3.14 helper tooling, and official I2_S GGUF operation without setup_env.py are proven on Hatchling. Models are available separately rather than bundled in the APK; the reference 2B model is deliberately small and does not represent larger or smarter models.
-
In progress
databaseDragon
A coherent relational-database feature set for SQLite, MariaDB and PostgreSQL, with public management helpers planned but not yet released.
-
In progress
Documentation
Installation, administration, packaging, networking and recovery documentation written for people who actually operate servers.
-
In Progress
Package catalogue expansion
More useful server software, developer tooling and infrastructure packages added as they are requested and can be maintained properly.
Architecture support
Architecture is not the same thing as a machine profile, and a builder profile is not the same thing as a tested image.
Saphira's design is intentionally understandable: you should be able to follow it from toolchain to boot to service startup without the machine being hidden behind layer after layer of abstraction. Simplicity is an engineering constraint, not a lack of ambition. Every piece of architecture work below has to justify itself against that same idea, and against the real hardware we keep on hand to test it.
Why more than one x86-64 profile?
x86-64-v3 is the normal modern default because modern hardware should be allowed to compile against a modern instruction set. But that is not the same as forcing every machine down to one common denominator. A Sandy Bridge machine should not require the same binary baseline as a new server, and the new server should not be compiled down to Sandy Bridge merely so one image can claim to fit both. The builder is being designed so v1, v2, v3 and v4 are selectable compiler baselines; different builds, not different distributions.
Why keep older hardware?
Because a useful machine does not become useless simply because another CPU generation appeared. We still run Nehalem-era hardware here, and Sandy Bridge and Ivy Bridge machines remain widespread and genuinely capable of focused server work. Keeping them usable is a practical decision about machines we can actually test; not retro-computing nostalgia.
Architecture versus machine
An architecture is a userspace ABI; i586-saphira-linux-musl or aarch64-saphira-linux-musl. A machine profile is the kernel and tuning beneath it. PC Engines WRAP / Geode SC1100 is a machine profile under the i586 userspace target; Raspberry Pi 4 is a machine profile under aarch64. The site should not turn every board into another distribution.
Builder capability, tested hardware, published image
These are three separate states. The builder can know about a profile; we can have validated it on real hardware; and we can ship a published image. x86-64-v4 is the clearest example: the builder is intended to support it, but we do not yet have v4 hardware here to validate native builds and runtime, so no tested or regularly published v4 image is implied. We would rather say 'not tested here yet' than dress a compiler option up as a support claim.
This is not a theoretical architecture matrix: we have Nehalem, Sandy Bridge, Ivy Bridge, PC Engines WRAP, Raspberry Pi Zero 2 W and Pi 4 8 GB hardware on hand to validate it. New hardware is not held back to preserve old hardware, and old hardware is not discarded merely to advance the default baseline; different build profiles let us do both.
x86-64-v3
The normal modern Saphira target for current servers, virtual machines and modern x86 systems. Saphira does not force every build down to the oldest common CPU baseline.
x86-64-v2
A profile for older but still capable x86-64 hardware, including Nehalem, Sandy Bridge and Ivy Bridge generation systems. Builder support is planned; this is not yet a selectable released profile.
x86-64-v1
The broadest x86-64 compatibility profile intended for the released builder. It will produce a distinct build profile from x86-64-v3 rather than changing Saphira's modern default.
x86-64-v4
The builder is intended to support this profile, but suitable x86-64-v4 hardware is not currently available for native build and runtime validation. No officially tested or regularly published x86-64-v4 image is implied.
i686
A 32-bit x86 userspace target being added. It is not marked complete or generally supported yet.
i586
A genuine i586 userspace baseline is being developed rather than silently requiring i686, SSE or SSE2.
PC Engines WRAP / Geode SC1100
A planned machine-specific kernel profile beneath the i586 Saphira userspace target. This is not another architecture or userspace ABI.
AArch64 / ARM64
ARM architecture work begins with the source-built aarch64-saphira-linux-musl userspace target. Architecture capability remains separate from machine validation.
Raspberry Pi 4
The first planned ARM machine target, represented as arch=aarch64 and machine=raspberry-pi-4. Saphira has not yet been claimed as built and booted on real Pi 4 hardware.
Saphira-d
An experimental Saphira sibling using musl + systemd alongside the existing musl + OpenRC edition.
Saphira-d is in development
Boot validated · cleanup pending24 August 2026 · first boot report
Saphira-d has booted systemd
Boot proof is in: the non-usr-merged Saphira Linux systemd sibling booted successfully today on homer, the i9 development machine, from a UAS USB NVMe device.
The first boot was performed with systemd-nspawn. systemd 261.2 reached graphical.target on x86-64, /sbin/init points to systemd, and the expected systemd services and units are present under /usr/lib/systemd.
$ sudo systemd-nspawn -D /mnt/saphira-nspawn -M saphira --boot
Saphira Linux 0.1
Kernel 7.1.8-arch1-3 on an x86_64 (pts/0)
akadata login: root
$ ls -la /sbin/init
lrwxrwxrwx 1 root root 22 Aug 24 15:00 /sbin/init -> ../lib/systemd/systemdsystemd-nspawn booted the image, reached multi-user.target and graphical.target, and presented a Saphira Linux 0.1 login prompt. systemd-logind failed during this first nspawn boot; that is expected cleanup for this stage and did not prevent the system reaching its targets.
The systemd packages are in the repository awaiting signing. The next step is a simple apk install systemd path cleanup to remove the remaining old OpenRC pieces, followed by images later today.
Why it exists. Saphira-d is not OpenRC's retirement notice and it is not a conversion of Saphira to systemd. It is an experiment: can the same source-built, musl-based, deliberately understandable Saphira philosophy keep its character when the init and service layer is systemd instead of OpenRC? Systemd is a real part of modern Linux expectations, so the question is worth answering honestly rather than by assertion.
What stays the same. What stays the same is the part that matters: a source-built, musl-based, staged distribution you can follow from toolchain to boot. Saphira-d is not a different project philosophy bolted onto a different libc.
What changes. What changes is the init and service architecture. OpenRC scripts become systemd units; the service-startup model and its dependency story change; and a new dependency chain (Linux-PAM, libxcrypt, libucontext, Jinja2, MarkupSafe, libmnl, libbpf) has to be built from source for musl.
Why its own build tree. Saphira-d has its own build tree rather than systemd being dropped into the OpenRC Saphira source. That keeps the two comparable on the same philosophy and stops one init experiment from silently redefining the distribution people already run as Saphira.
What we are trying to learn.
- what systemd genuinely requires to build and run on musl;
- the extra dependency chain it introduces;
- the functionality it provides in return;
- what happens to size and complexity;
- how current systemd behaves on musl in practice;
- whether the result stays understandable from toolchain to boot to service start;
- which differences are inherent and which are merely conventional wisdom.
How it is being built.
architecture abstraction → cross-toolchain → temporary tools → chroot / final userspace → PAM + systemd integration → kernel + initramfs → complete build → first boot → comparison against OpenRC Saphira
Where it is today. Saphira-d has now completed its first proven boot: the non-usr-merged systemd system booted on homer, the i9 development machine, from a UAS USB NVMe device. A systemd-nspawn boot reached multi-user.target and graphical.target on x86-64, with /sbin/init linked to systemd. Runtime cleanup and broader validation remain.
What happens next. Sign the systemd packages already in the repository, remove the remaining old OpenRC pieces with the apk install systemd path, publish images, and compare Saphira-d against OpenRC Saphira on the same broad philosophy.
On Pi 4. The akadata/pistorm64 project is existing engineering behind the planned Pi 4 work: its documentation records PiSCSI64 remote disk mount/boot and ISO-backed CD-ROM support as validated on a Pi 4 baseline. That is planned crossover work for Pi 4 Saphira builds, not something Saphira already ships. Read the full history on the About page.
Active direction & build details
Source-built three-stage model
libc
init / service manager
compiler
kernel target
active build profile
planned x86-64 profiles
32-bit profiles
AArch64
authentication / session integration
systemd dependency chain
architecture-isolated build roots
Pi 4 integration (planned)
These details describe the active Saphira-d direction. They do not imply that every general Saphira builder profile, ARM target, or machine profile is ready for Saphira-d.
Deliberate boundaries
What Saphira will not become
A small server distribution stays useful by knowing what it is not trying to be. These are deliberate project boundaries, not limitations placed on what users may build themselves.
-
Desktop environment
Saphira is a server operating system. There are no plans to turn it into a desktop distribution.
-
X11, Wayland and Plasma
They are not part of the Saphira base system or roadmap. Nothing prevents somebody from packaging them independently, though the project itself will remain server-first.
-
NVIDIA proprietary userspace on the host
Saphira keeps the host pure musl: it does not install CUDA, glibc, or NVIDIA's proprietary userspace there. The open kernel-module package and matching GSP firmware are a separate host-side boundary.
-
NVIDIA Open Kernel Modules
nvidia-open 610.57.04 is staged in hatchling for testing. The host stays musl-only; any CUDA/NVIDIA userspace belongs in a glibc systemd-nspawn container with the exact same NVIDIA release as the host modules. This architecture is documented, but its real-GPU and container proofs are pending.
-
Graphical installer
Installation tooling is terminal based. A TUI path for installing onto target disks is planned.
-
Mandatory hosted control plane
Saphira will not require a SaaS dashboard or remote service in order to administer the machine. Configuration remains local, inspectable and owned by the operator.