Sync the self-hosting stack

2026-10-21 12:12:12 +02:00
parent e210b4db11
commit 6a2b67364b
13 changed files with 263 additions and 134 deletions
@@ -9,6 +9,65 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
 Every version published to a channel appears here. Nothing is written from memory afterwards: a build
 cannot be published without its entry.

+## 2026-10-21 — Jarvis runs on .NET `api 1.0.0` `web 1.0.0`
+
+**The api and the console are rewritten on .NET** — the api on ASP.NET Core, the console in Blazor
+WebAssembly, served by nginx as before. The images keep their names and their channels. Your data,
+your users with their passkeys and authenticator codes, your vault and your agents carry over, and
+what your instance reports is the same, field for field. Read this one before you pull.
+
+**Before you upgrade**
+
+- **Be on api 0.151.0 first** — the last TypeScript release — and let it start once. 1.0.0 refuses a
+  database that release has not migrated, changing nothing: its log names the release to install,
+  and it restarts into the same refusal. Pin `JARVIS_IMAGE_API` to 0.151.0, `docker compose up -d`,
+  wait until it serves, then remove the pin.
+- **Take a dump**, as before any upgrade (README, "Upgrading").
+- **If you set `DATABASE_URL` yourself**, check its parameters against the README's list: one the
+  api does not read now stops it, naming it, where it used to be ignored; and `sslmode=verify-ca`
+  and `verify-full` now verify the certificate.
+- **If your reverse proxy adds a Content-Security-Policy**, it must allow `'wasm-unsafe-eval'` and
+  inline scripts, or the console stays blank (README, "Your reverse proxy has three requirements").
+  One that sets none needs nothing.
+
+**The upgrade**
+
+- `docker compose pull && docker compose up -d`, as always. If you pin, move `JARVIS_IMAGE_API` and
+  `JARVIS_IMAGE_WEB` together. Nothing to add to `.env`.
+- **Take the new `docker-compose.yml`**: two lines changed, `init` runs `jarvis init-secrets` and the
+  api's healthcheck `jarvis healthcheck`. Your current file keeps working — the image still answers
+  the three `node` commands the published files give it, and nothing else — until a later release
+  removes them, with `/usr/local/bin/migrate.sh` and `/usr/local/bin/entrypoint.sh`; its entry will
+  say so.
+- One api restart. Its first start records where the schema stands and changes nothing else. Open
+  tabs lose live updates until reloaded; agents reconnect by themselves and need no update.
+- **On Kubernetes**, pin both digests in one change, with the new manifests: `01-secret-job.yaml`
+  runs `jarvis mint-k8s-secret` (and no longer sets `NODE_EXTRA_CA_CERTS`), `03-migrate-job.yaml`
+  runs `jarvis migrate`, and `04-api.yaml` recreates the api for this release — every old pod stops
+  before a new one starts, a gap of about thirty seconds, once — and rolls it again from the next.
+  Overlays of your own that call `/usr/local/bin/migrate.sh` keep working until that release.
+
+**What changes for you**
+
+- **The console's first load is heavier**: about 6.2 MB on a first visit (it was under 1 MB), cached
+  afterwards; an update downloads what changed, about 1.7 MB.
+- **The locked-out recipe**: `printf '%s\n' '<new password>' | docker compose exec -T api jarvis
+  hash-password` (README).
+- **The console's page sends a Content-Security-Policy** that allows its own scripts and its two
+  inline ones, nothing else.
+- **The api's log is one line per entry, in UTC**, its levels `info:`, `warn:`, `fail:` and
+  `crit:` — search for `fail:` and `crit:`, not `error`.
+- **SSH host keys are trusted on first use.** A connection's first successful SSH session records the
+  key that answered; a later one presenting another key is refused before a credential is sent,
+  naming both fingerprints. Saving the connection again trusts a reinstalled server's new key.
+
+**The way back**, until the first release after 1.0.0 that changes the schema (its entry will say
+so): pin both previous images and set `SCHEMA_ACCEPT_DATA_LOSS=true` for one start — the TypeScript
+api drops the table 1.0.0 added, `__EFMigrationsHistory`, and nothing else; read its log — or
+`JARVIS_SKIP_MIGRATIONS=true`. After that release, the dump is the way back.
+
+Update the API and web images together. No agent update is required.
+
 ## 2026-10-21 — The last TypeScript release `api 0.151.0` `web 0.185.0`

 **The last release of the TypeScript api and console, and the one to be on before api 1.0.0** —