Upgrading and uninstalling
Moving to a newer version, rolling one back, and taking the platform off a machine.
Upgrade
STHORA_VERSION=v1.4.0 ./install.sh --upgradeDumps the database to /var/lib/sthora/backups/platform/pre-upgrade-<timestamp>.dump
before touching anything.
Rewrites the compose file, which ships with the images and may itself have changed.
Pulls the pinned images and brings the stack up.
Waits for /health, then applies migrations with prisma migrate deploy — which applies
committed migrations and can never generate one.
Prunes old images. Those are what fill the disk on a box that upgrades monthly.
It refuses if there is no install at /etc/sthora/docker-compose.yml.
Your applications keep running throughout
They are separate compose projects and the upgrade does not touch them.
Rolling an upgrade back
Restore the dump the upgrade took, and re-run with the previous version pinned:
STHORA_VERSION=v1.3.0 ./install.sh --upgradeSee restoring the platform database.
Pin STHORA_VERSION. It defaults to latest, and an unpinned upgrade is a
change nobody scheduled.
Uninstalling
./install.sh --uninstallIt asks you to type remove to continue, then runs compose down.
What it keeps: the data volumes and /var/lib/sthora. What keeps running: every
application you deployed — they are containers started by compose files on the disk and depend
on nothing here.
To remove the data as well:
docker volume rm sthora-postgres-data sthora-redis-data
rm -rf /var/lib/sthora /etc/sthoraThat second command deletes the master key with everything else. Every stored secret becomes unrecoverable at that moment, including any you would need to reconstruct an application's configuration elsewhere.
Re-running the installer
install.sh with no flag is idempotent. Every step checks before it acts, so a second run
repairs rather than duplicates — and it keeps an existing /etc/sthora/.env rather than
regenerating every credential.