Pralvo OS Seed
A CentOS Stream 10 host OS delivered as a bootc image — the whole operating system updates and rolls back as one atomic unit, the way a phone updates.
Request an environment and get a production-ready result — without a human coordinating ten separate systems by hand.
A CentOS Stream 10 host OS delivered as a bootc image — the whole operating system updates and rolls back as one atomic unit, the way a phone updates.
Rebuilding from the same inputs produces a byte-identical image. That’s the foundation auditability and signing depend on.
Every package’s license and source RPM is recorded, and every build is boot-tested as a real VM under QEMU before it counts as done.
How it works
Pralvo doesn’t ask you to migrate before you get value. It puts a control plane over the infrastructure already running, then tightens the boundary one verified step at a time.
Point Pralvo at the estate you already run. Substrate adapters speak to VMware, KVM, bare metal and public cloud without forking any of them.
Pralvo owns the package manifest and image composition — not a repaint of someone else’s finished image. You decide exactly what ships.
Resources, workflows, policy and lifecycle move through one control plane, so an environment request stops being ten separate tickets.
Each build proves itself: reproducible from pinned inputs, licence and source recorded, booted as a real VM before it counts as done.
Architecture
Pralvo owns the cloud experience and the control plane. A validated reference distribution supplies the execution substrate underneath. The boundary is deliberate and documented — not blurred.
Every Pralvo OS build carries its own paper trail. Nothing here is a roadmap item — these run on each build today.
Pralvo in practice
Pralvo ships as a sequence of small, independently working slices — each one usable and verified before the next begins. Here’s what the first customer-facing slice does.
One API call produces a production-ready Windows VM — identity, PKI, network, monitoring, backup, security evidence and lifecycle state already wired in. Running on the validated Pralvo OS and KubeVirt reference distribution.
Know moreHow we build
Each slice starts from one operator outcome and crosses every layer it needs — API, workflow, substrate adapter, evidence, verification. It ships independently deployable and independently reviewable.
Existing substrate components sit behind replaceable adapters. Forking an infrastructure project takes an explicit strategic decision, never convenience.
A capability is finished when its acceptance criteria pass and the artefacts prove it. Implemented-but-unverified work stays open, and the status on this page says so.
Questions
Early access is limited while Pralvo OS moves toward a certified release. Tell us what you’re running and we’ll tell you honestly where it fits.