Everything needed to run Jarvis on your own Docker host, and nothing else. The images are
published; this is the compose that arranges them, the environment they read, and the
prose explaining which values are load-bearing.
It lives in its own repository rather than in a directory of the product's, because the
audience is different in the one way that matters: a self-hoster has no access to the
source and no reason to want it. Handing them a monorepo path to browse would be handing
them a page of files they cannot clone, next to the four they can.
WHAT IS HERE:
- `docker-compose.yml` — postgres, redis, the api and the web. Only the web publishes a
port; it reverse-proxies /api and the websocket internally, so a TLS terminator in
front has exactly one target and the API is never reachable from outside the network.
- `docker-compose.agent.yml` — the optional overlay that supplies the compiled agent
binaries as a pullable image. Off by default, and the README says why leaving it off is
a supported state rather than a broken one.
- `.env.example` — every comment in it is load-bearing. The VAULT_MASTER_KEY note
especially: it has no recovery, and a database backup does not protect what it wraps.
- `.gitignore` — .env and database dumps, because the first thing anyone does with this
repository is fill one of those with secrets and the second is to forget it is there.
The README states the limitations plainly instead of leaving them to be discovered: SSH
host keys are not verified, access tokens survive revocation for up to 15 minutes,
self-registration is open by default and the first account created becomes super-admin,
both containers run as root, and /api/health answers 200 while the database is down.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
antoine
