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

Sync the self-hosting stack (8342e2e)

Browse Source
This commit is contained in:
antoine
2026-08-21 11:48:47 +02:00
parent 38ec167acd
commit 78a3202305
4 changed files with 59 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+29 -9
View File
@@ -44,17 +44,37 @@ Both are the kind that produce confusing symptoms rather than clean errors.
docker compose pull && docker compose up -d
```
That is the whole upgrade: both services track `latest`. Schema changes apply themselves when the api
starts, and the api and the web are versioned independently — their numbers are not meant to match,
because usually only one side changed.
That is the whole upgrade: every service tracks the **`stable`** channel by default. Schema changes
apply themselves when the api starts, and the api and the web are versioned independently — their
numbers are not meant to match, because usually only one side changed.
**`latest` does not mean the app forgets which build it is.** The tag is a second name on the same image
as the version tag, and the version is stamped into the image when it is built — so the footer in the
app and `/version.json` keep reporting the real number, whichever name you pulled it under. That is
what lets you tell somebody which build you are on when something goes wrong.
### Channels
Once you are in production, consider pinning: set `JARVIS_IMAGE_API` and `JARVIS_IMAGE_WEB` in `.env`
to explicit tags. It makes an upgrade a decision rather than a side effect of pulling.
| Channel | What it means |
| -------- | ---------------------------------------------------------------------------------- |
| `stable` | Promoted after running on the publisher's own instance. **The default, and what you want.** |
| `dev` | Every build, as soon as it is published. Nothing has tried it yet. |
| `latest` | A second name for `stable`, kept so nothing that already used it has to change. |
A channel is a **pointer** and a version number is a **fact**. `0.78.2` means one specific set of
bytes for ever; `stable` means whichever set we currently stand behind, and it moves. A build only
reaches `stable` by being promoted — and promotion copies the manifest of an image that has already
been published and already run. It never rebuilds, so the bytes you receive are the same bytes that
were tested, not a fresh build of the same source.
**Channels do not mean the app forgets which build it is.** The version is stamped into the image
when it is built, so the footer in the app, `/version.json` and the agent manifest keep reporting the
real number whichever name you pulled it under. That is what lets you tell somebody which build you
are on when something goes wrong.
Once you are in production, consider pinning: set `JARVIS_IMAGE_API`, `JARVIS_IMAGE_WEB` and
`JARVIS_IMAGE_AGENT` in `.env` to explicit version tags. It makes an upgrade a decision rather than a
side effect of pulling.
**Pin the agent one first if you pin only one.** The api and the web change what your own server
runs; the agent changes what runs on every machine you administer, and it applies itself without
asking. An enrolled agent also refuses any version that is not strictly newer, so moving that pin
back stops a rollout rather than reversing it on machines that already took the update.
Take a database dump before an upgrade that moves the api's minor version: