Self-hosted AI pentesting: what runs where and what leaves your network
Updated · By Rokkhe team
A self-hosted Rokkhe deployment runs as Docker Compose services on infrastructure you operate, and Caddy publishes the only port. Each scan runs in its own sandbox container on a per-run network with no route to the database. Engine telemetry stays off unless you enable it. What leaves your network is what you configure: prompts to your model provider, scan traffic, image pulls and the integrations you connect.
What runs where?
| Service | Role | Networks |
|---|---|---|
| caddy | TLS and the only published service. | edge |
| web, api, auth | The console, the application API, sessions and OAuth. | edge; api and auth also data |
| worker | Runs engagements. The only container with the Docker socket. | data, and each scan's own network |
| timescaledb, redis, migrate | System of record, queues and short-lived state, one-shot migrations. | data |
| egress-gateway | Optional, under the egress profile. The one exit for contained sandboxes. | sandbox, restricted |
The data network has no route from the edge, and the worker is kept off the edge network because it holds the Docker socket. /docs/self-hosting covers configuration and upgrades.
How is a scan isolated?
- Each scan's sandbox gets its own bridge network. It never joins the data network, so a compromised target cannot reach your findings or accounts.
- The worker joins each scan's network at the lowest gateway priority and runs with IP forwarding off, so one sandbox cannot route through it into another.
- The worker runs as a non-root user with a read-only root filesystem, all capabilities dropped and no-new-privileges set.
- Under a proxy_only execution profile the sandbox joins an internal network with no route out, and the egress gateway's host and port allowlist is the only exit.
What leaves the network?
| Connection | When | Controlled by |
|---|---|---|
| Model provider | During every engagement. Prompts carry the code and responses being analysed. | ROKKHE_LLM and its key; LLM_API_BASE points at an endpoint you run. |
| Scan traffic | During a scan. By default a sandbox can reach the internet as well as the target. | The scope you name; proxy_only confines it to the egress allowlist. |
| Image registry | On pull and upgrade. | IMAGE_OWNER, IMAGE_TAG and ROKKHE_IMAGE, or a mirror you populate. |
| Integrations | Only for the providers you connect. | The Integrations page. |
| Threat-intel enrichment | When someone enriches an indicator: CISA KEV, and VirusTotal with a key. | Per-provider daily budgets. |
| Agent web search | Only when a Perplexity or Tavily key is set. | PERPLEXITY_API_KEY, TAVILY_API_KEY. |
| Transactional email | Sign-in and invitation mail through Resend. Production auth requires it. | RESEND_API_KEY, ROKKHE_AUTH_EMAIL_FROM. |
| Engine telemetry | Never by default. | Off unless ROKKHE_TELEMETRY is set; DO_NOT_TRACK forces it off. |
Can the model run inside my network?
The engine sends prompts to whichever endpoint you configure. Set LLM_API_BASE to a gateway or inference server you operate and prompts go there instead of to a public provider. Whether a given model is capable enough is your call; the engine warns when a model is not on its recommended list, because weaker models may miss vulnerabilities.
Where are secrets kept?
Workspace credentials are encrypted with the keyring you supply in ROKKHE_CREDENTIAL_KEYRING, and credential operations fail closed without it. Jobs carry references rather than secrets: the API writes each job's resolved secrets to a one-time file that the worker reads.
What do I back up?
The pgdata volume and the ../data directory, together. Run files under ../data are the source of truth and the database is a projection of them. /docs/security describes the full security model.