Releases and update windows

Nothing updates itself on a deployment holding real data. Every update is a decision someone makes. On managed hosting, that someone is us, on a schedule designed so your deployment is never the first one a release meets.

The path a release takes

dev  ->  staging  ->  ring 0  ->  ring 1  ->  ring 2

Staging is a permanent customer-shaped stack restored from a scrubbed, production-shaped backup, so migrations meet realistic data before customers do. Not a clean test database with twelve rows in it.

Ring 0 is the public demo plus our own instance, the one our own team uses to run its work. Every release soaks here for a few days.

Ring 1 is consenting early customers, on the beta channel.

Ring 2 is everyone else, on stable.

Rings 1 and 2 are a channel field on your deployment record. Moving between them is a conversation, not a migration.

What happens on the night

We run the same update script that self-hosting customers run, described in full in updating. It:

1. refuses to start from an unhealthy stack,
2. takes and integrity-checks a database dump,
3. pulls the image by digest and verifies its signature,
4. applies migrations,
5. swaps the image,
6. waits for readiness and for the instance to report the version it asked for,
7. rolls the image back automatically on any failure after the migration.

The database is not rolled back automatically. Migrations are forward-only, and an automatic restore would discard everything written between the backup and the failure. If a migration is implicated we stop, restore deliberately, and tell you.

What you are told, and when

Release type	Notice
Ordinary release	Nothing. It happens and the version changes
Migration-bearing	Told in advance. These are marked in the changelog and treated with more care
Security fix	Told, and moved sooner
Anything that changes behaviour you rely on	Told, with what changed

The changelog is public and kept by hand. Releases that change the schema carry a migration marker.

Asking for a different schedule

Two things you can ask for:

A later ring. If your term dates make a particular fortnight impossible, we can hold you back. Say so with more than a day’s notice.

The beta channel. You get releases one ring earlier and help catch problems before they reach everyone. Worth it if you have a test-minded ICT team and want influence over what lands.

Checking your version

curl -s https://helpdesk.yourschool.org/api/health/version

{ "version": "0.2.0", "channel": "stable", "commit": "9f2c1ab44e01", "builtAt": "2026-08-01T09:14:22Z" }

The same information is in the product under Admin, Licence, and it is what support will ask for first.

What a release can and cannot change

Can: add features, add modules, change the database schema, change default wording of email templates you have not customised, fix bugs.

Cannot, without telling you: turn a module on that you turned off, change your workflow, change roles or permissions you have configured, or alter an email template you have customised.

A new module arriving is off by default. A new email template arrives with its shipped wording, and a customised template stays customised.

During a release

Expect a short restart. The stack comes back on the new image, which takes under a minute in the ordinary case. Anyone with the console open sees it reconnect; in-progress work is not lost, because nothing is held in the browser that has not been saved.

Migration-bearing releases can take longer, proportional to the size of the change and your data. That is why they get notice.

Self-hosted customers

You decide. RELEASE_CHANNEL in .env determines which release we recommend to you, and nothing updates without you running the command. The on-premises bundle is the exception and updates itself overnight by default, which you can turn off. See updating.