Updates
Keep your server up to date
How your server learns about new releases, how to apply them per install method, and how to get back to a good state if an update misbehaves.
Your server checks in with us for new releases every couple of hours, and an admin can check on demand. What it never does is update itself behind your back: every install method requires a deliberate action from you, whether that's a button or a command.
Where updates show up#
Open Admin, then Settings, and find the Software Update card. It shows your version, the newest release on your channel, and the release notes, including the notes for any versions you skipped, so nothing ships past you unread. A small badge on the admin rail marks a waiting update.
If the card says it can't check for updates, that is a connectivity statement, not an update statement: your server couldn't reach us to ask. Streaming at home is unaffected.
You can also wire an Update available notice into your notification channels under Admin, then Notifications.
Applying an update#
What the card offers depends on how you installed:
Linux one-liner, macOS, and Windows installs update in place: press Restart & update, the server downloads the release, swaps itself, and comes back on the new version. On Windows, the update needs one approval in a system prompt on the server machine itself, so be near the box or its remote desktop.
Docker (including most NAS setups): the card shows the exact commands, which come down to:
docker compose pull && docker compose up -d
Or use the tofa update helper if you installed with the one-liner compose setup. On Unraid, use force update on the container in the Docker tab; Install on Unraid has the steps.
Package installs (apt, dnf, pacman) update through your package manager like everything else on the machine; the card shows the matching command.
A few honest edges:
- If someone is watching, the update waits. The card tells you and offers Update anyway if you'd rather not wait for the credits.
- In-place updates need the built-in database. If you run your own PostgreSQL, update via your install method's normal mechanism instead; the card says so rather than offering a button that would fail.
- Every release is cryptographically signed, and your server verifies the signature before touching anything.
Channels#
The update card offers three channels: stable, beta, and nightly. During the beta, everything ships on the beta channel and that is where your server already is. Leave it there; the other channels exist for what comes after the beta, and switching today just means waiting longer for releases.
Before a big jump#
In-place updates take a database backup automatically before touching anything, and refuse to proceed if the backup fails. Docker updates don't get that for free, because the container swap happens outside the server. Before jumping several versions on Docker, take a backup first: Admin, then Settings, then Database, then Backup Now. It costs a minute. See Back up your server.
If an update goes wrong#
- In-place installs roll back by themselves. If the new version fails to start repeatedly, the server restores the previous version and comes back up on it.
- Database first. Updates migrate the database forward automatically, and an older version may not be able to read a migrated database. That is what the pre-update backup is for: restore it under Admin, then Settings, then Database, and you are back where you started.
- Going back a version on Docker is re-pinning the previous image tag in your compose file and running
docker compose up -d. On a one-liner install, re-run the installer with the version pinned:
curl -fsSL https://get.tofa.tv | TOFA_VERSION=0.9.28 sh
Pinning on Docker
The default compose file tracks the rolling beta image tag, so docker compose pull always moves you forward. If you want a server that never moves until you say so, pin a version tag in the compose file and change it deliberately.
Still stuck? Getting help & feedback covers what to send us.