Releases, images and updates

A registry you run is updated by you, in a window you choose. What the network gives you is a signed release channel that says what is out and how to get it, and a notification on your own registry when a stable release or a hotfix is newer than what you run. Nothing updates itself.

The channel

One JSON document, https://theprotocol.cloud/downloads/frame-kit/latest.json, signed with an Ed25519 key whose public half ships in every reader (the registry, the operator CLI, the kit's frame-update.py). A reader trusts nothing in it before the signature verifies; an unsigned or altered document reads as "no channel". The document lists the newest release first: its version, its kind (stable, hotfix or security), the kit tarball's sha256 and URL, the digests of the six images, the oldest version it upgrades from, and release notes.

Until the public release the document is not published (the URL answers 404) and the public image namespace is closed; a registry that checks the channel then reads "not published or unreachable" and notifies nobody.

Images

Release images are published to images.theprotocol.cloud/theprotocol/<name>:<version> for the six components (registry, teg-layer, event-store, auditor, directory, cert-writer), pullable without a login once the channel is open, and :stable follows the newest release. They are built from the kit tarball the same document names; the image labels carry the kit version and the tree digest, so an image and a tarball can be matched. build.sh in the kit builds identical images from source when you prefer that.

The kit's frame-up.py --images-prefix images.theprotocol.cloud/theprotocol --version <version> stands a frame up on pulled images; without the prefix it uses what build.sh built.

What your registry does

With RELEASE_CHANNEL_CHECK_ENABLED=true (the kit's frame template and every new operator bundle set it; unset means off) the registry reads the channel every six hours with a plain GET that carries no version and no identifier. When a listed release is newer than what it runs, it notifies its admin audience once per version, in-app and by the pushes the admins enabled, with high priority for a hotfix or a security release, and shows the release on the admin page Releases (/#/admin/release-channel): what runs, what is out, the notes, the rollback note, and a form to schedule the rollout window. The registry reminds the admins when the window is due. It changes nothing on the host.

Opt out with RELEASE_CHANNEL_CHECK_ENABLED=false; point at a channel of your own with RELEASE_CHANNEL_URL and RELEASE_CHANNEL_PUBKEY_B64 (an operator who signs releases for frames of their own).

Applying a release

On a frame stood up from the kit:

./frame-update.py --name <frame> --check                                 what is out, verified, against what runs
./frame-update.py --name <frame> --to-latest --schedule 2026-09-23T02:00:00+02:00
                                                                         a systemd timer applies it then
./frame-update.py --name <frame> --to-version 1.0.0-beta.12 --apply      now

The images are pulled by the digests the signed document names, never by a tag alone, and recreated in order (the ledger first, the registry last, which migrates at boot). The ledger's supply delta is read before and after and every update is recorded in the frame's frame-update.json; --rollback puts the previous images back.

On a cloud operator (the tp-operator CLI):

tp-operator update                                        check only (the default)
tp-operator update --schedule 2026-09-23T02:00:00+02:00   a systemd timer applies the newest release then
tp-operator --yes update --apply --to-version <version>   now: pre-snapshot, pull, up, healthcheck, auto-rollback

Rolling back

One release at a time. A release whose notes say it crossed a database migration needs the migration downgrade before the older image starts; the release notes and the admin page say so for that release. frame-update.py --rollback and the operator CLI's pre-update snapshot are the two mechanisms; both leave the ledger untouched.

What is disclosed

The check is an HTTPS GET of a public file from your registry's outbound address. No account, no version and no identifier travel with it. The image pulls are anonymous.