What makes up your deployment
Two things, and two only: your deployment directory (your context as markdown files, the configuration, the governance) and the database volume (the sealed audit trail, the approval queue, the accesses, the cost history). The search index is not part of it: it is derived, and rebuilds entirely with kastel reindex. A backup therefore covers everything that does not rebuild.
Back up and restore
The archive holds your complete context, its attributed history, and the operational state (sealed audit trail, approvals, accesses). Every file in it is fingerprinted, and --verify re-reads the whole archive after writing it: fingerprints, history, continuity of the sealed trail. Read the end of the command rather than its exit code alone: when one of those parts could not be taken, the backup is declared partial and says so plainly. A partial backup still restores, but without what is missing.
Restore targets a freshly initialised, empty deployment; it refuses to overwrite a living one, and a corrupted archive is refused without writing anything. Three honest notes: connected keys do not travel in the backup (reconnect them after restoring); a backup resurrects what was erased since - rotating your backups is part of your GDPR compliance; and restoring the same archive into two living instances creates two diverging histories, not a replica.
Export, leave
Export produces a portable archive of your whole context, with a manifest: version, per-file fingerprint, counters. It is the unconditional exit: nothing to request, no proprietary format to decode - your context is already readable markdown files, natively written in the open OKF format. The anti-lock-in proof is not a reversibility clause in a contract: it is that the command exists, on your side, all the time.
Upgrade
Upgrading is never automatic: your deployment is pinned to a precise engine version, and it stays there until you type this command. It does the whole move at once: pulls the current public release, updates the pin, restarts, applies the database and structure migrations, and reindexes. If the new engine does not start healthy, the previous pin is restored: you are never left between two versions. Re-running it when everything is current does nothing.
Verify what you are running
Every published engine image is signed at publication. Verifying it requires no account and no contact with us - the signature checks against the public transparency log:
The two flags are the whole verification: copy them together or not at all. Success proves the image comes from our publication chain, down to the identity; it does not prove the absence of vulnerabilities. The image’s software inventory is attested the same way, and verification also works offline, on a local copy of the image, for a network cut off from the world.