Flagship
Reproducible by default
Rebuilding from the same pinned inputs produces a byte-identical image — the foundation auditability and signing depend on. It turns “trust us” into “check for yourself”: an auditor can rebuild and compare.
Pralvo OS
The host operating system for the Pralvo cloud — a purpose-built appliance composed from CentOS Stream 10, updating and rolling back as one atomic unit.
Built on
CentOS StreambootcKVMQEMUKubeVirtCephOVN / OVSFRR
01
Overview
What this product is, in the words we would use in a review rather than a brochure.
Pralvo OS is the operating system every Pralvo host runs. It is composed from CentOS Stream 10 packages — Pralvo decides exactly what ships, not upstream — and delivered as a bootable container image. The whole OS updates and rolls back as one atomic unit: closer to how a phone updates than to patching files on a running server.
An appliance, not a general-purpose server
A normal server OS is an engine, a steering wheel and a chassis — build whatever you want. An appliance OS is the complete car: it starts itself, manages its own engine, updates itself and reports its own problems. Pralvo OS turns a server into one specific thing: a dependable machine that runs virtual machines. The booted host is read-only, refuses modification in place, and always matches a signed release — there is no arbitrary local package installation, and diagnostics happen through a toolbox container.
That is the same discipline other infrastructure vendors apply by shipping a small appliance OS rather than a general-purpose distribution — applied to KVM/KubeVirt hosts without rebuilding every package. A Pralvo host answers as itself: what release am I, is my security state right, did I refuse what I should refuse, is my storage what I promised, am I healthy.
Honest status
Pralvo OS Seed 0.1 is an internal increment, not a supported product. It builds, boots and produces its evidence today; signed release channels, staged health-gated updates, automatic rollback and local recovery are still ahead of it — and every item on this page says which side of that line it is on.
02
What it does
Atomic updates & rollback
The whole OS ships as one bootable image, so an update is a single atomic swap rather than a thousand file patches. If a new image misbehaves, the previous one is still intact to boot back into. Staged, health-gated activation and automatic rollback are the next milestones.
A signed receipt for the whole release
One document names the release by fingerprint and covers every piece of evidence — software bill of materials, licence records, delivered source, vulnerability scan, boot results — by checksum. One signature protects the set, and a customer verifies it offline with a single command.
Licence-cleared and source-complete
No release clears until a human has approved every licence and the exact source RPMs are delivered. The gate is split in two: the cheap half runs on every build and is forbidden from printing a pass.
Built to run virtual machines
Pralvo OS exists to host VMs, so the host proves it. It asks the KVM subsystem a question and requires an answer, rather than trusting that a device file existing means virtualisation works.
Your data survives a rollback
The host is divided into declared zones with a stated answer for what survives an update, a rollback and a factory reset. Rolling back the OS does not roll back your data, and the host checks its own filesystem against that declaration on every boot.
What boots is what we certified
The running system reports which release it is, and it must be the certified one — closing the chain from the source we can prove to the machine that came up.
The host reports its own health
One status document in Pralvo’s own vocabulary reports release, security state, refused writes and storage promise. The verdict is calculated from the failure list, so the document cannot say “healthy” while listing a problem.
Diagnosable when it fails
Every boot emits a bounded diagnostics bundle, on good boots as well as bad, so a failure names its cause instead of costing another run to reproduce. A check that could not run is a failure, never a pass.
03
What it guarantees
These hold for every published build, or the build does not publish.
Enforced in CIRollback never touches your data
Think of the OS as a building and your data as the furniture. An update swaps the whole building; a rollback swaps yesterday’s building back. The furniture never moves — written into the contract so it is discovered on a good day, not a bad one.
Recovery outlives everything
The recovery environment is the only thing that survives a factory reset — the thing you use to recover has to outlive the thing that wipes everything else. It lives on its own partition the running system cannot write to.
Secure Boot is proven both ways
The host boots under enforcing UEFI Secure Boot, and the test also boots with deliberately wrong keys and demands rejection. A check that cannot fail is not a check.
It can actually run VMs
The virtualisation subsystem is asked a question and must answer, on every certified build. A host that cannot run a VM is caught before it ships, not on the first day a customer uses it.
Every check must be able to fail
Pralvo holds its own tests to five rules: able to fail, proved to have run, observing rather than re-doing, loud when skipped, and plugged in. A gate nobody runs is not a gate.
Failures name themselves
A struggling machine has one channel — the serial console. Every boot emits a bounded, single-line diagnostics bundle, including on boots the host reports as healthy, so the failures that cost most can still be investigated.
04
How it works
Stage 01
Compose the manifest
Pralvo owns the package manifest and image composition. You — or the Pralvo profile you choose — decide exactly what ships, down to pinned build inputs and lockfiles.
Stage 02
Build reproducibly
Pinned inputs, two independent builds, one identical manifest digest. The build records its own provenance: licence approvals, exact source RPMs, an SPDX software bill of materials.
Stage 03
Clear the legal gate
A release does not clear until every licence is human-approved and the exact source is delivered. The gate is split in two so the cheap half runs on every build without ever printing a pass.
Stage 04
Sign the receipt
One document names the release by fingerprint and covers every artifact by checksum; one signature protects the lot, recorded in a public append-only log. Customers verify offline with the downloaded files only.
Stage 05
Ship three disks, one OS
A QCOW2 for virtual machines, a raw disk for bare metal, and an installer ISO. Each is verified to resolve to the certified image, and the installer is proven by installing onto a genuinely blank disk and booting the result.
Stage 06
Update as one atomic unit
A new image is delivered as a bootc container and promoted through dev → candidate → stable channels. Hosts stage it and swap at a maintenance window; health-gated activation and automatic rollback are the next milestones.
05
Questions
What it is, and what it is not.
Answers we would rather give before a procurement call than during one.
Not as a supported product. Seed 0.1 builds, boots and produces its evidence, but signed release channels, health-gated rollback and local recovery are still ahead of it. It is an internal increment — a prerequisite for the customer-facing Pralvo work, not a standalone release.
No. Exact RHEL binary compatibility, Red Hat support and certification are not claims of Pralvo OS. A genuine RHEL-backed deployment remains a separate supported option where a customer supplies their own entitlements.
An operating system shipped as a bootable container image. The whole OS updates and rolls back as one atomic unit — closer to how a phone updates than to patching files on a running server. If an update misbehaves, the previous image is still intact to boot back into.
No. Pralvo OS is an appliance. The booted host is read-only and refuses modification in place; there is no arbitrary local package installation. Diagnostics happen through a toolbox container, so a host stays exactly the signed release it is certified to be.
Pralvo OS is composed from CentOS Stream 10 content rather than repainting a finished CentOS image, so Pralvo — not upstream — decides exactly what ships, and owns the supply chain, release decision and support boundary. Unmodified packages keep verified upstream builds; Pralvo rebuilds a package only when it carries a Pralvo patch or provenance requires it.
Pralvo hosts declare data boundaries with a stated answer for what survives an update, a rollback and a factory reset — and check themselves against the declaration on every boot. Rolling back the OS never rolls back your data, and the recovery environment is the only thing that survives a factory reset.
ESXi is a purpose-built virtualisation appliance. Pralvo OS applies the same appliance discipline — one controlled OS, platform-managed updates, a health contract — but deliberately builds on Linux + KVM/QEMU rather than inventing a new kernel or hypervisor. We compose, harden, sign and support the OS; the virtualisation underneath is proven open source.
Rebuilding from the same pinned inputs produces a byte-identical image. That is what makes an audit meaningful and what signing depends on — without it, “this is the image we tested” is a claim rather than something you can independently check.
Everything you run, one boundary.
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.