Upgrade
Move to a new release: back up, change the version, and restart the servers one at a time.
A Pistis release is a version number, such as 0.2.0, and four images tagged with it (Images). To upgrade, back up, point your install at the new version and restart the Pistis servers one at a time. Sessions keep running on the other server meanwhile.
Back up first
The database holds everything: sessions, people, connections, agents, saved files and each session's checkpoints. Back it up, and keep your keys with it: PISTIS_SECRET_KEY encrypts the secrets people entered, and a backup can't open them without it.
| Install | Back up |
|---|---|
| Compose | docker compose exec -T postgres pg_dump -U postgres postgres > pistis.sql, and a copy of .env |
| Kubernetes | Your Postgres's own backups, and the chart's Secret (or yours, with secrets.existingSecret) |
pistis dev | Stop it and copy its data folder, .pistis by default |
Upgrade a server folder
A folder made by npm create pistis runs the version in its package.json. Update it, and stop and start npx pistis dev:
npm i @pistishq/cli@latest @pistishq/sdk@latestOr set the new version for @pistishq/cli and @pistishq/sdk in package.json and run npm install. All the @pistishq packages share one version, so keep them on the same one. The next start pulls that version's sandbox images.
Upgrade with compose
- Set
PISTIS_VERSIONin.envto the new version, and pull its images:
docker compose pull- Restart one server, and wait until its log says it is ready:
docker compose up -d --no-deps brain1
docker compose logs -f brain1 | grep -m1 "ready url="- Do the same for
brain2, then bring up the rest:
docker compose up -dRunning sandboxes keep the image they started with and reconnect to the new relay by themselves; new sandboxes start from the new image.
Upgrade on Kubernetes
Check out the release's tag of the repository, whose chart names that release's images, and upgrade:
git checkout v0.2.0
helm upgrade pistis deploy/helm/pistis --reuse-valuesKubernetes replaces the Pistis servers one at a time. To pin a version yourself, set image.tag.
What changes in the database
A new version updates the database when it first starts, in one transaction, and records each change in schema_migrations. A Pistis older than the database refuses to start on it, so upgrades go forward only. To go back to an older version, restore the backup you made before the upgrade.
The move to pi 1.4 is one way.
pi is the engine Pistis keeps sessions in. The first start of a version built on pi 1.4 also rebuilds the sessions' task table (pi's storage schema 2). A version on pi 1.3 can't open it afterwards, so the backup is the only way back.
Rotate keys while you're at it
Changing PISTIS_SECRET_KEY needs every server stopped: see Rotate the secret key.