Self-hosting

Run the whole platform inside your own boundary.

Rokkhe self-hosts on infrastructure you operate. The shape we run is the shape you can run — a single VM with Compose behind a reverse proxy. Nothing in the stack calls home, and the only outbound traffic is what you configure: your model provider, and whichever integrations you connect.

#What you need

• A Linux host with Docker and the Compose plugin. One VM is enough; the reference deployment runs every service on a single machine.
• A domain pointed at the host if you want Caddy to obtain certificates automatically.
• Credentials for a model provider. Rokkhe never ships a key; the deployment uses yours.
• Outbound access to your image registry, or a mirror you populate yourself.

#The stack

Nine services come up together. Only Caddy publishes a port — everything else is reachable only on the internal networks below.

#Network boundaries

The stack is segmented so that compromising one tier does not reach the next. This is the part worth reading if you are assessing Rokkhe rather than deploying it.

The worker sits on both data and sandbox because it owns the boundary between them: it reads work from the queue and creates the container that executes against a target. A scan’s container never joins the data network, so a compromised target cannot reach your findings.

#Required configuration

Configuration lives in infra/.env. The base Compose file carries development defaults so a local stack comes up unattended; the production overlay removes them. These four have no default in production and the stack refuses to render without them.

#Commonly set

#Bringing it up

Both files, every time. The overlay is what pins ROKKHE_ENV to production, requires the four variables above, and moves Caddy onto 80 and 443.

bashcd infra
cp .env.example .env      # then fill in the four required values

docker compose \
  -f docker-compose.yml \
  -f docker-compose.prod.yml \
  pull

docker compose \
  -f docker-compose.yml \
  -f docker-compose.prod.yml \
  up -d

migrate runs to completion before api and worker start, so the first boot applies the schema before anything serves traffic.

#Health

• /health/live — the process is alive.
• /health/startup — the backend initialized at least once.
• /health/ready — required dependencies are healthy; the edge gates traffic on this.
• /api/health — public compatibility endpoint reporting only status and readiness.

The detailed probes are internal: the edge answers 404 for /health/* because the payload names versions, environment, and dependency state. Compose healthchecks cover timescaledb, redis, api, auth, and web, so a failed dependency holds back the services that need it rather than surfacing as a broken page.

#Upgrading

bashdocker compose -f docker-compose.yml -f docker-compose.prod.yml pull
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

#State and backups

pgdata is the only volume whose loss is unrecoverable. Snapshot it with your normal database tooling rather than copying the directory from under a running Postgres.