Felipe Borges announced a beta of the rewritten GNOME Boxes on August 3, after two years rebuilding the desktop virtualization tool from the ground up. The port to GTK4 and libadwaita is the visible half. The consequential half is that the new Boxes ships as a Flatpak and only as a Flatpak, bundling the whole virtualization stack rather than depending on whatever libvirt, QEMU and SPICE versions your distribution happens to carry. Practically, it can now install Windows 11 with no manual Secure Boot or TPM workarounds, adds a VSOCK device for reaching guests, and gains port forwarding. It is aimed at GNOME 51 in September.
The short answer
Felipe Borges published a beta of the rewritten GNOME Boxes on August 3, 2026, available as org.gnome.Boxes.Devel from the GNOME Nightly Flatpak repository. The application moves to GTK4 and libadwaita, and the old GTK3 SPICE display widget is replaced by libmks. Distribution changes to Flatpak only, bundling the entire virtualization stack instead of relying on the versions your distribution ships. Functionally, Boxes now installs Windows 11 without manual Secure Boot or TPM workarounds, adds a VSOCK device for SSH access to guests running systemd 256 or newer, and supports port forwarding to reach guest services from the host. Borges calls it a beta for testing, not production, and advises backing up VM data first.
GNOME Boxes has occupied an awkward position for years: friendly enough that people recommend it to newcomers, limited enough that most of those newcomers eventually end up in virt-manager editing libvirt XML anyway. The beta Felipe Borges published on August 3 is an attempt to close that gap, and the interesting part is not the new toolkit.
The rewrite, and what it replaced
Two years of work, described by Borges as rebuilding the application from the ground up rather than porting it.
The toolkit move is GTK3 to GTK4 with libadwaita, which brings the interface in line with the rest of the modern GNOME applications and, as Borges puts it, makes the codebase significantly easier to maintain. That second half is the one that matters for the project's survival, because an application nobody can contribute to is on a clock regardless of how it looks.
The specific replacement worth naming is the display widget. Boxes used a GTK3 based SPICE display widget, which is the component that actually draws the guest's screen inside the window. The rewrite swaps it for libmks. That is the sort of change users never see directly and feel constantly, because the display widget is where input latency, scaling behaviour and resize handling live.
Flatpak only is the real decision
Everything above is a modernisation. The distribution change is a choice with consequences.
The new Boxes ships as a Flatpak, and only as a Flatpak. Borges frames it as eliminating the maintenance overhead of supporting multiple distributions, and as bundling the entire virtualization stack so the project has the control needed to fine tune functionality.
Think about what that means for a front end to libvirt and QEMU. Previously, Boxes was a thin layer over whatever versions of libvirt, QEMU and SPICE your distribution shipped. The same Boxes release behaved differently across distributions, and a bug report was close to meaningless without the full stack version list. Bundling collapses that: one QEMU, one libvirt, one set of options, the same everywhere.
The cost is equally real. You give up your distribution's integration and its update cadence for those components. If you already run libvirt on the machine and expect Boxes to be one client among several, sharing definitions with virt-manager, that expectation no longer holds cleanly. Whether the trade is good depends entirely on whether you treat Boxes as a self contained appliance or as a graphical face on infrastructure you also manage other ways.
Windows 11 without the ritual
This is the change most likely to make someone actually switch.
Windows 11 requires Secure Boot and a TPM 2.0 device. In a virtual machine, the hypervisor has to supply both, which historically meant selecting an OVMF firmware image with Secure Boot enabled and attaching a swtpm emulated TPM. Neither step is conceptually hard. Both are fiddly, thinly documented, and easy to get subtly wrong in a way that surfaces only when the Windows installer refuses to proceed. Plenty of people got as far as that error and went to find virt-manager.
The rewritten Boxes configures both automatically. A Windows 11 ISO now installs the way any other guest does.
Getting into the guest
Two additions cover the two things people actually want from a desktop VM.
A VSOCK device provides SSH access to guests running systemd version 256 or newer, which is where the guest side support arrived. VSOCK is a socket family built for host to guest communication that bypasses the network stack entirely, so it works whether or not the guest has an IP address the host can route to. That removes a familiar category of frustration where the VM is running fine and simply cannot be reached.
Port forwarding covers the other half: map a host port to a guest port and a service running inside the VM becomes reachable from the host. Between the two, a shell and a service, both without hand configuring guest networking.
What we would do
Install it next to the stable version, not over it.
The beta is published as org.gnome.Boxes.Devel in the GNOME Nightly Flatpak repository, which means it coexists with a stable Boxes rather than replacing it. Borges is direct that this is a beta for testing and not for production, and recommends backing up virtual machine data before trying it. For a tool whose failure mode is a disk image, that advice deserves to be followed literally.
The finished rewrite is targeted at GNOME 51 on September 16. Six weeks is a short runway for an application rebuilt from scratch, particularly one maintained alongside GNOME Settings and other Red Hat responsibilities, much of it in the author's own time. If you have a use case that the old Boxes handled badly, this is a good moment to test it and file something specific, because that is when a bug report is worth the most.
Sources and further reading
- Felipe Borges, The Future of GNOME Boxes, August 3, 2026
- GNOME Boxes preparing to deliver much improved virtualization experience, Phoronix, August 3, 2026
- Discussion of the announcement on GNOME Discourse
- GNOME Boxes nightly builds
Frequently asked questions
Why is Flatpak only a big deal for a virtualization tool?
Because Boxes is a front end to libvirt and QEMU, and a front end is only as predictable as the stack beneath it. Historically Boxes ran against whatever versions of libvirt, QEMU and the SPICE libraries your distribution shipped, which meant the same version of Boxes behaved differently on Fedora, Debian and Arch, and a bug report was rarely reproducible without knowing the full stack. Borges describes the Flatpak decision as bundling the entire virtualization stack, which removes that variable: everyone runs the same QEMU with the same options against the same libvirt. The cost is real too. You give up your distribution's integration, its security update cadence for those components, and the ability to share a libvirt configuration with virt-manager the way you might expect. Whether that trade is worth it depends on whether you use Boxes as a self contained appliance or as one client among several.
What changes about installing Windows 11?
Windows 11 requires Secure Boot and a TPM 2.0 device, and in a virtual machine both have to be provided by the hypervisor. Under the old Boxes that meant configuring an OVMF firmware with Secure Boot enabled and attaching a swtpm emulated TPM device, usually by editing libvirt XML by hand or by giving up and using virt-manager. The rewritten Boxes configures both automatically, so a Windows 11 ISO installs the way any other guest does. This is the change most likely to be the reason someone actually switches, because the manual path is not difficult so much as fiddly, poorly documented and easy to get subtly wrong in a way that only shows up at the Windows installer's compatibility check.
What are VSOCK and port forwarding for here?
They are two answers to the same problem: reaching something inside the virtual machine from the host. VSOCK is a socket family designed for host to guest communication that does not go through the network stack at all, so it works without the guest having an IP address you can route to. Boxes uses it to offer SSH access to guests running systemd version 256 or newer, which is where the necessary systemd side support landed. Port forwarding is the more conventional answer: you map a host port to a guest port so a web server or database inside the VM is reachable from the host. Between them they cover the two things people most often want from a desktop VM, a shell and a service, without hand configuring guest networking.
Should I install the beta?
Only on a machine where losing a virtual machine would be an inconvenience rather than a problem. Borges is explicit that this is a beta meant for testing and not for production environments, and he advises backing up virtual machine data before testing. That warning is worth taking at face value for a tool whose failure mode is a disk image. Install it as org.gnome.Boxes.Devel from the GNOME Nightly Flatpak repository, which installs alongside a stable Boxes rather than replacing it, so you can try the new one on a throwaway guest while keeping the old one for anything you care about. If you want to help, the useful contribution is a bug report from a real workflow rather than a first impression.
When does the finished version arrive?
The rewrite is targeted at GNOME 51, which is scheduled for September 16, 2026. That is roughly six weeks from the beta, which is a short runway for an application that has been rebuilt from scratch, so we would not be surprised to see parts of it land later or arrive with rough edges. It is also worth knowing how this work is resourced: Borges maintains Boxes alongside GNOME Settings and his other responsibilities at Red Hat, and describes much of the Boxes work as happening in his free time. A two year ground up rewrite delivered on that basis is an achievement, and it is also a reason to calibrate expectations about how fast the remaining gaps close.