Jellyfin 12 Upgrade Preparation: Backup, Plugins and Migration Checklist

Quick answer

Jellyfin 12 is not stable yet. RC5 is the current preview release as of 13 August 2026, so most home-server users should prepare now and wait for the stable release.

Before upgrading:

1. Update the existing server to Jellyfin 10.11.11 where practical. Jellyfin says 10.10.7 or any 10.11 release can upgrade, but recommends 10.11.11.
2. Stop Jellyfin and create an offline, restorable copy of its data and configuration.
3. Record the current container image or package version, volume mappings, hardware devices and network settings.
4. Inventory plugins and custom integrations. Do not assume every third-party plugin will be ready immediately.
5. Check free space in the Jellyfin data location and the destination holding the backup.
6. Schedule a maintenance window. The first Jellyfin 12 start runs database migrations and must not be interrupted.
7. Keep the old version and backup available until libraries, users, watched status, playback and remote access have been verified.

Do not install an RC on the only copy of a household media server unless you deliberately want to test pre-release software and can restore the previous data.

---

Current Jellyfin 12 status

Jellyfin Server 12.0 RC5 was published on 11 August 2026. It is a preview build for testing before the final public release. It is not delivered automatically through the normal Apt repository or the Docker latest tag.

The Jellyfin project describes performance as the main goal of version 12. The release also changes the version number from 10.12.x to 12.x; the missing 10. does not mean you have skipped two releases.

The confirmed upgrade notes for RC5 say:

• the source server must be on 10.10.7 or 10.11.x
• 10.11.11 is the preferred starting point
• the first start runs migrations and can take several minutes
• the migration must not be interrupted
• external plugins need extra care during RC testing
• RC packages use preview-specific download routes or image tags

Check the official Jellyfin releases page before acting. When stable ships, this guide will be re-verified against the final release notes.

---

Who should prepare now

Prepare in advance if your Jellyfin server:

• is used by other people in the household
• runs in Docker or Docker Compose
• uses third-party plugins
• is available through a reverse proxy or private remote-access service
• uses Intel, AMD or NVIDIA hardware transcoding
• has a large or long-lived database
• depends on Sonarr, Radarr or another service using the Jellyfin API
• has no recently tested restore process

Preparation does not require changing the running server today. Most of the work is recording the current state and proving that the backup can be restored.

---

What not to do yet

Until Jellyfin 12 stable is available:

• do not change a working production container from latest to preview
• do not add Jellyfin’s unstable Apt component to a normal household server
• do not delete the current image or package cache
• do not update all containers and the host operating system in the same maintenance window
• do not assume a container rollback will reverse database migrations

Jellyfin does not support downgrading migrated data to an older server version. Rolling back the application also requires restoring data from the backup taken before the upgrade.

---

Step 1: Record the current server state

Start by recording the exact version and installation method.

In the Jellyfin dashboard, open:

Dashboard → General

For a native Ubuntu installation, record:

dpkg -l | grep -E '^ii\s+jellyfin'
systemctl status jellyfin --no-pager

For Docker, record the running image and mounts:

docker inspect jellyfin --format '{{.Config.Image}}'
docker inspect jellyfin --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'
docker inspect jellyfin --format '{{json .HostConfig.Devices}}'

If your container has a different name, replace jellyfin with that name.

Save a copy of the Compose file and any environment file used by the service. Remove passwords, tokens and private addresses before sharing those files with anyone.

Record at least:

Jellyfin version:
Install method:
Container image or package source:
Configuration path:
Cache path:
Media mounts:
Hardware device mappings:
Reverse proxy or Tailscale route:
Installed plugins:
Date recorded:

---

Step 2: Reach a supported starting version

Jellyfin’s RC5 notes support upgrading from 10.10.7 or 10.11.x and recommend 10.11.11.

Check the version first. If you are on an older release, upgrade through the supported intermediate version and verify it before attempting Jellyfin 12.

Do not combine these into one unverified jump:

old Jellyfin release → 10.11.11 → Jellyfin 12

After reaching 10.11.11, confirm:

• the server starts normally
• every expected library is present
• users and watched status are intact
• one known file Direct Plays
• one known transcode works, if you use transcoding
• plugins load without errors
• logs contain no unresolved migration failure

Keep the server on this known-good state until Jellyfin 12 stable is published.

---

Step 3: Check storage and free space

Check the filesystems holding Jellyfin data, container configuration and backups:

df -h

For a Docker bind mount, identify the host path first:

docker inspect jellyfin --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

Then check its size:

sudo du -sh /path/to/jellyfin/config

Replace the example path with the real host path.

Jellyfin’s built-in backup feature checks for at least 5 GB of free space, but the project warns that subtitles and Trickplay data can require considerably more. The safe target is enough room for the complete backup, migration working space and a margin for logs and temporary files.

Do not store the only backup inside the directory that will be migrated.

---

Step 4: Create a restorable backup

Jellyfin’s own guidance is clear: after a new version migrates the data, going back requires restoring a pre-upgrade backup.

Use the built-in backup feature where available, then copy that backup away from the active Jellyfin data directory. For an additional filesystem-level copy, stop Jellyfin first so the database is not changing while it is copied.

Native Ubuntu example

Stop the service:

sudo systemctl stop jellyfin

Confirm it is stopped:

systemctl is-active jellyfin

Copy the Jellyfin configuration and data locations used by your installation to a dated backup destination. Verify the paths against the Jellyfin dashboard and the official configuration documentation rather than assuming they are default.

Start Jellyfin again after the copy:

sudo systemctl start jellyfin
systemctl status jellyfin --no-pager

Docker or Docker Compose example

Stop only the Jellyfin service:

docker compose stop jellyfin

Confirm it is stopped:

docker compose ps jellyfin

Back up the host directory mapped to /config. If /cache is mapped separately, decide whether to copy it based on your recovery plan; the persistent /config data is the critical part.

Then start the existing version again:

docker compose start jellyfin
docker compose ps jellyfin

Prove the backup is usable

A successful copy command is not a restore test.

At minimum, verify:

find /path/to/backup -maxdepth 2 -type f | head -50
du -sh /path/to/backup

The strongest test is restoring the backup into a temporary isolated Jellyfin instance with no access to the live configuration. Do not expose the test instance publicly or let it write to your real media directories.

Read the official Jellyfin backup and restore guide before the upgrade window.

---

Step 5: Audit plugins

Open:

Dashboard → Plugins → My Plugins

Create a list containing:

Plugin	Version	Source	Essential?	Jellyfin 12 status
Example	Current version	Official or external	Yes or no	Confirmed, unknown or incompatible

Treat an unknown plugin as a reason to wait, especially when it provides authentication, metadata, notifications or another service integration.

The RC instructions tell testers to disable external plugins and use the unstable plugin repository because incompatible plugins can fail to load or cause side effects. Stable-release instructions may differ, so check the final release notes and the plugin maintainer’s compatibility statement.

Do not switch a production server to the unstable plugin repository merely to prepare for the stable release.

---

Step 6: Check HTTPS and remote access

Jellyfin 10.11’s release notes said the internal TLS interface was planned for removal in Jellyfin 12 and recommended terminating HTTPS at a reverse proxy.

Before upgrading, identify how clients reach the server:

Local HTTP on port 8096
Jellyfin built-in HTTPS on port 8920
Reverse proxy such as Caddy, Nginx or Traefik
Private access through Tailscale or another VPN

If you currently depend on Jellyfin’s built-in HTTPS settings, check the final Jellyfin 12 release notes before upgrading. Move to a maintained reverse proxy or private-access design first if the final release confirms that your current method is no longer supported.

Do not open Jellyfin’s HTTP port directly to the public internet as a workaround.

---

Step 7: Record hardware transcoding

An application upgrade should not become an unplanned transcoding rebuild.

Record the current devices and settings before changing anything:

ls -la /dev/dri 2>/dev/null
lspci | grep -Ei 'vga|display|3d'

For Docker:

docker exec jellyfin ls -la /dev/dri
docker inspect jellyfin --format '{{json .HostConfig.Devices}}'

Capture the current Jellyfin playback settings and test one representative file now. Record:

Client:
File:
Playback mode:
Hardware acceleration method:
Video codec:
Audio codec:
Subtitles:
CPU or GPU behaviour:

Use the same file and client after the upgrade. This separates an upgrade regression from a pre-existing client or codec problem.

---

Step 8: Plan the maintenance window

Choose a period when nobody needs the server and you can observe the first start.

Allow time for:

1. a final stopped-service backup
2. the image or package update
3. database migrations
4. plugin checks
5. library and user verification
6. playback tests
7. restoring the old version and data if required

The Jellyfin 12 RC notes say the first start can spend several minutes running migrations. Large or unusual databases can take longer. Do not restart the host, stop the container or kill Jellyfin because the normal web interface appears unavailable.

Use the startup UI and logs to observe progress.

For Docker:

docker logs -f jellyfin

For a native Ubuntu service:

sudo journalctl -u jellyfin -f

---

Release-day upgrade plan

Do not run this plan until Jellyfin 12 stable appears on the official releases page and the final notes have been read.

Docker Compose

1. Confirm the Compose file, current image and /config host path.
2. Stop Jellyfin.
3. Take the final offline backup.
4. Pull the intended stable image.
5. Start only Jellyfin.
6. Follow logs until migrations and startup complete.
7. Run the verification checklist below.
8. Keep the previous image reference and pre-upgrade backup until the server has been stable for several days.

Avoid a broad docker compose pull if it would update unrelated services at the same time.

Native Ubuntu packages

1. Confirm Jellyfin 12 stable is present in the normal repository.
2. Stop Jellyfin and take the final offline backup.
3. Refresh package metadata.
4. Review the proposed package changes before accepting them.
5. Install the Jellyfin update.
6. Follow the service logs through migration and startup.
7. Run the verification checklist below.

Use the exact package instructions in the final Jellyfin 12 release notes; preview packages and repositories are deliberately different from the normal stable path.

---

Post-upgrade verification checklist

Do not call the upgrade complete when the login page first appears.

Verify:

• server version reports Jellyfin 12 stable
• server logs show no unfinished or failed migration
• all expected users can sign in
• watched status and favourites are present
• libraries and item counts look credible
• recently added media is present
• one local Direct Play file works
• one subtitle-heavy file works
• one hardware transcode works, if used
• mobile, television and browser clients reconnect
• remote access still works through the intended private route or reverse proxy
• plugins are compatible and enabled only when needed
• Sonarr, Radarr and other integrations still connect
• a normal library scan completes
• CPU, memory and disk use settle after migration and scanning
• the pre-upgrade backup remains untouched

Keep brief notes about anything that changed. They will make a rollback or later troubleshooting much easier.

---

Rollback plan

Rollback means restoring both parts of the previous state:

Previous Jellyfin application version
+
Pre-upgrade Jellyfin data and configuration

Reverting only the Docker image tag or package version is not enough after the database has been migrated.

A safe rollback sequence is:

1. stop Jellyfin
2. preserve the failed Jellyfin 12 data for diagnosis
3. restore the complete pre-upgrade data and configuration
4. restore the exact previous container image or package version
5. start Jellyfin without exposing it remotely
6. verify users, libraries and playback
7. investigate the failure before retrying

Write down the actual restore commands for your paths before the maintenance window. A rollback plan containing placeholders is not ready.

---

SmallGrid recommendation

For a normal household server, wait for Jellyfin 12 stable and read the final notes before pulling anything.

The useful work to do now is:

reach 10.11.11
record the current setup
create and verify an offline backup
audit plugins
check the remote-access design
capture a known playback baseline
write the rollback commands

That turns release day into a controlled application update instead of a database-recovery exercise.

---

Official sources

• Jellyfin Server releases
• Jellyfin upgrades and downgrades
• Jellyfin backup and restore
• Jellyfin configuration and data paths
• Jellyfin container installation
• Jellyfin 10.11 release notes

---

Related SmallGrid guides

• Jellyfin on Ubuntu: Low-Power Setup, Media Folders and Reboot Checks
• Jellyfin Docker Volume Paths Explained
• How to Check Why Jellyfin Is Transcoding
• Jellyfin Hardware Transcoding on Ubuntu
• Backups That Don’t Lie: 3-2-1 for Home Servers

---

Recap

Jellyfin 12 is close enough to prepare for, but RC5 is still a preview release.

Bring the existing server to a supported version, make a backup that can actually be restored, record plugins and infrastructure, and leave enough uninterrupted time for first-start migrations.

When stable is released, re-check the official notes, update one layer at a time, verify real playback and keep the old application plus pre-upgrade data until the new server has proved reliable.