Update or roll back your medialab Server from the web UI, with automatic backup

Updating a media server should be boring. In practice it is the moment things break: a database migration runs, a plugin stops loading, and the server never answers again. Normally you find out from a terminal, with apt and a few tense minutes of watching logs.

Self-Update removes the terminal from that loop. It is a Jellyfin plugin that updates or rolls back medialab Server (the MediaLab Works variant of Jellyfin 12.2) from the web UI. Before it installs anything it backs up the database and configuration, and if the new version does not start correctly the server returns to the previous one by itself. That is what makes a downgrade safe enough to do from a browser.

This tutorial covers the full path: checking versions, updating, rolling back, the daily check at 03:00 and the optional automatic update. The product page is at /products/jf-selfupdate and the detailed reference is the user guide.

Prerequisites

• medialab Server installed from its packages (medialab-server and medialab-server-web) on Debian or Ubuntu. Those packages bring the updater: /usr/lib/medialab-server/update.sh, the systemd units medialab-update.path and medialab-update.service, and the folder /var/lib/medialab-update.
• At least 1 GB free in /usr/lib. With less, the update stops with Not enough disk space.
• A MediaLab Works account with a license that covers the plugin (an active subscription, a lifetime license within its update window, the Jellyfin bundle, or the free 30-day trial) for updating and rolling back. Checking the versions works without a license.
• Administrator access to the Jellyfin dashboard. The plugin's API answers only Jellyfin administrators.

If medialab Server was installed from an archive, a portable install or a local build, the updater is missing: the page explains how to install from the packages and the actions are turned off. On official Jellyfin the page only shows how to switch to medialab Server, which keeps your data, users, libraries and plugins in place.

Step 1 — Install the plugin

From your private plugin repository (recommended). Jellyfin then installs and updates the plugin by itself.

1. In your MediaLab Works account open Licenses → Jellyfin plugin repository and click Create address. Copy it. It is private because it contains a token, so do not share it; you can regenerate or revoke it at any time.
2. In Jellyfin open Dashboard → Plugins → Repositories, click +, give it a name (for example MediaLab Works), paste the address and save.
3. In Dashboard → Plugins → Catalog find Self-Update by MediaLab, click Install, then restart the server.

From the public catalog. https://medialab.works/jellyfin/manifest.json lists every released MediaLab Works plugin; medialab Server adds it by itself.

Manually, from a zip file. Download jf-selfupdate_x.y.z.zip from Account → Licenses (the SHA-256 is shown next to the button), extract it into a new folder Self-Update by MediaLab_x.y.z.0 inside /var/lib/jellyfin/plugins/ on a package install, and restart the server.

Step 2 — Activate the license

1. Open Dashboard → Plugins → Self-Update by MediaLab and click License (the Server update page has a License button too).
2. Paste your license key and click Activate with key. The plugin binds the key to this server and shows the license as Active.
3. No key yet? On the same page enter your e-mail and start the 30-day trial, or buy a license; the plugin activates itself when the payment is done.

The license is checked once a day and at every server start, and again before an update, a rollback or an automatic update, unless it was checked shortly before. Without internet it stays valid for 7 days after the last successful check. Move license (release this server) on the License page frees the key for another server.

Step 3 — Check now and read the version list

Open Server update in the Jellyfin dashboard menu (administrators only).

• Installed version shows the medialab revision, the installed package (for example 12.2+ml4+deb12), the Jellyfin version and the newest version found at the last check.
• Click Check now. The updater reads the medialab repository, and the list Available versions shows every version, marked installed, newer or older.

Do this before you plan any maintenance. It is a read-only operation and works without a license.

Step 4 — Update to the newest version, or to a chosen one

• Update to x installs the newest version.
• Install next to a version installs that one.
• Roll back to the previous version goes to the version just below the installed one; Roll back next to an older version goes to that one. From medialab Server 12.2-ml.7 on, rolling back below 12.2-ml.7 is refused on purpose, because older versions have the less secure updater.

Every action asks for a confirmation first. Read it: it reminds you that the server restarts, so playback in progress stops; that the database and configuration are backed up first; and that if the server does not start correctly it returns to the current version by itself.

While an update is running, or while a request waits to be picked up, a new request is refused.

Step 5 — Watch the progress across the restart

Current operation follows the request: sent, running, The server is restarting…, then the page reloads by itself when the server answers again. The restart usually takes 1–3 minutes.

Last result then shows how it ended:

• succeeded;
• failed, rolled back automatically, with the version the server returned to;
• refused, with the reason, for example a version that is not in the repository.

In the rare case where the server does not answer after returning either, the page shows where the backup is.

Step 6 — The daily check at 03:00 and optional automatic updates

The scheduled task Check for medialab Server updates (category medialab, every day at 03:00) only checks the repository. It installs nothing.

In Automatic update:

• Install new versions automatically is off by default.
• Update hour (server time) is the hour at which a new version may be installed (04:00 unless you change it). Click Save.

With the automatic update on and a valid license, when the last check found a version newer than the installed one, it is installed at the chosen hour, at most once a day, with the same backup and automatic rollback as a manual update. You can change the time of the check itself in Dashboard → Scheduled Tasks.

Tips and troubleshooting

• No sudo, by design. The plugin runs as the jellyfin user and only writes a request file, /var/lib/medialab-update/request.json. The root service medialab-update validates it strictly: the action must be update, rollback or check, the version must have the exact package format (for example 12.2+ml4+deb12) and must exist in the repository. Only the medialab-server and medialab-server-web packages are installed, and only from the signed medialab apt repository, whose address is fixed on the server and never comes from the request. If a request is refused, that is this check doing its job.
• Free space first. Check /usr/lib before a big jump. Not enough disk space is the most common avoidable failure.
• Pick a quiet hour. An update restarts the server; playback in progress stops for 1–3 minutes. The 03:00 check and the default 04:00 install hour are a good starting point for a home server.
• Actions refused? Updating, rolling back and the automatic update need a valid license; without one, checking still works and nothing is deleted. Look at the License page.
• Plugin updates and lifetime licenses. The public catalog always offers the newest plugin version. When the update window of a lifetime license has ended, a newer plugin version is not licensed and stops with "version not licensed" until you use Roll back to x.y.z on its License page or buy an update pass. To avoid that, use your private repository, which offers only the versions your license allows, instead of the public catalog.
• Containers. In a container, update by pulling the new image tag (12.2-ml.N) and recreating the container; Self-Update shows the available versions but doesn't install packages in a container.

Conclusion

The valuable part is not the button, it is the order of operations behind it: back up the database and configuration, install, and if the server does not come back, return to the previous version and restore the backup automatically. With the daily check at 03:00 doing the reading and the automatic update off until you decide otherwise, you keep control without keeping a terminal open. Start at /products/jf-selfupdate, keep the guide and changelog at hand, and if something does not add up, the knowledge base and FAQ are the next stops.