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-25 23:18:16 +02:00
parent 62a9308795
commit 1aa6e9d05f
3 changed files with 69 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
kubernetes/README.md
+13 -1
View File
@@ -280,11 +280,23 @@ outcome. Run it again.
## Backups
Everything in [the main README](../README.md#backups-and-restoring-one) applies, with one
substitution: the vault key is not in a Docker volume, it is in the `jarvis-generated` Secret.
substitution: the vault key is not in a Docker volume, it is in a Secret — `jarvis-secrets` if you
set `VAULT_MASTER_KEY` there yourself, `jarvis-generated` otherwise. The kustomization mints
`jarvis-generated` either way, so on the manual path it holds a key nothing uses: back up the one
the api reads.
```sh
kubectl -n jarvis get secret jarvis-generated -o jsonpath='{.data.VAULT_MASTER_KEY}' | base64 -d
kubectl -n jarvis get secret jarvis-generated -o jsonpath='{.data.VAULT_KEY_CREATED_AT}' | base64 -d
```
Back that up somewhere that is not this cluster, and not alongside your database dump. A database
backup that travelled with its own key is a backup that decrypts itself.
The second line is when the key was created, bound to that key by its fingerprint — on a Secret
minted from api 0.114.1 on. An older one carries a bare date, which the api ignores here, so a
restored copy of it changes nothing and the claim asks for the key. If you ever restore the key by
hand into `jarvis-secrets`, restore that value beside it word for word, or leave it out — never
compute a new one. It is what tells the install screen whether an empty database is a
first install or a lost one, and an old key dated today makes the first administrator free to
whoever reaches the address before your dump is loaded.