Vanilla OS 3 Reunion: Complete Guide (2026)
✅ Covers Vanilla OS 3 "Reunion" · Released September 1, 2026 — Last updated: September 2026
Vanilla OS takes a different approach to the "immutable Linux" idea than Fedora Silverblue or openSUSE Aeon: instead of a read-only root filesystem with rpm-ostree layering, it runs two full root partitions and swaps between them on every update. Version 3, codenamed "Reunion," is the first release to ship ARM64 with feature parity to x86_64, and the first where most images are bit-for-bit reproducible. This guide covers how the system actually works under the hood, what changed in 3.0, and whether it fits your workflow.
Curious to try it yourself before committing to bare metal? A cloud VPS is the fastest way to test-drive a new release — see our comparison of the best Linux VPS hosting providers.
What Vanilla OS Actually Is
Vanilla OS is an immutable, atomic distribution built around two custom tools instead of a traditional package manager touching the live system directly:
- ABRoot — manages two swappable root partitions ("current" and "future") and applies every system update as an atomic transaction.
- Apx — installs packages inside containers instead of writing to the base system, so your app installs can't corrupt the OS layer.
The result: the base system stays untouched by day-to-day package installs, and every update either fully succeeds or fully rolls back — there's no "half-applied update" state to debug.
How ABRoot Actually Works
This is the part most coverage of Vanilla OS skips over. ABRoot doesn't use rpm-ostree-style layering — it works with two complete root partitions:
- Current — the partition you're actively running.
- Future — the target of the next update.
Updates are applied as OCI images: ABRoot downloads the update image, applies it to the future partition, and verifies it's consistent before touching anything you're using. On reboot, the two partitions swap roles — future becomes current. If a local change is needed (installing a system-level package outside a container, for example), ABRoot's package manager generates a local OCI image with your changes layered on top of the base image, rather than writing directly to the filesystem.
Because updates only ever touch the inactive partition, rollback is just booting into the other partition — no snapshot restore tool required, no partial-update state to untangle. If you've used Timeshift to recover from a bad update on a traditional distro, this solves the same problem structurally instead of after the fact. ABRoot also supports LVM thin provisioning, so the two root partitions don't have to each reserve their full size up front — blocks are allocated on demand.
What's New in Vanilla OS 3 "Reunion"
Released September 1, 2026. The headline changes:
| Change | Detail |
|---|---|
| ARM64 support | Built with feature parity to x86_64 — not a stripped-down secondary target |
| Reproducible builds | Most images are now bit-for-bit reproducible (NVIDIA builds are the exception) |
| Kernel | Linux 7.1.3 |
| Desktop | GNOME 50, GDM running on Wayland exclusively (no X11 session) |
| Fractional scaling | Enabled by default, no experimental flag needed |
Reproducible builds matter more than they might sound: it means anyone can rebuild the exact same image from the same source and get an identical, verifiable result — a supply-chain security property most distros don't offer at all.
App swaps in this release
- Ptyxis replaces Black Box as the default terminal.
- Papers replaces Evince as the default PDF reader.
- Resources replaces GNOME System Monitor.
All three are GNOME's own newer-generation apps — this brings Vanilla OS's default app set in line with where upstream GNOME itself has been moving.
Vanilla Continuity: Built-In Backup
New in this release cycle: a snapshot-based backup tool built specifically to work with ABRoot's dual-root model, rather than a generic third-party tool bolted on. It supports LUKS2 encryption — pairs naturally if you've already set up disk encryption with LUKS — and remote backup targets over SFTP, FTP and NFS.
Vanilla OS vs. Other Immutable Distros
"Immutable Linux" isn't one architecture — the major players solve it differently:
- Vanilla OS (ABRoot) — two full swappable root partitions, updates as OCI images, rollback by booting the other partition.
- Fedora Silverblue / Kinoite (rpm-ostree) — a single read-only ostree-managed root with layered package "commits" on top, more like a Git history of the filesystem than two mirrored partitions.
- Bazzite — built on Fedora's Atomic/rpm-ostree base rather than ABRoot, but aimed specifically at gaming rather than a general-purpose immutable desktop; see our Bazzite guide if that's closer to what you're after.
If your priority is a conceptually simple rollback model — you're either on the partition that works or you boot the other one — ABRoot's approach is easier to reason about than rpm-ostree's layered commits. If you specifically want Fedora's package ecosystem and SELinux posture in an immutable form, Silverblue/Kinoite stays the more direct fit.
Installing Software with Apx
Apx installs packages into per-application or per-stack containers rather than the host system. In practice:
apx pkg install package-nameruns inside a container built from a chosen backend (e.g. an Ubuntu or Fedora-based container image), and Apx handles exporting the app so it appears and runs like a normal installed application — you're not manually entering `distrobox enter` sessions to use it day to day. For anything not packaged this way, Vanilla OS also supports Flatpak; see our Snap vs Flatpak vs AppImage comparison if you're deciding which packaging format to lean on.
Who Should Run Vanilla OS 3
- Good fit: anyone who wants an immutable desktop with a simpler mental model than ostree layering, ARM64 users who want first-class (not bolted-on) support, and anyone who cares about reproducible, verifiable builds.
- Worse fit: anyone who regularly needs to install system-level packages outside a container — Apx's containerized model is the whole point, but it's a real workflow change if you're used to
apt installtouching the live system directly.
Frequently Asked Questions
Is Vanilla OS based on Ubuntu or Debian?
Vanilla OS builds its own base images rather than being a downstream respin of Ubuntu or Debian in the traditional sense — Apx containers can pull from Ubuntu- or Debian-based backends for app installs, but the immutable base system itself is Vanilla OS's own image.
How is ABRoot different from Fedora's rpm-ostree?
ABRoot uses two complete, swappable root partitions and applies updates as OCI images to the inactive one. rpm-ostree instead manages a single read-only filesystem tree with layered commits, closer to a Git-style history than two mirrored partitions. Both are atomic and roll back reliably; ABRoot's two-partition model is generally easier to reason about, rpm-ostree's layering is more storage-efficient.
Does Vanilla OS 3 support ARM64 devices like the Raspberry Pi?
Vanilla OS 3 ships ARM64 builds with feature parity to x86_64. Specific single-board-computer support depends on that hardware's mainline kernel support for Linux 7.1.3 — check your device's compatibility separately.
Can I install regular Linux packages without a container?
The default and recommended path is through Apx (containerized) or Flatpak. Writing directly to the immutable base system defeats the reliability guarantees ABRoot is built around, so it's deliberately not the primary workflow.
What happens if a Vanilla OS update fails?
Nothing on your running system changes — updates are written to the inactive "future" partition and verified before the next boot. If the update fails verification, you keep running on the current, working partition.
