Upgrades

Normal upgrades

1. Back up the database (Backups).
2. Run migrate with the new version (pre-deploy job).
3. Roll out API, worker, MCP, then the scheduler; then the web app.

Migrations are additive within v1 (expand/contract for zero downtime). The API's OpenAPI contract is snapshot-tested: a breaking change fails CI unless it is labelled api-breaking, and would ship as /api/v2.

Development databases from before v1.0

Keel was developed milestone by milestone; a few changes need a reset of local development databases (production had no deployments before v1.0):

If your dev database was created…	Do
Before M1 (identity and tenancy)	Recreate it: docker volume rm keel-postgres-data (the Identity and Audit initial migrations were regenerated).
Before M6 and it has audit rows	Audit snapshots are now stored as text; older rows verify as Modified. Recreate the database, or accept that the old rows fail verification.
M2 – M8 otherwise	Nothing: those milestones only added migrations. Existing models get lineage on their next release or scan, or with Rebuild lineage. The first scan after upgrading from M2 proposes everything; runs requested before M3 show their missing stages as "Runs on the next scan".

To reset: stop the AppHost, docker volume rm keel-postgres-data, start it again, and re-run the demo seeder if you want the demo.

Runtime versions

The code targets .NET 10 LTS (C# 14) and also builds on .NET 11 (CI builds both; global.json rolls forward to the newest installed SDK). The web app needs Node 22+ and pnpm 10.