Use this checklist alongside each release’s notes. It covers preparation, the update itself and acceptance afterwards, so a finished download is followed by a working photo library.
Before the maintenance window
- Record your current server, Manager and app versions, installation method and storage paths.
- Read the release notes, including required app versions and database changes.
- Create a database checkpoint and a separate media backup. Keep the matching deployment configuration and recovery secrets.
- Pause bulk imports and let active operations settle. Tell other users when access will pause.
- Check free space for images, database work and recovery files.
- Keep a small test list: sign-in, original photo, video, album, sharing and a new upload.
Manager installations
Open Updates, select an Eligible release, then choose Verify and review update. Read the recovery information before Update Frameleaf.
Manager checks compatible images and creates a database checkpoint. If the operation stops, preserve its state, fix the reported cause and use Resume safely. Cancel update and restart is offered while returning to the previous release is still safe. Once the new release can have changed the database or media, recovery moves forward; changing only the image back is not a rollback.
Native Synology installations
The Manager package and photo-library release update separately. Verify the downloaded SPK checksum, use Package Center → Manual Install, then open the app from DSM. In Updates, use Review update for an eligible library release and read the checkpoint, storage and service changes.
Keep storage folders and the existing HTTPS/port arrangement. Use the recovery action in Activity if the operation stops. The Synology guide covers the native package lifecycle.
Manual Docker Compose installations
Keep the same project, configuration, volume names and storage mappings. Compare the matching release’s Compose files before replacing yours, including custom worker, GPU and proxy overrides. Use the database image specified by that bundle.
From your existing Compose project, review the resolved images, pull and recreate the services with the commands in the upgrade guide. If a bundle renames a service, stop the old stack with its current Compose file before replacing it, and update scripts and proxy targets accordingly.
Keep volumes. Do not add the volume-removal option to an upgrade. Run one stack against each PostgreSQL data directory. Keep separate machine-learning services on the matching release too.
First-start acceptance
Database migrations and indexes can take time on a large collection. Let the process continue while it makes progress without errors. Then check:
- An administrator and an ordinary user can sign in.
- Representative originals open; a longer video plays.
- Albums and sharing show the intended content to the intended accounts.
- A small new upload completes and appears on another client.
- Background work has progressing queues and no unexplained repeated failures.
- Remote access works from outside the home network if you use it.
- Backup scheduling and destinations remain configured.
Keep the old recovery set until these checks and a new backup are complete.
Report a release experience that helps others
Reply with:
- Previous release → new release.
- Manager, NAS package or manual Compose.
- Approximate library size and storage type.
- Time spent applying the update versus rebuilding background results.
- The first error and the recovery action if something stopped.
- The acceptance checks you completed.
Remove tokens, recovery keys, private URLs and personal media details. Open a focused Bug reports topic for a reproducible problem and link it here, so the release discussion stays useful to everyone.
References: Upgrading · Backup and restore