Fedora Silverblue vs Workstation 45: Which One to Install

On Fedora Silverblue, root can’t write to /usr, so nothing you install changes the running system until you reboot into a new deployment. That one property decides most of this comparison. You trade a few seconds per dnf install for an operating system you can roll back as a whole, and the bill shows up in places most comparisons skip: third-party RPMs, disk space, boot time and a btrfs compression setting that silently never turns on.

Original content from computingforgeeks.com - post 176315

We installed both editions side by side on identical VMs (4 vCPU, 4 GB of RAM, 40 GB disk), Silverblue from its own installer ISO and Workstation from the netinstall image with the Workstation package group, and ran the same jobs on each: an install, a third-party RPM, an undo, three reboots and an update cycle. All of it was tested in October 2026 on Fedora 45 Silverblue and Fedora 45 Workstation with SELinux enforcing, so no step relies on switching it off.

Which edition to install

Pick Silverblue when the machine should stay in a known good state and most of your software already ships as Flatpaks or runs in containers. Pick Workstation when you install host packages every week, build kernel modules, or depend on vendor RPMs that expect a writable /opt. Both run the same GNOME, kernel and Podman, so the choice is about how changes reach the system, not about what the desktop looks like:

• A bad update or a broken package must be reversible with one command and one reboot: Silverblue.
• Host packages must work the moment the install finishes, with no reboot: Workstation.
• Vendor RPMs such as Google Chrome must install from the vendor’s own repository with plain dnf: Workstation.
• Development work must happen in containers rather than on the host: Silverblue, with Toolbx or Distrobox doing the mutable work.
• Disk must stay lean on a small SSD: Workstation, by about 3 GB on a fresh install.

If most of those lines point at Silverblue, read the third-party RPM and compression sections before you decide anyway, because those are the two places Silverblue still costs real effort.

The two systems side by side

We measured both machines on the same hypervisor host. Disk use is the figure right after install. Boot time and memory are the range across three reboots each, taken with htop and Chrome installed on both machines, at the login screen 90 seconds after SSH answered, so no user session or app was running.

Measured	Silverblue	Workstation
Kernel / GNOME Shell	7.2.11 / 51.0	7.2.11 / 51.0
RPMs in the base system	1,503	1,856
Apps installed as Flatpaks	19 (Fedora OCI remote)	0
Disk used after install	6,948 MiB	3,777 MiB
Root filesystem	composefs overlay, read-only	btrfs, read-write
btrfs compression active	No (fixable, see below)	Yes, zstd:1
Package tools	rpm-ostree, bootc, flatpak	dnf5, flatpak
Boot to login screen	17.7 to 21.8 s	12.7 to 15.1 s
Memory used at the login screen	1,227 to 1,238 MiB	957 to 985 MiB
Install htop	1 min 47 s, then reboot	5.0 s, usable at once
Install Google Chrome	1 min 58 s, then reboot	29.3 s
Undo the last change	3.65 s, then reboot	3.06 s

Most of the 3 GB disk gap is structural, so don’t expect a cleanup to close it. On Silverblue the whole operating system lives as content-addressed objects in /sysroot/ostree/repo, and the preinstalled apps bring their own GNOME runtime under /var/lib/flatpak instead of sharing the host’s libraries. Workstation installs the same apps as RPMs, shares libraries with the host, and writes them through zstd compression. Expect the Silverblue figure to grow by roughly one deployment’s worth of changed objects each time an update is staged, and to drop again when the old deployment is pruned.

GNOME Software makes the split visible. On Silverblue it shows every preinstalled app with its own size, because each one is a Flatpak with its own sandbox.

Workstation’s list carries no sizes and includes Boxes, which Silverblue leaves out of its default set. Those entries are host RPMs, so removing one through Software runs a PackageKit transaction against the live system rather than deleting a sandbox.

Both editions came up with only the Fedora Flatpak remote configured, and Software asked about third-party repositories on first launch on each. If you plan to live on Flatpaks, follow the Flathub setup for Fedora on either edition first.

A system directory root cannot write

Workstation stops an unprivileged user from writing to /usr, but root can still change anything, which is how a careless sudo make install or a curl-piped installer ends up overwriting distro files. On Silverblue the same write fails for root too. Try it on each machine, then remove the test file on Workstation with sudo rm -f /usr/bin/write-test:

sudo touch /usr/bin/write-test

Workstation accepted it silently. Silverblue refused it, because / is a composefs overlay mounted read-only and /usr sits inside it. A bad installer running as root can still litter /etc or /var, but without explicitly unlocking /usr it can’t swap a system binary in place, so any change to the OS has to arrive as a new deployment that rpm-ostree status shows you.

touch: cannot touch '/usr/bin/write-test': Read-only file system

Everything a user or an admin is allowed to change lives under /var and /etc instead. The top-level paths you are used to are symlinks into /var on Silverblue, which you can confirm with a listing:

ls -ld /opt /usr/local /home /root

Each one points into the writable state directory, so your files survive every update and rollback.

lrwxrwxrwx. 1 root root  8 Jan  1  1970 /home -> var/home
lrwxrwxrwx. 1 root root  7 Jan  1  1970 /opt -> var/opt
lrwxrwxrwx. 1 root root 12 Jan  1  1970 /root -> var/roothome
lrwxrwxrwx. 1 root root 15 Jan  1  1970 /usr/local -> ../var/usrlocal

/etc is writable, and ostree keeps a three-way merge of it across deployments. sudo ostree admin config-diff lists every /etc file that differs from the image default, which makes it the fastest audit of local configuration drift on a Silverblue box. Expect a handful of system-generated entries even on a fresh install (machine-id, passwd, shadow, ld.so.cache, the tuned profile and the NetworkManager connection), and look past those for the edits that matter. Workstation has no equivalent; there you compare rpm -Va output against packaged files.

Host packages: seconds against a reboot

On Workstation a package is usable the moment dnf prints Complete!, because dnf writes straight into the live /usr. That speed is also the risk, since a half-finished transaction or a bad scriptlet lands on the system you are running. Installing htop with its one dependency took five seconds:

time sudo dnf install -y htop

htop ran the moment the prompt came back.

[3/4] Installing hwloc-libs-0:2.14.0-3. 100% | 116.3 MiB/s |   2.9 MiB |  00m00s
[4/4] Installing htop-0:3.5.3-1.fc45.x8 100% | 570.2 KiB/s | 522.8 KiB |  00m01s
Complete!

real	0m5.011s

Silverblue has no dnf on the host. You layer the RPM onto the image with rpm-ostree, which loads the full Fedora repo metadata (75,853 solvables), builds a new deployment with htop inside, and stages it for the next boot:

time sudo rpm-ostree install htop

We timed it at 1 minute 47 seconds for 2.5 MB of packages, and htop still wasn’t on the running system when it ended. Almost all of that time goes into loading repo metadata and writing a new OSTree commit, so a tiny package costs nearly as much as a large one.

Will download: 2 packages (2.5 MB)
Downloading from 'fedora'...done
Importing packages...done
Checking out packages...done
Running systemd-sysusers...done
Running pre scripts...done
Running post scripts...done
Running posttrans scripts...done
Writing rpmdb...done
Writing OSTree commit...done
Staging deployment...done
Added:
  htop-3.5.3-1.fc45.x86_64
  hwloc-libs-2.14.0-3.fc45.x86_64
Changes queued for next boot. Run "systemctl reboot" to start a reboot

real	1m47.375s

rpm-ostree status now shows two deployments. The booted one (marked with the dot) is unchanged, and the new one above it carries LayeredPackages: htop:

For a change that only adds packages you can skip the reboot. apply-live copies the staged tree onto the running system, and here it finished in 3.6 seconds:

sudo rpm-ostree apply-live

rpm-ostree reports what it added to the running tree. It is purely additive by default, and replacing packages or files needs --allow-replacement, so keep it for quick additions and let anything that swaps a library wait for the reboot.

Computing /etc diff to preserve...done
Updating /usr...done
Updating /etc...done
Running systemd-tmpfiles for /run and /var...done
Added:
  htop-3.5.3-1.fc45.x86_64
  hwloc-libs-2.14.0-3.fc45.x86_64
Successfully updated running filesystem tree.

Keep layering for things that must live on the host, such as drivers, a VPN client or a shell. Everything else belongs in a Flatpak or a Toolbx container, where installs take seconds on either edition. The rpm-ostree package management guide covers removal, overrides and the layering limits in more depth.

Third-party RPMs that write to /opt

Vendor RPMs are where Silverblue still pushes back. Both editions ship the google-chrome repository disabled, and on Workstation one flag enables it for a single install. Chrome landed in /opt/google in 29.3 seconds:

sudo dnf install -y --enablerepo=google-chrome google-chrome-stable

On Silverblue we tried the same flag first, and it failed before touching the network.

Error: “–enablerepo currently only works in a container build”

rpm-ostree accepts --enablerepo only inside a container image build, so on a running Silverblue host the command stops immediately:

error: --enablerepo currently only works in a container build

You have to enable the repository in a file instead, and that file is not where older guides say it is. On both editions /etc/yum.repos.d/ is empty, and the shipped repo definitions live in /usr/share/dnf5/repos.d/, which is read-only on Silverblue. A file with the same name in /etc/yum.repos.d/ overrides the shipped one, so copy it there and flip enabled:

sudo cp /usr/share/dnf5/repos.d/google-chrome.repo /etc/yum.repos.d/
sudo sed -i "s/^enabled=0/enabled=1/" /etc/yum.repos.d/google-chrome.repo

Layer the package once the repository is enabled. The copy in /etc survives updates because ostree carries /etc changes forward into each new deployment, so you do this once per machine, not once per update:

sudo rpm-ostree install google-chrome-stable

rpm-ostree downloaded 148.9 MB, built a new deployment in 1 minute 58 seconds and asked for a reboot. After the reboot Chrome runs, but its files are not in a writable /opt. rpm-ostree relocates them into the image and leaves a symlink behind:

readlink -f /opt/google/chrome/chrome

Chrome resolves to a path under /usr/lib/opt, inside the read-only image.

/usr/lib/opt/google/chrome/chrome

Chrome gets away with it because it never writes to its own install directory. Any vendor package that does, such as an agent that drops state or plugins under /opt/vendor, will fail at runtime with Read-only file system. A test write as root returned exactly that on our box. Fedora’s Atomic Desktops troubleshooting page calls the /opt handling a partial solution for the same reason. Check where a vendor RPM writes before you layer it, and prefer the vendor’s Flatpak when one exists.

Undo: one package or the whole system

Workstation undoes changes one transaction at a time. Removing the Chrome install with dnf history took 3.06 seconds and freed 444 MiB:

sudo dnf history undo last -y

dnf removes the package and the font dependency it pulled in, and the change is live at once because nothing needs to boot:

After this operation, 444 MiB will be freed (install 0 B, remove 444 MiB).
Running transaction
[1/3] Prepare transaction               100% |   2.0   B/s |   2.0   B |  00m01s
[2/3] Removing google-chrome-stable-0:1 100% |   1.7 KiB/s | 268.0   B |  00m00s
[3/3] Removing liberation-fonts-all-1:2 100% | 116.0   B/s | 100.0   B |  00m01s
Complete!

An empty /opt/google directory stayed behind, and that is the general limit of package-level undo: it reverses what the RPM database knows about, not what scriptlets, config edits or a manual make install did around it. Undoing a bad Mesa or glibc update this way also means reinstalling older builds that may already be gone from the mirrors. Kernels are the exception, because dnf keeps the last three installed and GRUB lists them.

Silverblue rolls back the entire deployment instead. The previous tree is still on disk, so the rollback only swaps the boot order and finishes in seconds no matter how large the change was:

sudo rpm-ostree rollback

rpm-ostree lists everything the swap removes, here both layered packages and their dependencies, and queues it for the next boot.

Moving '6436fe470b9ac4fb9bbf86803d4aaedf4b4f5c2252835fbbb9ce98d81de7f32d.0' to be first deployment
Transaction complete; bootconfig swap: no; bootversion: boot.1.0, deployment count change: 0
Removed:
  google-chrome-stable-156.0.8078.47-1.x86_64
  htop-3.5.3-1.fc45.x86_64
  hwloc-libs-2.14.0-3.fc45.x86_64
  liberation-fonts-all-1:2.1.5-16.fc45.noarch
Changes queued for next boot. Run "systemctl reboot" to start a reboot

After the reboot neither htop nor google-chrome existed on the system. The same move works when an OS update breaks graphics or boot: pick the previous entry in the boot menu once, then make it the default with rpm-ostree rollback. Your home directory is untouched, but /etc returns to the state of the deployment you roll back to, because each deployment carries its own /etc and only /var is shared.

A rollback from a bad OS update does not stay rolled back on its own. With the default GNOME Software settings described in the next section, the desktop stages the newest update again in the background, and the following reboot boots straight back into the broken version. Until a fixed update lands, switch off download-updates as shown below. sudo rpm-ostree cleanup -p drops a restaged deployment too, but Software refreshes every minute or two in a live session and can stage it again, so treat it as a stopgap and run it right before the reboot.

Updates GNOME Software stages on its own

Know this behaviour before you put Silverblue on someone else’s laptop. With the default download-updates setting, GNOME Software on Silverblue doesn’t just download an OS update. It builds and stages the new deployment through rpm-ostreed in the background, and the next reboot of any kind boots into it. On sb-lab01 the staged update was ready two and a half minutes after GNOME Software’s first background refresh in the new session, with nobody opening the Updates tab:

sudo journalctl -b -1 -u rpm-ostreed | grep -E "Initiated txn|Txn .* successful"

Look at the Upgrade line: the gnome-software service started it, not a person or a timer.

Oct 21 12:23:54 sb-lab01 rpm-ostree[1022]: Initiated txn RefreshMd for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:23:55 sb-lab01 rpm-ostree[1022]: Txn RefreshMd on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:23:55 sb-lab01 rpm-ostree[1022]: Initiated txn AutomaticUpdateTrigger for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:24:02 sb-lab01 rpm-ostree[1022]: Txn AutomaticUpdateTrigger on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:24:54 sb-lab01 rpm-ostree[1022]: Initiated txn RefreshMd for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:24:55 sb-lab01 rpm-ostree[1022]: Txn RefreshMd on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:24:55 sb-lab01 rpm-ostree[1022]: Initiated txn AutomaticUpdateTrigger for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:24:59 sb-lab01 rpm-ostree[1022]: Txn AutomaticUpdateTrigger on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:25:48 sb-lab01 rpm-ostree[1022]: Initiated txn Upgrade for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:26:24 sb-lab01 rpm-ostree[1022]: Txn Upgrade on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:26:33 sb-lab01 rpm-ostree[1022]: Initiated txn RefreshMd for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:26:42 sb-lab01 rpm-ostree[1022]: Txn RefreshMd on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:26:42 sb-lab01 rpm-ostree[1022]: Initiated txn AutomaticUpdateTrigger for client(id:gnome-software dbus:1.95 unit:gnome-software.service uid:1000): /org/projectatomic/rpmostree1/fedora
Oct 21 12:26:49 sb-lab01 rpm-ostree[1022]: Txn AutomaticUpdateTrigger on /org/projectatomic/rpmostree1/fedora successful
Oct 21 12:29:25 sb-lab01 rpm-ostree[1022]: Initiated txn KernelArgs for client(id:cli dbus:1.108 unit:session-7.scope uid:0): /org/projectatomic/rpmostree1/fedora

Our next systemctl reboot, which we ran for an unrelated change, booted straight into the staged update, and rpm-ostree status afterwards showed the box running the build GNOME Software had picked. Nothing else on the system pulls updates, because every system-level updater ships switched off:

• rpm-ostreed-automatic.timer is disabled.
• bootc-fetch-apply-updates.timer is disabled.
• rpm-ostree status -v reports AutomaticUpdates: disabled.

So the desktop session is the updater. On a personal desktop that is what you want, because the rollback above covers a bad update and the user reboots when they choose. On a shared machine where reboots are scheduled, a staged update lands at whatever hour the reboot runs, so either treat every reboot as an update window or switch the setting off for every account. gsettings only changes it for the desktop user who runs it, so set a system default in dconf and lock it:

sudo mkdir -p /etc/dconf/db/local.d/locks
printf "[org/gnome/software]\ndownload-updates=false\n" | sudo tee /etc/dconf/db/local.d/00-software-updates
echo "/org/gnome/software/download-updates" | sudo tee /etc/dconf/db/local.d/locks/software-updates
sudo dconf update

Any user can confirm the setting is off and can no longer be changed from their session:

gsettings get org.gnome.software download-updates
gsettings writable org.gnome.software download-updates

Both lines print false, and updates wait until someone runs rpm-ostree upgrade. To hand the choice back to users once a fixed update has landed, remove both files and rebuild the database, after which both lines print true again:

sudo rm /etc/dconf/db/local.d/00-software-updates /etc/dconf/db/local.d/locks/software-updates
sudo dconf update

Leave the lock in place on machines where nobody should be surprised by a reboot that changes the OS.

Btrfs compression that Silverblue never turns on

Fedora formats both editions with btrfs and writes compress=zstd:1 into /etc/fstab. On Workstation the option is live. On Silverblue it is not, on any subvolume, and nothing tells you. The installer wrote the same request into Silverblue’s fstab:

grep btrfs /etc/fstab

Every btrfs line asks for zstd:

UUID=81db790e-9e3c-4759-8270-7b463b481e21 / btrfs subvol=root,compress=zstd:1,ro 0 0
UUID=81db790e-9e3c-4759-8270-7b463b481e21 /home btrfs subvol=home,compress=zstd:1 0 0
UUID=81db790e-9e3c-4759-8270-7b463b481e21 /var btrfs subvol=var,compress=zstd:1 0 0

Now compare what the kernel actually mounted, because fstab is only a request and /proc/mounts is what the filesystem is doing.

grep btrfs /proc/mounts

No compress option appears anywhere, including /var and /var/home:

/dev/sda3 /etc btrfs rw,seclabel,relatime,discard=async,space_cache=v2,subvolid=258,subvol=/root 0 0
/dev/sda3 /sysroot btrfs ro,seclabel,relatime,discard=async,space_cache=v2,subvolid=258,subvol=/root 0 0
/dev/sda3 /sysroot/ostree/deploy/fedora/var btrfs rw,seclabel,relatime,discard=async,space_cache=v2,subvolid=258,subvol=/root 0 0
/dev/sda3 /var btrfs rw,seclabel,relatime,discard=async,space_cache=v2,subvolid=256,subvol=/var 0 0
/dev/sda3 /var/home btrfs rw,seclabel,relatime,discard=async,space_cache=v2,subvolid=257,subvol=/home 0 0

Compression on btrfs is a filesystem-wide mount option, and the filesystem is first mounted from the kernel command line, which only carries rootflags=subvol=root. Workstation fixes that later when systemd-remount-fs remounts / with the fstab options. On Silverblue / is a composefs overlay, the remount is refused, and the unit fails on every boot. It failed on all eight boots of sb-lab01 before the fix below:

journalctl -b -u systemd-remount-fs --no-pager

Every boot logs the same refusal from the overlay, so the compression request is dropped without a desktop notification.

Oct 21 12:31:39 sb-lab01 systemd-remount-fs[718]: mount: /: fsconfig() failed: overlay: No changes allowed in reconfigure.
Oct 21 12:31:39 sb-lab01 systemd-remount-fs[718]:        dmesg(1) may have more information after failed mount system call.
Oct 21 12:31:39 sb-lab01 systemd-remount-fs[714]: /usr/bin/mount for / exited with exit status 32.
Oct 21 12:31:39 sb-lab01 systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE
Oct 21 12:31:39 sb-lab01 systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'.
Oct 21 12:31:39 sb-lab01 systemd[1]: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.

Fedora has tracked this since composefs arrived on the Atomic desktops, and the upstream workaround in the Fedora discussion thread on ignored root mount options moves the option to the kernel command line. Check the current arguments first, because --delete has to match the existing rootflags value exactly:

rpm-ostree kargs

On a default install the value reads rootflags=subvol=root:

ostree=/ostree/boot.1/fedora/f2fb52c56fd2769cd2843ad3a6630edfeffbc64f931dc600349bb966a93eff13/0 rhgb quiet root=UUID=81db790e-9e3c-4759-8270-7b463b481e21 vconsole.keymap=us rootflags=subvol=root rw

Replace the root flags in one rpm-ostree call:

sudo rpm-ostree kargs --delete=rootflags=subvol=root --append=rootflags=subvol=root,compress=zstd:1

A single --replace does not work here, because the value itself contains an equals sign and rpm-ostree answered error: No karg 'rootflags=subvol' found. Next, comment out the / line in fstab so systemd stops trying to remount the overlay:

sudo sed -i "s|^\(UUID=[^ ]* / btrfs .*\)|# \1|" /etc/fstab
systemctl reboot

If that boot fails, the previous GRUB entry still has the old kernel arguments; boot it and run rpm-ostree rollback to make it the default again. After a good reboot all five btrfs mounts carry the option and systemctl --failed lists nothing:

grep btrfs /proc/mounts | grep -c compress=zstd:1

All five mounts now report zstd.

5

We did not measure a space saving, because only data written after the change is compressed. Existing files, including the ostree repository, stay as they are until they are rewritten, which on Silverblue happens naturally as updates replace objects.

Boot time and memory at the login screen

Silverblue reached the login screen 3 to 7 seconds later than Workstation on every boot, and used about 250 MiB more memory once it got there. The kernel and initrd phases were the same on both, about 1 and 3 seconds; the whole gap is in userspace:

Boot	Silverblue total	Silverblue userspace	Workstation total	Workstation userspace
1	19.754 s	15.461 s	12.720 s	8.801 s
2	17.736 s	13.742 s	14.560 s	9.973 s
3	21.750 s	17.095 s	15.092 s	10.308 s

systemd-analyze blame on Silverblue put fedora-atomic-desktop-appstream-cache-refresh.service near the top on two of the three boots at 7.4 and 7.7 seconds, a unit Workstation doesn’t have, and the critical chain shows plymouth-quit-wait.service holding the login screen for 8.3 seconds against 4.1 on Workstation. Neither number changes how the desktop feels once you are logged in, and on a laptop that suspends instead of rebooting you will rarely see it. The memory difference is not one big process: the largest resident processes (gnome-shell at about 250 MiB, ibus, Xwayland, firewalld) were within a few MB of each other on both machines.

Audit checklist before you commit to Silverblue

Run through these on a Silverblue install before you put real work on it. Each line is a condition that should hold, and the matching section above shows how we checked it.

1. grep btrfs /proc/mounts shows compress=zstd:1 on every btrfs mount, and systemctl --failed is empty.
2. rpm-ostree status lists only the layered packages you meant to add; anything else belongs in a Flatpak or a Toolbx container.
3. Every vendor RPM you layered writes nothing under /opt at runtime.
4. Repo overrides you need live as copies in /etc/yum.repos.d/, never as edits in /usr/share/dnf5/repos.d/.
5. The GNOME Software download-updates setting matches how the machine is rebooted, and it is off while you sit on a rollback.
6. A previous deployment exists in rpm-ostree status, so rpm-ostree rollback has something to return to.
7. sudo ostree admin config-diff shows no /etc change you can’t explain beyond the system-generated files.

If a machine fails items 2 or 3 every week, it wants Workstation, and the Fedora Workstation install guide plus the post-install checklist get it set up. If it passes all seven, Silverblue gives you a desktop where a bad update costs one reboot, and the custom bootc image route lets you bake your layered packages into an image instead of layering them by hand. For the release itself, the Fedora 45 changes overview lists what both editions picked up.