Sync the self-hosting stack (85835b7)

This commit is contained in:
2026-08-21 14:22:36 +02:00
parent 78a3202305
commit 8f9ef6b8fc
7 changed files with 431 additions and 92 deletions
+26 -12
View File
@@ -48,8 +48,10 @@ JWT_REFRESH_SECRET=
# Must decode to exactly 32 bytes:
# openssl rand -base64 32
#
# Every credential in the vault — SSH keys, API secrets, Microsoft 365 client secrets, the outbound
# mail password — is encrypted under this key with AES-256-GCM. It is not stored anywhere but here.
# Every credential in the vault — SSH keys, API secrets, Microsoft 365 client secrets — is encrypted
# under this key with AES-256-GCM, and so is everything Jarvis seals OUTSIDE the vault: the Microsoft
# Graph client secret it sends its own mail with, this instance's licence identity key, every
# authenticator-app secret, and every terminal recording. It is not stored anywhere but here.
#
# Change it or lose it and none of that data can be read again, by you or by anyone. A database backup
# does not save you: the backup holds the ciphertext. Back this value up separately from the database,
@@ -91,16 +93,28 @@ OPENAI_API_KEY=
# Pinning makes an upgrade a decision instead of a side effect of pulling. The app reports its real
# version either way — a channel tag is a second name on the same image, not a build that forgot
# its number.
#JARVIS_IMAGE_API=git.luxit.be/luxit/jarvis-api:0.59.1
#JARVIS_IMAGE_WEB=git.luxit.be/luxit/jarvis-web:0.74.2
#
# THERE IS NO EXAMPLE NUMBER HERE ON PURPOSE. Pin the version you are ALREADY RUNNING, which the app
# footer shows as `web … · api …`. Nothing in the publishing path bumps a number written into this
# file, so any number printed here is one that went stale while nobody was looking — and moving the
# api pin BACKWARDS runs an old build against a schema that has already been migrated forward.
#JARVIS_IMAGE_API=git.luxit.be/luxit/jarvis-api:<the api version in your footer>
#JARVIS_IMAGE_WEB=git.luxit.be/luxit/jarvis-web:<the web version in your footer>
# Only read when the agent overlay is enabled, just below. Its version is the AGENT's, and moves
# independently of the two above — a Jarvis release usually does not change the agent at all.
#
# PIN THIS ONE FIRST if you pin only one. The two above change what your own server runs; this one
# 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 this back stops a
# rollout rather than reversing it on machines that already took the update.
#JARVIS_IMAGE_AGENT=git.luxit.be/luxit/jarvis-agent-dist:0.20.0
# changes what runs on every machine you administer. Pinning it decides which build your instance
# publishes; a separate UPDATE POLICY decides when a machine takes it, and its default is "let the
# agent decide" — which in practice means the next time its service starts. Set that policy
# instance-wide under Settings → Platform → General, per organization under Settings → Organization →
# Agent updates. An enrolled agent also refuses any version that is not strictly newer, so moving
# this back stops a rollout rather than reversing it on machines that already took the update.
#
# The app footer does not carry this number. Each enrolled machine reports the build it runs, on the
# Agents page — that is the one to pin.
#JARVIS_IMAGE_AGENT=git.luxit.be/luxit/jarvis-agent-dist:<version>
# ---------------------------------------------------------------------------
# The Jarvis agent (optional)
@@ -127,12 +141,12 @@ OPENAI_API_KEY=
# Licence (required to create anything)
# ---------------------------------------------------------------------------
# The key your provider gave you. REQUIRED to create anything new.
# Your licence key. REQUIRED to create anything new. Ask antoine@luxit.be for one.
#
# Without it, an instance keeps running everything already set up and refuses to create new
# organizations, users and agents — so an existing deployment does not stop working when this
# reaches it, and a fresh install gets as far as its first administrator and then needs a key. An
# unlicensed instance also contacts nobody at all. See the README for exactly what a licensed one
# organizations, users, agents and assets — so an existing deployment does not stop working when
# this reaches it, and a fresh install gets as far as its first administrator and then needs a key.
# An unlicensed instance also contacts nobody at all. See the README for exactly what a licensed one
# reports.
#
# This value SEEDS the database on first boot and does not govern it afterwards: a renewal arrives