Self-Hosted Builds — InterGenOS Building Itself

A from-source distribution makes a claim every time it ships: these binaries came from this source, through this pipeline. The strongest way to back that claim is to close the loop — run the entire build pipeline on InterGenOS itself, so the system that builds the OS is the OS, verifiable end to end with the same tools it ships to every user. That is what self-hosting means here, and InterGenOS is built to do it.

A development machine hosting the self-hosted build lane — dual AMD Radeon GPUs, mid-compile on the GPU-compute tier.

What the image already carries

Everything the 21-phase pipeline needs ships on the image — not as a special developer edition, but as the standard system:

• The virtualization stack — QEMU (KVM-accelerated), libvirt, virt-manager and virt-viewer, OVMF UEFI firmware (Secure-Boot-capable), swtpm (TPM 2.0 for guests), and virtiofsd for sharing the source tree into a build guest. Builds run inside an isolated guest, never on the live host — the same discipline the project applies everywhere. See Virtualization & Containers.
• The seal-and-sign toolchain — squashfs-tools, xorriso, veritysetup, sbsign/sbverify, GnuPG, and the smart-card stack (pcsc-lite, ccid, OpenSC) that talks to the hardware signing token. Both operator signing ceremonies — the archive-integrity manifest and the bootloader/UKI signing — run on the InterGenOS host itself.
• The build tooling — the compilers, the package tooling, and the orchestrator’s host-precondition check, which verifies every required tool before a build is allowed to start and fails closed on any gap.

Why it matters

Self-hosting is not a stunt; it is a trust property with teeth:

• The toolchain is auditable. When the OS builds itself, the compiler, linker, and every build tool are the same from-source, pinned, checksummed packages you can inspect with pkm — not an opaque third-party build box.
• The loop closes. An InterGenOS host, running an InterGenOS-built virtualization stack, boots an InterGenOS build guest, which produces the next InterGenOS image — including a guest with enforced Secure Boot and a TPM, so the product of the build can be validated under its full trust chain without leaving the machine.
• No hidden dependencies. If the pipeline needed something the image does not carry, self-hosting would fail loudly. Keeping the loop closed keeps the dependency claim honest.

The shape of a self-hosted build

1. Enable the virtualization stack (libvirtd) and create a build guest — UEFI/OVMF firmware, the source tree shared in via virtio-fs.
2. Inside the guest, the orchestrator runs the same fixed 21-phase pipeline documented in The Build & Release Pipeline: validation gates, toolchain, the seven package tiers, kernel, bootloader, image, manifest, squashfs, UKI/verity, ISO.
3. The build pauses twice on the host for the operator-only hardware-token ceremonies; signing inputs are re-staged and re-verified around each pause.
4. The resulting ISO is validated the way every candidate is validated: booted and installed on real hardware, with the signed chain checked end to end.

Status

The self-hosted path is being validated now, in stages, and this page states only what has been demonstrated:

• Demonstrated: an InterGenOS system hosting its own isolated build environment (KVM guest, OVMF firmware, virtio-fs source sharing), with the builder’s host-precondition check passing green inside that environment, and full package-tier builds running to completion in it.
• In validation: the first complete from-scratch cycle — all 21 phases, both signing ceremonies, ISO, install, and boot validation — performed end to end on InterGenOS-hosted infrastructure. This page will state that milestone as validated only once it has run clean, in keeping with the project’s rule that claims follow verification, never precede it.