Foxws
Stry

Upgrading

How to upgrade a running production install to a new stry release. For a first install, see Production Setup.

Before you start

  • Check the GitHub releases for breaking changes since your current version. Upgrading from 1.x to 2.0 needs extra steps: follow the upgrade guide.
  • Back up the database. See the backup example in Production Setup.
  • Images are tagged latest (the newest stable release), {major}.{minor} and the full version number. Use a specific tag instead of latest if you want to decide when to upgrade.

Pull the new image

podman pull ghcr.io/francoism90/stry:latest
lpod install production/app.quadlets --replace
# ...repeat for every other service whose image changed, such as stry-horizon...

--replace updates the Quadlet unit and restarts the service. It leaves existing secrets and volumes alone.

Instead of pulling and reinstalling each service by hand, you can let Podman do it. Every service in the production preset has AutoUpdate=registry set, so this updates all of them:

systemctl --user restart podman-auto-update

Podman pulls a new image for each of these services and restarts only the ones that changed. This runs once. To run it on a schedule, enable podman-auto-update.timer.

Auto-update only pulls images and restarts containers. It doesn't run Artisan commands, so you still need the migration and cache steps below.

Regenerate the Podman files, if needed

You only need this when the release notes mention changes to containers/stubs/*. If they do, repeat the option you used during setup (see Generate the Podman files), then reinstall the changed units with lpod install ... --replace.

Moving the idle check to lpod

Did you install stry-idle.timer from the ondemand preset? The idle check is part of lpod now. Upgrade lpod by running its installer again, then switch over once:

curl -fsSL https://github.com/foxws/lpod/releases/latest/download/install.sh | bash
lpod remove stry-idle.timer
lpod idle enable stry

If you installed the Quadlet units by hand from the templates instead of running podman:setup, you need to compare and update them yourself on every upgrade (see the note in Production Setup).

Run migrations

lpod stry artisan migrate --force

This runs both the database migrations and the settings migrations in database/settings/*. Settings migrations update values that admins can edit, such as ChapterSettings::$patterns, on existing installs.

If SETTINGS_CACHE_ENABLED=true (the default), clear the settings cache afterwards:

lpod stry artisan settings:clear-cache

Re-sync search indexes, if needed

You only need this when a release adds a new searchable model or field:

lpod stry artisan scout:sync --import

See CLI Interaction for all Scout commands.

Check that it worked

systemctl --user status stry
curl -I https://your-domain/
journalctl --user -u 'stry*' -f

Rolling back

Not every migration can be undone. Settings migrations, for example, have no down() method at all (see Application Configuration). If an upgrade goes wrong:

  1. Restore the database backup you made before upgrading.
  2. Go back to the previous image: podman pull ghcr.io/francoism90/stry:<previous-tag>, then lpod install production/app.quadlets --replace.

Don't rely on migrate:rollback to undo a release. Your database backup is the real way back.

See also

PreviousDevelopment