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>
46 lines
2.2 KiB
YAML
46 lines
2.2 KiB
YAML
# Jarvis — the agent release, as a pullable image.
|
|
#
|
|
# OPTIONAL OVERLAY. The base stack runs perfectly without it; what it adds is the one feature a
|
|
# self-hosted instance cannot otherwise have, because enrolling a machine downloads a compiled
|
|
# binary and there is nowhere for a compose-only deployment to get one. This carries that release
|
|
# as an OCI image, so it arrives through the same `docker compose pull` as the api and the web.
|
|
#
|
|
# Turn it on by naming both files. Either spelling works:
|
|
#
|
|
# docker compose -f docker-compose.yml -f docker-compose.agent.yml up -d
|
|
#
|
|
# or, so that a plain `docker compose ...` keeps working for every later command, put this in .env:
|
|
#
|
|
# COMPOSE_FILE=docker-compose.yml:docker-compose.agent.yml
|
|
#
|
|
# Upgrading is unchanged: `docker compose pull && docker compose up -d`. The publisher re-runs,
|
|
# replaces the release in the volume, and the api picks it up WITHOUT a restart — digests are
|
|
# computed from the bytes on disk on every request, not cached at boot.
|
|
services:
|
|
# Runs once per `up`, copies its payload into the shared volume, exits. Not a server.
|
|
agent-releases:
|
|
image: ${JARVIS_IMAGE_AGENT:-git.luxit.be/luxit/jarvis-agent-dist:latest}
|
|
# Explicit, because the default would be wrong the moment somebody copies this block: a
|
|
# restarting one-shot is an infinite loop, and Compose's own default policy is already "no".
|
|
restart: "no"
|
|
volumes:
|
|
- agent_releases:/out
|
|
|
|
api:
|
|
# NOTE THE COUPLING: until the publisher has exited 0, the api does not start. That is
|
|
# deliberate — a release that failed to arrive should stop the deploy and say so, rather than
|
|
# leave an instance quietly handing 404s to every installer somebody runs this week. The cost
|
|
# is that an unreachable registry now blocks the whole stack, so if that trade is wrong for
|
|
# you, drop these three lines and the api will simply serve no build until the volume fills.
|
|
depends_on:
|
|
agent-releases:
|
|
condition: service_completed_successfully
|
|
volumes:
|
|
# Read-only: the API serves these bytes to every managed machine and never writes here.
|
|
- agent_releases:/srv/agent-releases:ro
|
|
environment:
|
|
AGENT_RELEASE_DIR: /srv/agent-releases
|
|
|
|
volumes:
|
|
agent_releases:
|