Installing GNOME OS Preview now could mean reinstalling it to reach the eventual Stable edition. That's the practical catch in GNOME's October 16 launch: the new edition uses stable GNOME releases, starting with GNOME 51.1, while leaving the long-term upgrade path unsettled. Developer Adrian Vovk's announcement invites enthusiasts beyond the developer audience to try it, provided they can accept that possible rebuild.
The download page now separates Preview, based on the latest GNOME 51 release, from Nightly, which follows the latest commits of GNOME components. It also warns that forward compatibility isn't guaranteed. For someone choosing an operating system for a working laptop, those two pieces of information belong together: slower-moving desktop code doesn't settle how long an installation can be carried forward.
Why the project is withholding the Stable label
GNOME's developers set a specific condition at their FOSDEM 2026 hackfest: they would call the OS stable once they had a configuration they were willing to support over the long term. They wanted systemd-homed in that configuration and didn't want to maintain installations using the earlier account arrangement forever. A migration script came up in the discussion. The developers judged it too difficult and dangerous to deploy in practice.
That decision follows the design Vovk described in his 2024 proposal for a general-purpose GNOME OS. He wanted identical copies of the base system, with missing functionality treated as something the OS must fix. He argued against letting package overlays become the routine answer to missing features. The appeal is easier diagnosis: if users share the same base, developers have fewer locally modified systems to account for when investigating a failure. Preview arrives while parts of that common base are still being decided.
The unfinished work reaches into user accounts
The systemd home-directory design explains why systemd-homed reaches further than a login-screen preference. It keeps a user's account record with the home directory, including a signed JSON identity file. Its supported storage arrangements include an encrypted LUKS2 volume containing the user's filesystem. In that arrangement, the home directory is activated and mounted for use, with identity records checked as part of activation.
Changing an existing installation to use those account and storage mechanics raises questions about moving data and preserving access. The February hackfest account establishes that the GNOME OS team considered automatic migration unsafe to ship. It doesn't establish that migration is technically impossible. For an early adopter, the consequence is simpler: don't assume a future system-image update will perform that conversion for you.
Configuration changes also need to survive updates. At the same hackfest, developers described how links between /etc and /usr had let local changes drift away from upstream defaults. They reported moving Nightly to an overlay arrangement using systemd-confext, with OS defaults beneath a writable layer for administrator overrides. That completed change illustrates the work involved in maintaining a system across versions, beyond choosing which desktop release to include.
Rollback already solves a different problem
GNOME OS does have a recovery mechanism for ordinary system updates. Its user guide says two OS versions remain installed, and users can choose the older one at startup. GNOME Software handles updates, while the terminal equivalent is:
updatectl update
The guide then directs users to reboot into the new image. Keeping an earlier image gives them a way back when an update breaks something. It doesn't supply the account migration discussed at FOSDEM.
The same guide describes daily operation without a traditional package manager. Graphical apps come through Flatpak and GNOME Software, with Podman, toolbox and distrobox also available. A development extension supplies the GNOME OS toolchain and common GNOME development utilities. These are concrete routes for getting work done, though they require a different approach from installing every dependency into the host system. Before switching, check where the tools you use would live.
The downloads also carry a cost separate from installation. The Preview announcement lists delta-update support in systemd-sysupdate as unfinished work, intended to avoid downloading a full 2 GB image each time. Preview changes which GNOME code users receive; smaller updates remain on the development list. That matters if your connection makes repeated multi-gigabyte downloads expensive or inconvenient.
Developer tools still expose gaps in the model
Jordan Petridis's September Toolpak proposal addresses utilities that don't fit comfortably into the existing arrangements. GNOME OS's development extension contains a finite set of tools for building the OS. Developers working elsewhere need a wider selection. Petridis points to utilities such as strace and QEMU, whose jobs require access that a confined application environment can obstruct.
Toolpak's proposed answer is to distribute tools independently of the host, with their dependencies, while allowing broad system access. The design calls for trusted signatures, runtime verification and review before inclusion in a proposed store. Petridis described funded prototype work, so this remains a project to follow rather than a finished installation channel. Its trust model also matters: separating a tool's libraries from the OS wouldn't make that tool safe to run with unrestricted access.
Application support has another funded effort behind it. Modal's August Flatpak investment announcement details €508,640 from the Sovereign Tech Agency for a two-year initiative. Planned work includes separating speaker access from microphone access, more specific network permissions, and a portal allowing VPN apps to manage system connections. A portal gives a sandboxed app a defined way to request an operation from the host.
For GNOME OS, which relies on Flatpak for graphical applications, those interfaces affect which applications can work properly without broad exceptions. Modal says the effort is expected to run through the end of 2027, and that its plans may change as implementation begins. The VPN and audio controls are planned work in the funding announcement, which gives no Preview delivery date for them.
Check the installation instructions before choosing a disk
GNOME has already used daily operation as a testing programme. Tobias Bernard's Summer of GNOME OS challenge asked participants to run Nightly on a primary computer for at least four weeks, rewarding valid bug reports and fixes. He explained that notifications and touch input can be awkward or impossible to test properly in a virtual machine. Preview gives enthusiasts a less changeable starting point for exploring their hardware, although the existence of that testing effort isn't a guarantee about any particular laptop.
The public documentation hasn't fully caught up with the new edition's positioning. The installation guide still refers to Nightly and warns that GNOME OS has limited hardware support and no dedicated security team. It specifies UEFI with Secure Boot disabled and says dual boot isn't recommended or officially supported. Those are material constraints for anyone planning to replace an existing installation, even as the homepage now recommends Preview to most visitors.
The guide's disk preparation can erase existing data. It also tells users to record an encryption recovery key on another device if the installer supplies one. Given that documented process, a spare machine is a more sensible first hardware test than a laptop holding your only copy of working files. For a virtual-machine trial, the GNOME OS homepage points to GNOME Boxes and specifies the version distributed through Flathub.
The next decision to watch is when GNOME OS can commit to supporting its chosen configuration and explain how existing users reach it. Vovk's Preview announcement makes no promise of perpetual updates. Until the migration question is settled, anyone adopting Preview should budget for a reinstall alongside the time spent testing the desktop.