Upgrade

Stacks connected to the control plane

We upgrade your stack from the Schildmark Leitstand, one stack at a time or as part of a rollout to several customers. We agree the time with you. Each server, in turn:

1. takes a local backup, kept on the server as the rollback point;
2. downloads the new release (its checksum is verified) and pulls its images;
3. switches to the new release, keeping theseus.env, your secrets and certificates, so endpoints and user accounts stay valid; the Docker volumes (your data) are kept;
4. starts the services and checks that every one of them is healthy within 10 minutes.

If the check fails, the server rolls back on its own to the previous release and the upgrade is reported as failed; your stack keeps running the release it had.

• On two servers, the core upgrades first, then the application server. A failed core stops the upgrade there.
• The console is briefly unavailable while the services restart. Agents buffer their events and send them when the manager is back.
• Downgrades are refused. To go back to an earlier release, the backup taken before the upgrade is restored instead.
• If you use hosted services, they move to the new release with your stack once the upgrade has finished.
• Upgrades need a valid licence: once a licence has lapsed past its grace period, upgrades are refused until it is renewed (see Licence).

Stacks installed from a bundle

1. Back up first: sudo ./theseus backup.

2. Extract the new bundle over the stack directory:

   tar -xzf theseus-<new version>.tar.gz --strip-components=1 -C /opt/theseus

3. Apply, which pulls the new images and recreates the containers:

   cd /opt/theseus && sudo ./theseus config apply

4. Check with sudo ./theseus status.

The agent on endpoints

New enrolments install the agent version AGENT_VERSION. Existing agents are not upgraded automatically; on Debian and Ubuntu the package is held so routine upgrades do not change it.