Sync the self-hosting stack

README.md

@@ -162,6 +162,26 @@ before repeating anything that writes. This is why the api asks for a stop grace
 your instance, signs each session with a key whose private half never leaves it, and reports its
 inventory on every heartbeat.
 
+## Two ways to run it
+
+**Docker Compose — one of everything.** One api container, one web container, one Postgres, one
+Redis, on one host. Two commands and about a minute. This is what most instances run and what the
+rest of this README describes; if you are not sure which you want, it is this one. A reboot of that
+host is downtime, and for the overwhelming majority of deployments that is a fine trade.
+
+**Kubernetes — several of everything that can be several.** Several api pods and several web pods
+behind one address, a Postgres with a primary and replicas, a Redis that fails over. A node can
+reboot and the instance keeps serving. It costs you a cluster to operate and a database to run
+properly, and it asks you to make decisions Compose makes for you.
+
+Everything below is the Compose path. For the other one, the manifests and their own guide are in
+[`kubernetes/`](kubernetes/README.md) — start there rather than here, then come back for the
+install screen, the reverse proxy requirements and the backup section, which are the same either
+way.
+
+Moving between them later is a database dump and the vault key; nothing about your data is specific
+to how the containers are scheduled.
+
 ## What you need
 
 - Docker with Compose v2, on **x86-64 Linux**. The api and web images are published for
@@ -276,6 +296,11 @@ header a caller can forge. Change it later under **Settings → Platform**.
 docker compose pull && docker compose up -d
 ```
 
+> **On Kubernetes** the shape is different, because the schema is a Job rather than something the
+> api does on its way up: the migration runs to completion first, then the Deployments roll. See
+> [`kubernetes/README.md`](kubernetes/README.md#order). Everything below about channels applies
+> unchanged, except that you pin images by digest rather than tracking a channel tag.
+
 That is the whole upgrade: the api, the web, and — with the agent overlay on — the agent release all
 track the **`stable`** channel by default. Postgres and Redis are not on a Jarvis channel; they
 follow their own upstream tags, `postgres:16-alpine` and `redis:7-alpine`. Schema changes apply
@@ -557,6 +582,11 @@ socket fan-out, all of which rebuild themselves; `agent_releases` is refilled by
 They are separate volumes precisely so that they can be, and must be, backed up separately. A dump
 that travelled with the key that opens it is a dump that opens itself.
 
+> **On Kubernetes** the same two things matter and only their location changes: your Postgres
+> operator owns the dump, and the vault key is in the `jarvis-generated` Secret rather than a volume.
+> See [`kubernetes/README.md`](kubernetes/README.md#backups). The restore procedure below is
+> otherwise identical — it is a database and a key, wherever they are kept.
+
 ```sh
 docker compose exec -T postgres pg_dump -U jarvis jarvis | gzip > jarvis.sql.gz
 ```