Sync the self-hosting stack

This commit is contained in:
2026-08-24 13:31:40 +02:00
parent 0674e550f1
commit 9848d2f8be
3 changed files with 32 additions and 21 deletions
+1 -1
View File
@@ -130,7 +130,7 @@ JARVIS_PORT=8080
#
# If they are missing or too short the instance says so loudly in its logs and leaves setup
# OUTSTANDING rather than completing — an instance marked installed with no account is one nobody
# can ever get into, and the claim window is gated on setup being unfinished, so there would be no
# can ever get into, and the claim is gated on setup being unfinished, so there would be no
# way back. Falling through to the ordinary install screen is strictly better than that.
#
#JARVIS_ADMIN_EMAIL=
+15
View File
@@ -9,6 +9,21 @@ 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-08-24 — The claim no longer expires `api 0.89.0` `web 0.112.0`
**The thirty-minute window on the install screen is gone.** There is no countdown, no "the window
has closed", and no more restarting the api container to open another one. The first account created
still owns the instance; it can now be created whenever you get to it.
**Which means the exposure is yours to manage, and we would rather say so than let a timer imply it.**
Until somebody creates that first account, anyone who reaches this instance can. The gap that matters
is between `docker compose up -d` and you opening a browser — so keep it short, and prefer pointing
a public hostname at the instance _after_ you have installed rather than before.
Everything else about the claim is unchanged, including the part that protects you where a timer
never did: an instance whose database has gone missing still costs the last characters of your vault
master key to claim, because from the outside it is indistinguishable from a new one.
## 2026-08-24 — Losing your database no longer puts your instance up for grabs `api 0.88.0` `web 0.111.0`
**If your database is ever lost or replaced, your instance was claimable by whoever loaded the page
+16 -20
View File
@@ -193,27 +193,25 @@ else has a "later" that costs nothing.
Everything it asks is a setting you can change afterwards from an ordinary screen. Nothing it asks
needs a container restart to change.
### The claim window
### Install it when you deploy it
**A brand-new instance can be claimed for 30 minutes after it starts, and the first account created
owns it.** That is why the install screen shows a countdown.
**Until somebody creates the first account, anyone who reaches this instance can.** There is no
deadline on that and no token to find: the first account created owns the instance, and the claim is
open for as long as nobody has taken it.
This replaces something worse. Jarvis used to accept exactly one registration on an instance with no
users and make that account super-admin — so a freshly deployed instance reachable from the internet
belonged to whoever found it first, on a product that holds SSH keys and opens shells on your
clients' servers. The window closes that.
So the gap that matters is between `docker compose up -d` and you opening a browser. Keep it short.
If you are pointing a public hostname at this, point it after you have installed, or install through
the host's own address first — the setting is editable afterwards.
If you miss it, nothing is lost. Restart the api container to open another:
```sh
docker compose restart api
```
If you would rather it were not open at all until you say so, do not publish the address yet: the
install screen is served by the same web container as everything else, and a Jarvis nobody can reach
is a Jarvis nobody can claim.
**Losing your database does not put your instance up for grabs.** An instance whose database has gone
missing looks exactly like a brand-new one from the outside — no accounts, no completed setup — while
sitting on a hostname the world already knows. On that instance the window still opens, so you can
get back in, but creating the first administrator costs the last characters of your vault master key.
You have it; nobody else does. A genuine first installation is never asked for it.
sitting on a hostname the world already knows. On that one the claim still opens, so you can get back
in, but creating the first administrator costs the last characters of your vault master key. You have
it; nobody else does. A genuine first installation is never asked for it.
### The one thing to do afterwards
@@ -439,7 +437,6 @@ wrong on the screen that asks for it.
| Symptom | Cause |
| --- | --- |
| Every page redirects to an install screen | This instance has not been installed yet. That is the wizard, not an error. |
| The install screen says the claim window has closed | Nobody claimed it within 30 minutes of boot. `docker compose restart api` opens another. |
| The assistant answers "this instance has no model configured" | Exactly that. **Settings → Platform → Model**, where the test button will tell you what the provider thinks. |
| api restarts in a loop, logs `Invalid environment configuration` | A value you set yourself is wrong. Only the database, Redis and the vault key are validated at boot now. |
| The sign-in page loads but cannot sign in | The stored public address is not the one the browser used, scheme included. Change it under **Settings → Platform**. |
@@ -507,10 +504,9 @@ SQL
Enrol a new factor as soon as you are back in, and note that this leaves no audit trail of its own —
the trail is your shell history.
**Re-running the install wizard is not a recovery route.** Its claim window only opens on an instance
with no users and no completed setup, so on a working deployment it will refuse — and making it
refuse less by clearing those columns by hand would hand your live instance to whoever reaches it
first.
**Re-running the install wizard is not a recovery route.** The claim is open only on an instance with
no users and no completed setup, so on a working deployment it refuses — and making it refuse less by
clearing those columns by hand would hand your live instance to whoever reaches it first.
### Moving the instance to a new address