Bazzite is not a different distribution from Fedora. Its default image is Fedora’s KDE Atomic build with Steam, Lutris, a patched gamescope and a gaming kernel baked into one 11.6 GB container image. So the real Fedora vs Bazzite question is who assembles your gaming stack, and who keeps it working after an update. On Fedora you do it with dnf and RPM Fusion. On Bazzite the Universal Blue project does it, and you take the whole image or nothing.
We put both on matching Proxmox VMs and measured the parts that differ: the Steam and Proton setup effort, the gamescope Gaming Mode session, dnf against rpm-ostree updates, how each delivers the NVIDIA driver, and where each one hurts. The VMs had no GPU, so you will not find frame rates here; our Steam, Proton and NTSYNC guide for Fedora has those, measured on an NVIDIA card. Everything below was run on Fedora 45 with KDE Plasma and on Bazzite stable 44.20261023 in October 2026.
Bazzite is Fedora shipped as an image
A Fedora install is a set of RPMs that you change one transaction at a time. Bazzite is a bootable OCI image built from Fedora Kinoite on GitHub, pulled from ghcr.io, and deployed with rpm-ostree, so every machine on the same tag runs the same bytes in /usr. That is why Bazzite can promise a working Steam setup. It tested the exact combination you’ll boot. It’s also why a new Fedora base reaches Bazzite stable last, because the base only changes after the project has validated it on its own testing tag.
You can read both tags without installing anything. This asks the registry for the version label, the kernel and the build date of the stable and testing images:
for t in stable testing; do skopeo inspect --no-tags docker://ghcr.io/ublue-os/bazzite:$t | jq -r '[.Labels["org.opencontainers.image.version"], .Labels["ostree.linux"], .Created] | @tsv'; doneOn October 26 the stable image was still built on Fedora 44, and the Fedora 45 base was on testing with a newer ogc kernel:
44.20261023 7.2.9-ogc3.1.fc44.x86_64 2026-10-23T16:31:37Z
testing-45.20261026.1 7.2.11-ogc4.1.fc45.x86_64 2026-10-26T16:47:47ZSo when we tested, a Fedora 45 machine and a Bazzite stable machine were not on the same Fedora base. Does that matter for games? Rarely, because the gap is normally short.
When Fedora 43 shipped on October 28, 2025, the Bazzite desktop images moved stable to it the next day, according to the Bazzite release history. The deck images were slower in the last cycle and only reached the Fedora 44 base in August 2026. If you want Fedora 45 packages on Bazzite before stable moves, the testing tag is the only route, and that is a channel built nearly every day.
Both lab VMs were cloned from the same Fedora 45 Cloud Edition template: 4 vCPUs, 8 GB of RAM, UEFI firmware, and no GPU. The package counts on the Fedora side start from that minimal base, so a Workstation or KDE install will show smaller transactions. They were set up like this.
- fedora01, Fedora 45 plus the
kde-desktopgroup (1,060 packages, 308 s) - bazzite01,
bazzite:stablewritten withbootc install to-disk - KDE Plasma on both, so the desktop is not a variable
The Bazzite image took 11 minutes to pull and 10 minutes 19 seconds to write to an 80 GB disk. That bootc path is not how Bazzite tells you to install it. The official ISO does the same image deployment behind a graphical installer and also adds the Flatpak apps, which is why our Bazzite VM had none. Everything that lives inside the image is identical either way.
Steam takes one dnf transaction on Fedora
Fedora does not ship Steam in its own repos, so the setup is two commands. You add RPM Fusion, then install the gaming packages. On a Workstation install you can flip the third-party repository switch instead, which enables a filtered Steam repo, but the full RPM Fusion repos also cover the NVIDIA driver and codecs. Add both RPM Fusion repos first.
sudo dnf install -y https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpmThen install Steam together with gamescope, MangoHud and GameMode, the three tools Bazzite’s image either ships or replaces.
sudo dnf install -y steam gamescope mangohud gamemodeOn top of the KDE desktop, dnf resolved 209 new packages and finished in 115 seconds:
Transaction Summary:
Installing: 209 packages
Replacing: 18 packages
Downgrading: 18 packages
Total size of inbound packages is 220 MiB. Need to download 220 MiB.
After this operation, 745 MiB extra will be used (install 810 MiB, remove 66 MiB).Read the 209 carefully, because 189 of them are i686 packages. Steam’s client is still 32-bit, so it drags in a second copy of Mesa, the Vulkan loader and their libraries. The replacing and downgrading lines are not part of a normal install. Our template had updates-testing enabled, so dnf moved 18 packages back to their stable builds; a default install shows only the install count.
Two commands are the whole Fedora setup for Steam. Proton itself comes down through Steam, and the Fedora gaming guide covers turning on NTSYNC and checking that Proton actually uses it.
Bazzite ships it already installed
On Bazzite the same step has nothing to run. Steam and Lutris are RPMs inside the image, not Flatpaks, and the gaming tools come from the Terra repository instead of Fedora’s. Query them on the booted system.
rpm -q steam lutris terra-gamescope terra-mangohud umu-launcherEvery package answers, and the 32-bit MangoHud build is there too:
steam-1.0.0.87-5.fc44.x86_64
lutris-0.5.22-1.fc44.x86_64
terra-gamescope-3.16.31^6-1.fc44.x86_64
terra-mangohud-0.8.4-2.fc44.x86_64
terra-mangohud-0.8.4-2.fc44.i686
umu-launcher-1.4.4-1.fc44.x86_64Three differences hide in that list, and each one changes what you’re running.
- gamescope is a newer Terra build, with 32-bit libraries
- umu-launcher is preinstalled; Fedora’s repos lack it
- GameMode is removed from the image on purpose
Bazzite’s image held 2,726 packages, 216 of them i686, against 1,830 on our Fedora VM after the Steam install. ScopeBuddy, vkBasalt and a patched, version-locked Mesa from Terra are in there as well. If you came from our Lutris, Heroic and GE-Proton setup on Fedora, you’ll notice that half of it is already done on Bazzite: Lutris and umu are installed, and only Heroic is left for you to add from Flathub.
Gaming Mode ships only on deck images
The gamescope session is the part people mean when they say Bazzite feels like a Steam Deck: you boot into Steam’s Big Picture running inside gamescope, with no desktop underneath. Fedora ships the gamescope compositor but no session for it, and on our Fedora VM a search for a session package came back empty.
dnf list --available 'gamescope-session*'Even with RPM Fusion enabled, nothing matches:
Updating and loading repositories:
Repositories loaded.
No matches found.Fedora’s gamescope RPM gives you the binary and its helpers, and /usr/share/wayland-sessions/ held only plasma.desktop. You can still run a single game nested in gamescope from Steam’s launch options, but a boot-to-Steam session has to come from outside Fedora’s repos.
Does Bazzite’s desktop image fill that gap? No. The default bazzite image had the same lone plasma.desktop as Fedora, and Gaming Mode comes only with the bazzite-deck images. We pulled bazzite-deck:stable and listed its sessions and session packages:
podman run --rm ghcr.io/ublue-os/bazzite-deck:stable bash -c 'ls /usr/share/wayland-sessions/; rpm -qa | grep -iE "gamescope-session|steamos-manager|inputplumber|opengamepadui|powerstation" | sort'Two Steam sessions sit next to Plasma, along with the controller and power daemons a handheld or a TV box needs:
gamescope-session-ogui-steam.desktop
gamescope-session-steam.desktop
plasma.desktop
gamescope-session-0~20261002git.08e65a6-1.fc44.noarch
gamescope-session-ogui-steam-0~20260325git.fbdc768-2.fc44.noarch
gamescope-session-steam-0~20260919git.82c45fc-1.fc44.noarch
inputplumber-0.83.0-2.fc44.x86_64
opengamepadui-0.46.1-8.fc44.x86_64
powerstation-0.8.4-2.fc44.x86_64
steamos-manager-powerstation-0~20261018.gitaa85e5b-1.fc44.x86_64The deck image’s autologin script picks gamescope-session-ogui-steam.desktop as the default. The machine boots straight into Steam Big Picture Plus, and Steam’s power menu switches to the Plasma desktop. That is the setup to pick for a living-room PC or a handheld.
For a desk PC with a keyboard and mouse, the desktop image is the better fit, and in that case Bazzite and Fedora give you the same Plasma session with Steam as an app. The deck image is also 13.5 GB against 11.6 GB. Moving between the desktop and deck flavors of the same KDE image is a documented rebase, but switching between KDE and GNOME is not: Bazzite’s FAQ recommends a reinstall for that. Its rollback docs also warn that going from Deck 44 back to Deck 43 breaks autologin.
dnf changes packages, rpm-ostree swaps images
On Fedora an update is a dnf transaction that rewrites the running system, package by package, and dnf history records every transaction. What Fedora does not give you by default is a way back to the system as a whole. The VM’s Btrfs root held its four default subvolumes, no snapshots and no snapshot tool. You add that yourself with Snapper and grub-btrfs on Fedora, and until you do, a bad Mesa or kernel update means booting an older kernel and downgrading by hand.
Bazzite blocks that model on purpose. Its /usr/bin/dnf is a wrapper script that forwards to dnf5 for read-only work and refuses package changes on the host.
sudo dnf install -y htopYour command fails before dnf5 ever runs:
ERROR: Fedora Atomic images utilize rpm-ostree instead (and is discouraged to use).
Please, read our documentation
https://docs.bazzite.gg/Installing_and_Managing_Software/Software you add goes to Flatpak, Homebrew or a Distrobox container instead, and rpm-ostree install is there as a last resort that the docs say can pause updates and block rebases. If you have used rpm-ostree on Fedora Silverblue, the mechanics are the same. In return, the system itself updates as a unit. On the desktop images, a timer runs uupd every day at 04:00 with a 15 minute random delay, and it updates the image, Flatpaks and containers together. The deck images update manually from Steam’s settings instead:
systemctl list-timers --all | grep uupdOur VM had the timer armed on first boot, with no setting changed:
Tue 2026-10-27 04:00:10 UTC 7h Mon 2026-10-26 20:32:44 UTC - uupd.timer uupd.serviceWhat does that cost? Size. While we were testing, a new stable build landed three days after the one we’d installed, and rpm-ostree reported what moving to it would download:
rpm-ostree upgrade --check47 of the 128 layers had changed, so a routine update was 1.8 GB:
AvailableUpdate:
Note: --check and --preview may be unreliable. See https://github.com/coreos/rpm-ostree/issues/1579
Total layers: 128
Size: 5.1 GB
Removed layers: 47
Size: 1.8 GB
Added layers: 47
Size: 1.8 GBApplying it changes nothing on the running system. Since we installed with bootc, our VM tracked the unsigned registry reference, so we moved it to the signed image and the new build in one rebase, the switch ujust verify-image exists to make. On a normal install, ujust update or the nightly timer does the same download:
sudo rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stableThe first attempt died partway with error: Bus owner changed, aborting when the rpm-ostreed daemon went away mid-pull. The second run kept every layer the first had already fetched, needed only the last 13, and finished in 143 seconds. These are the key lines from its 45 upgrades and 2 additions:
ostree chunk layers already present: 115
ostree chunk layers needed: 13 (695.9 MB)
Upgraded:
kernel 7.2.9-ogc3.1.fc44 -> 7.2.11-ogc4.1.fc44
pipewire 1.6.9-1.fc44 -> 1.6.10-1.fc44
terra-gamescope 1:3.16.31^6-1.fc44 -> 1:3.17.0^1-1.fc44
Added:
kmod-nct6687d-1.0^20261020git.ec1030b-2.fc44.x86_64
nct6687d-1.0^20261020git.ec1030b-2.fc44.noarch
Changes queued for next boot. Run "systemctl reboot" to start a rebootA new kernel and a new gamescope arrive in the same step, and you don’t choose between them. The new image sits next to the running one as a staged deployment until you reboot:
rpm-ostree statusA staged entry carries the diff, and the dot marks the deployment you’re booted into:
State: idle
Deployments:
ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:ee82a885dbb77cd4604a5ffa8278a0eef0bc84d16850045c7b9d847729da9949
Version: 44.20261026 (2026-10-26T20:06:36Z)
Diff: 45 upgraded, 2 added
● ostree-unverified-registry:ghcr.io/ublue-os/bazzite:stable
Digest: sha256:d1617c7098adb290bdf37e1b6661fa68467fced5771336425cfa985db4ded7e6
Version: 44.20261023 (2026-10-23T16:31:37Z)
ostree-unverified-registry:ghcr.io/ublue-os/bazzite:stable
Digest: sha256:d1617c7098adb290bdf37e1b6661fa68467fced5771336425cfa985db4ded7e6
Version: 44.20261023 (2026-10-23T16:31:37Z)Our reboot didn’t finish the job, and the way it failed shows the model working. The shutdown step that writes the staged deployment to the bootloader logged error: Remounting /boot read-write: Invalid argument in the journal of ostree-finalize-staged. The likely cause is our layout: bootc install to-disk created no separate /boot partition, and /boot came up as an autofs automount.
Our VM simply came back up on the old image, unchanged and fully working. We read it as a side effect of our install path rather than of Bazzite updates in general, and Bazzite has an open issue about bare-metal bootc installs. On a dnf system, a transaction that fails halfway leaves you with whatever it had already replaced.
Going back by hand is one command, and it only reorders the boot entries. On our VM both entries were the same build by then, so the capture shows the mechanism rather than a return to an older image:
sudo rpm-ostree rollbackNothing is downloaded or rebuilt:
Moving 'f593e7378a02c707f98112b508af6902cab5a660f8bb46aef9ec55d51ca97cac.0' to be first deployment
Bootloader updated; bootconfig swap: yes; bootversion: boot.1.1, deployment count change: 0
Changes queued for next boot. Run "systemctl reboot" to start a rebootBazzite keeps two deployments by default, and sudo ostree admin pin 0 pins the deployment at the top of the list so later updates can’t push it out (ours answered Deployment 0 is now pinned). Its brh helper (bazzite-rollback-helper) can also rebase to a dated build from the last 90 days when the previous deployment is already gone. Fedora can match this, but only after you add Snapper, so plan that in before the first big update.
Same NVIDIA driver, different delivery
Both systems offered the same NVIDIA release on the day we checked, 615.78.08, so the driver version isn’t the difference. The difference is where the kernel module gets built and who signs it. On Fedora, RPM Fusion’s akmod-nvidia compiles the module on your machine for every new kernel, and Maxwell, Pascal and Volta cards need the separate 580xx branch:
dnf list --available akmod-nvidia akmod-nvidia-580xx xorg-x11-drv-nvidiaBoth branches come from rpmfusion-nonfree:
Available packages
akmod-nvidia.x86_64 3:615.78.08-1.fc45 rpmfusion-nonfree
akmod-nvidia-580xx.x86_64 3:580.178.04-1.fc45 rpmfusion-nonfree
xorg-x11-drv-nvidia.x86_64 3:615.78.08-1.fc45 rpmfusion-nonfreeLocal builds are where Fedora’s NVIDIA trouble comes from. The akmod builds only for kernels whose headers are installed, so the first install often builds for a newer kernel than the one you’re running, and the driver doesn’t load until you reboot. With Secure Boot on, the module also has to be signed with a key you enroll yourself, or it won’t load at all. The NVIDIA driver guide for Fedora walks through both, and it’s a one-time job, but it’s yours.
Bazzite moves that work to its build servers. You pick an image for your card, and the module arrives prebuilt. We pulled bazzite-nvidia-open:stable and looked inside:
podman run --rm ghcr.io/ublue-os/bazzite-nvidia-open:stable bash -c 'rpm -q kmod-nvidia nvidia-driver; M=$(find /usr/lib/modules -name "nvidia.ko*" | head -1); modinfo -F version $M; modinfo -F license $M; modinfo -F signer $M; ls /etc/pki/akmods/certs/'The open kernel module is already compiled for the image’s kernel and signed with Universal Blue’s own key:
kmod-nvidia-615.78.08-1.fc44.x86_64
nvidia-driver-615.78.08-1.fc44.x86_64
615.78.08
Dual MIT/GPL
ublue kernel
akmods-ublue.derThat signer line is the catch with Secure Boot. With only Microsoft’s keys trusted, shim and the kernel’s lockdown checks reject a kernel or module signed “ublue kernel”. You enroll Universal Blue’s key once with ujust enroll-secure-boot-key, and it asks for the password universalblue at the next boot.
Our own VM pointed the same way for the ogc kernel itself. With Secure Boot on and only the Microsoft keys enrolled, the Bazzite disk did not reach userspace in four minutes, almost certainly a rejected kernel signature (we had no console to confirm it), and with the firmware in setup mode it booted in under a minute. The Fedora VM booted with Secure Boot on and no changes.
Card generation decides the image, the same way it decides the package on Fedora.
- RTX 20, GTX 16 and newer:
bazzite-nvidia-openorakmod-nvidia - GTX 745/750, GTX 900, GTX 10, Titan V:
bazzite-nvidiaorakmod-nvidia-580xx - Kepler and older: nouveau on Bazzite; RPM Fusion’s 470xx or 390xx legacy branches on Fedora
The legacy bazzite-nvidia image runs the 580 branch on an LTS build of the ogc kernel. Bazzite’s FAQ is clear that you cannot swap the driver or the kernel yourself; you rebase to the other image instead. Its hardware page also lists major caveats for NVIDIA in Gaming Mode, so an NVIDIA living-room box is the one setup where Bazzite’s main feature is the weakest.
Each one has a weak spot
Neither system is the safe default for everyone, because the weak spots sit on opposite sides of the same trade. Fedora gives you control and makes you do the integration. These are the costs we hit or confirmed on Fedora 45.
- Steam, NVIDIA and codecs need RPM Fusion
- The NVIDIA akmod rebuilds on every kernel
- No gamescope session package
- No system snapshots until you add Snapper
Bazzite gives you an integrated stack and takes the control away. Its costs are just as concrete.
- A new Fedora base reaches stable last
- Updates come as gigabyte-sized image layers
- dnf cannot install on the host
- Kernel and driver are fixed per image
- Secure Boot needs the Universal Blue key
Which list you can live with decides it. The docs also ask for a 50 GB disk at minimum, which matters on a handheld.
If you already run Fedora, work in containers and want the newest packages the day they ship, stay on Fedora and add the gaming pieces; it’s two commands and about two minutes of downloads, plus the NVIDIA driver. If the machine is mainly for games, or it sits under a TV, or someone else in the house uses it, Bazzite’s image is the better trade, because nobody has to know what an akmod is. Developers who want both can keep Fedora and run games there, since Distrobox on Fedora covers the container side either way.
Fedora vs Bazzite side by side
Every row below comes from the two lab VMs, except four that come from Bazzite’s documentation: the ways to add software, the default rollback deployment, the Secure Boot key, and the desktop-only scope of the update timer.
| Item | Fedora 45 (KDE Plasma) | Bazzite stable |
|---|---|---|
| Fedora base (Oct 26) | 45 | 44 on stable, 45 on testing |
| Getting Steam | RPM Fusion, then 209 packages, 220 MiB, 115 s | Already in the image |
| 32-bit packages | 189 | 216 |
| gamescope | Fedora build | Terra build, newer |
| GameMode | Installed with Steam | Removed from the image |
| Gaming Mode session | No package | bazzite-deck images only |
| Package changes | dnf | Flatpak, Distrobox, Homebrew; rpm-ostree as last resort |
| Updates | dnf upgrade, per package | uupd daily on desktop images, 1.8 GB image delta |
| Rollback | Needs Snapper | Previous deployment, kept by default |
| NVIDIA module | akmod, built locally | Prebuilt in the -nvidia images |
| Secure Boot | Boots; enroll your own key for NVIDIA | Enroll the Universal Blue key first |
| Kernel | Fedora kernel | ogc gaming kernel |
The rows that move people are the last five. If you’d rather own the kernel, the driver and the update timing, Fedora with RPM Fusion costs you two commands more than Bazzite does, plus the NVIDIA driver if you need it, and you keep every lever. If you’d rather have a rollback for the whole system and someone else validating the stack, Bazzite delivers that, at the price of a slower base and gigabyte-sized updates.
