Updating the Host

The Host page has an Updates card showing the installed version, channel, install method, and the command appropriate for that installation. The public project does not currently publish a signed update manifest. Without an operator-managed feed, the card reports that no release has been published instead of claiming the host is current.

Your channel comes from the repository this host installs from, see Release Channels for what each track means and how to move a host between them. The Updates card never switches channels for you.

Operators can set SLIPSTREAM_UPDATE_FEED to an HTTPS endpoint that serves the signed channel manifests. The host verifies those manifests against its built-in keys and rejects tampered or replayed data.

Updating, per install method

The console shows the right one of these automatically; for reference:

rpm-ostree layer: rpm-ostree upgrade is not enough

rpm-ostree upgrade upgrades the base image and only re-resolves layered packages when the base actually changes, so on a base that sits still (a pinned tag, a paused rebase) it keeps reporting "No updates available" while newer Slipstream RPMs are sitting in the repo. Force rpm-ostree to re-resolve just the Slipstream layer, removing and re-adding the same names in one transaction:

sudo rpm-ostree refresh-md --force
sudo rpm-ostree update \
  --uninstall slipstream --uninstall slipstream-web \
  --install   slipstream --install   slipstream-web
systemctl reboot

Name only the packages you actually layered, rpm-ostree status lists them. The new version is staged; it activates on the next boot.

Two things to know. The re-resolve picks the highest version across every enabled /etc/yum.repos.d/slipstream*.repo, so if the canary repo is enabled alongside the stable one, canary wins and the box quietly tracks canary, enable exactly the channel you want (see Release Channels). And if this box runs the Bazzite sysext, the sysext shadows any layered copy: update with sudo slipstream-sysext update instead.

Restart after a package update

Restart the host to pick up the new binary:

systemctl --user restart slipstream-host

If the update also brought a new slipstream-web (the console itself, it ships as a separate package and a separate user service), restart that too, and do it first; the page blinks and reconnects:

systemctl --user restart slipstream-web
systemctl --user restart slipstream-host

A pacman -Syu upgrades every installed Slipstream package, so it always needs both. The apt and dnf commands above name one package, so they usually don't, to move the console and the host together, name both: sudo apt install --only-upgrade slipstream-host slipstream-web (apt) or sudo dnf upgrade slipstream slipstream-web (dnf). If you enabled the plugin/script runner, it is a third unit: systemctl --user restart slipstream-scripting.

slipstream-sysext update prints the same restart hint when it's needed.

One-click updating (opt-in)

The apt, dnf, Bazzite-sysext, and rpm-ostree installs can one-click update via a small root helper the packages ship (ss-update + a slipstream-update.service oneshot). It's off until you opt in, because a web button that ends in root deserves an explicit decision:

sudo usermod -aG slipstream-update $USER    # takes effect within a minute, no re-login needed

The console re-checks group membership every minute, so the Update now button replaces the opt-in hint on its own, there's no need to log out and back in.

That group membership is the entire grant, a polkit rule lets its members start exactly that one service, whose only job is "run this system's normal package update for the Slipstream packages, then prove the new binary runs". The button never chooses versions or URLs; your package manager's own signed repositories stay the source of truth. The card shows the opt-in command until you've done this, and the manual command always keeps working.

Notes per method: on rpm-ostree the update is staged and the card will say so, reboot to finish (the console never reboots your machine). On Arch/pacman the button additionally requires PACMAN_FULL_SYSUPGRADE=1 in /etc/slipstream/update.conf, because the only safe pacman update is a full pacman -Syu, partial upgrades are how Arch boxes break, and we won't run one. After a successful update the host restarts itself and the page reconnects.

The Steam Deck on-device build gets the button too, with no opt-in (it's your own user's install, no root involved): it runs the same update.sh rebuild the docs describe, which compiles on the Deck, expect it to take a while; the card keeps showing progress and the log lands in ~/.config/slipstream/logs/update-steamos.log.

Updating a client

This page is about the host. The Android public APK is updated by downloading the latest APK from GitHub Releases. Decky and Flatpak bundles are updated by reinstalling a newer package. The per-platform table is in Install a Client -> Keeping a client up to date. A host and a client don't have to be on the same version, but keeping them close is the least surprising.

Turning the check off

The check contacts the configured release feed (GitHub Releases / your update manifest host) and nothing else, and sends nothing but a normal download request. If you'd rather the host never checks, add this line to the host's host.env:

SLIPSTREAM_UPDATE_CHECK=0

host.env lives at ~/.config/slipstream/host.env, see Configuration. Then restart the host: systemctl --user restart slipstream-host. The card then shows checks as disabled; everything else keeps working.

SLIPSTREAM_UPDATE_APPLY=0 in the same file removes the Update now button; the card shows the manual command instead.

If the card says the feed is stale

"Feed hasn't changed in over 45 days" means checks succeed but nothing new arrives. Usually that just means no release happened for a while; if the releases page shows something newer than the card does, something between this host and the feed is pinning old data, worth a look at proxies or DNS on the way to the release feed. That comparison only works on a stable host: the releases page is stable-only, so a canary host being "behind" it means nothing.

Next

• Something went wrong during or after an update? Troubleshooting.
• Want to remove Slipstream instead, or find out what an uninstall leaves behind? Uninstalling.