Luxit/jarvis-selfhost
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sync the self-hosting stack

Browse Source
This commit is contained in:
antoine
2026-09-27 23:05:31 +02:00
parent a5aed16d1a
commit ef1b961d2d
1 changed files with 79 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+79
View File
@@ -9,6 +9,85 @@ 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-09-27 — The install's last step no longer strands a first deployment `api 0.116.1` `web 0.141.2`
**The symptom.** On a first installation the wizard could stop on its last step, the vault key
backup: the key was not shown, and the step still asked for its last eight characters. It happened
on the published Kubernetes stack. It had two independent causes.
**A deployment finished the install for you.** The data repair that runs with every schema sync
marked an instance installed as soon as it had a platform administrator. That was meant for
instances installed before the wizard existed, but the wizard's own second step creates that
administrator. On Kubernetes the sync is the `jarvis-migrate` hook, which runs on every Argo CD sync,
image updates included; on compose it runs at each api start. So a deploy between the second step
and the last one marked a half-installed instance installed, and an installed instance no longer
shows its vault key.
**The last step hid the key on Kubernetes.** It left out the "Show my vault key" button whenever the
key came from the environment, and said you already had it in your `.env`. On Kubernetes the key
always comes from the environment, from the `jarvis-generated` Secret the minting Job writes, and
nobody has seen it. The only command offered was a `docker compose` one. This cause alone was enough
to strand an operator, even when no deploy ran during the install.
What changed:
- The repair now marks only an instance whose administrator the install did not create, meaning
one with no `install.claim` entry in its audit trail, and only once that administrator is more
than fifteen minutes old. A sync in the middle of an install leaves it alone. Instances from before
the wizard are still recognised, and an instance already marked installed stays marked. An install
that finished and later lost its mark (an `install.complete` entry, or an unattended install) gets
it back, as it did before.
- The wizard writes the administrator and its `install.claim` entry together, so a sync can no
longer land between the two. If that entry cannot be written, the claim fails and nothing is
created; submit it again.
- The last step always offers the one-time reveal, which is audited, wherever the key comes from.
- The command for reading the key yourself matches the deployment, and prints the key on a line of
its own, so your prompt no longer sits against its last characters. On Kubernetes it is `kubectl`
on `jarvis-generated`, with your namespace filled in when the api can read it, plus the same on
`jarvis-secrets` if you set `VAULT_MASTER_KEY` there; it runs as is in PowerShell too. With the
published compose file it is `docker compose exec`. A refused reveal names the same command, the
checks step names the Secret on Kubernetes, and the claim step shows both published commands.
- The `.env` sentence is now only a hint beside the button, shown when the api itself receives
`VAULT_MASTER_KEY` in its environment outside Kubernetes. The published compose file never does
that: its `init` service copies a key you set in `.env` into the `jarvis_secrets` volume, so the
step shows the `docker compose exec` command instead.
- If the instance is already installed when the last step runs, the step says so, gives that
command, and lets you continue into Jarvis. You can type the key's last eight characters there to
check the copy you kept; that is optional.
- Reloading `/install` as the administrator of an instance that was marked installed before its
last step shows that same screen, instead of going straight into Jarvis. It stops once you have
checked your copy there, or if the key had already been shown to you.
- Finishing on an instance that turns out to be already installed still checks the eight
characters; it used to accept any eight. The api reports that the instance was already installed,
and the step continues into Jarvis as usual. On Kubernetes, a wrong answer points at
`jarvis-secrets` in case that is where your key is.
- The key is never revealed on an installed instance, even by an api pod that has not yet heard
that another one finished the install.
**Stuck on that screen now?** You do not have to wait for this release. On the version you run
today, read the key with the command below and type its last eight characters on the last step.
That finishes the install, or is accepted if a deploy already marked the instance installed. Keep
the key somewhere that is neither the cluster nor next to your database dumps.
```sh
kubectl -n jarvis get secret jarvis-generated -o go-template="{{.data.VAULT_MASTER_KEY | base64decode | println}}"
```
`jarvis` is the namespace in the published manifests; use yours if you changed it. Use
`jarvis-secrets` instead of `jarvis-generated` if you set `VAULT_MASTER_KEY` there yourself. On
compose it is `docker compose exec api sh -c "cat /var/lib/jarvis/secrets/vault-master-key; echo"`.
After the upgrade, reload the install page, signed in as the administrator (signed out, you are
brought back to it after signing in):
- If a deploy had already marked your instance installed, the page says so and shows the command
for your deployment. Back the key up, check it there if you like, and continue into Jarvis.
- Otherwise your instance is not installed yet, and the install resumes at its address step. Your
settings are saved; click through to the last step, which now shows the key.
**Self-hosters:** api and web; publish the api first, since the web reads what it now reports about
where the key is. No schema change, no new environment variable, and nothing to run by hand.
## 2026-09-27 — No notice under every picture in the viewer `web 0.141.1`
**A picture opened in the viewer no longer carries a notice saying it is the copy that was sent.**