Upgrades and backups
Move AIOE to a new release, and back up what you cannot rebuild.
An AIOE release is a pair of image tags, aioe-api and aioe-console, with aioe-mesh-services alongside if you run the overlay. Upgrading means running the new tags; the API brings the database schema up to date by itself when it starts.
How schema changes apply
When the API container starts with STORE=postgres, it applies every pending database migration before it serves its first request. You do not run migrations by hand, and there is no separate migration job. With several replicas, the first to start applies them.
This is why a backup before an upgrade matters: a migration changes the schema in place.
Upgrade
Read the release notes
Check the release notes for anything a release asks you to do, such as a new required setting.
Back up the database
Take a backup, or confirm your managed database's latest automatic backup, before you change anything. See Back up below.
Run the new images
Set the new tag in values.yaml and upgrade:
image:
tag: <new release tag>helm upgrade aioe ./aioe -n aioe -f values.yaml
kubectl -n aioe rollout status deployment/aioe-apiKubernetes replaces the pods one by one; new pods report ready once the migrations are applied.
Check it
https://<api-host>/healthz reports the new version. Sign in to the console and open Workbenches: enrolled workbenches reconnect by themselves.
Back up
| What | Why | How |
|---|---|---|
| PostgreSQL | Everything AIOE knows: your organisation, enrolled devices, policies, catalogue, projects, memory, secrets (sealed), the audit trail. | Your database's own backups. The Azure template keeps 14 days of automatic backups (not geo-redundant). Elsewhere, schedule pg_dump or your provider's snapshots. |
AIOE_SECRETS_KEY | Every secret, linked account and workbench backup in the database is sealed with it. A database restored without the same key cannot open them. | Keep it in your secret store, apart from the database backups. |
AIOE_SIGNING_KEY | The platform's signing identity. A new key works, but anything holding the old public key must fetch the new one. | Keep it in your secret store. |
| The audit trail's newest link | Proves later that nothing was removed from the end of the trail. | Note it from the console's Audit view, somewhere the database's owners cannot change. See Audit. |
| Your configuration | The values you deployed with. | Keep values.yaml, parameters.json or .env in version control, without secrets. |
You do not need to back up Redis: it holds only short-lived coordination data. The console holds nothing: it is a static web app.
pg_dump --format=custom --file=aioe-$(date +%F).dump "$DATABASE_URL"Restore
- Stop the API (scale it to zero) so nothing writes during the restore.
- Restore the database with your provider's tools, or
pg_restore --clean --dbname="$DATABASE_URL" aioe-<date>.dump. - Start the API with the same
AIOE_SECRETS_KEYand the same image tag as when the backup was taken, or a newer one: it applies any migrations the backup is missing. - In the console, open Audit and choose Check the chain: the trail should hold, and its newest link should be at or after the one you noted.
Workbenches enrolled after the backup was taken are unknown to the restored database: their people enrol them again.