- The source code and the pull request diff
- The contents of the repository files
- The platform token and the webhook secret
- Branch names, authors, history
securityThe code stays inside
The code stays inside
your infrastructure.
ReviewGate is self-hosted inside the network you control. The vendor never receives your code or your diff. The only outbound connection is to the model you chose; with a local model nothing goes out at all. Every outbound connection is listed below.
self-hosted · your networkmetadata onlyair-gapped is possible
- The review prompt (the diff plus your rules; with the code-context options on, also the changed files in full and the stack versions) — only to the model you chose, with your key
- With a local model (Ollama, vLLM) nothing goes out at all
how the data flows
One network, one outbound connection by default
The diff and the rules go only to the model you chose. A cloud model receives the review prompt, billed to your key; with a local model (Ollama, vLLM) nothing leaves at all. The ReviewGate vendor takes no part in this and never sees the code.
storagestored (metadata) never stored
What is stored, and what never is
- The number of findings and their severity
- Review statuses and the severity gate verdict
- The tokens the model spent
- All of it in your own database, cleaned up after 90 days
- Source code and diffs
- File contents
- Comment texts that quote code
you can verify it yourself«Only review metadata is stored» is a property of the architecture: the bot physically never writes code or diffs to the logs or to the database. You do not have to take our word for it — the database is yours, the logs are on your host, and the container's outbound traffic is yours to watch.
outbound connections
The full list — and how to bring it to zero
The model you chose
The only outbound connection — and only if the model is in the cloud. The endpoint and the key are yours. A local model removes even this one.
The image registry (only on upgrade)
A new image is pulled only when your ops team decides to. It is never used while a review runs; for a closed network the image can be delivered as a file.
The license check is offline
It is verified locally with a built-in public key. No calls home — it works in an air-gapped deployment too.
zero outboundA local model plus the offline license check make a fully air-gapped deployment without a single outbound connection. How to set it up is in Models and your own key.
- The webhook is signed with a secret; the token is compared in constant time.
- The platform token and the model key live in your own
.env, inside your network. - The license is verified offline with a built-in public key — no calls home.
- No new sub-processor: the code reaches nobody except the model provider you already chose and already have an agreement with.
- No telemetry and no phone-home — nothing to allow-list towards the vendor.
- Air-gapped end to end: with a local model, a deployment works with the outbound rule set to deny.
security FAQ
Frequently asked questions
Does our code reach you, the vendor?
No. ReviewGate is self-hosted inside your infrastructure and never receives your code or your diff. We see review metadata only if you send it to us yourself for support.
What about the model provider?
The diff goes only to the model you chose, using your key. If you want zero outbound traffic, run a local model through Ollama or vLLM — the bot supports it.
What do you store?
Metadata only: the number of findings, their severity, the statuses, the tokens spent — in your own Postgres, cleaned up automatically after 90 days (these metrics make it easy to see what the bot is worth and what the judge drops). Code and diffs: never. The bot writes neither to the logs nor to the database, and you can check that in the source.
Can it run completely offline?
Yes: a local model plus the offline license check give an air-gapped deployment without a single outbound connection.
What happens if the judge or the database breaks?
The review arrives anyway — the engine is fail-open end to end: a judge failure publishes the findings of the first pass, metrics database errors produce only a warning in the log, unavailable code context falls back to the diff, and a status that could not be published is ignored. No side subsystem can take the review down.
Who has access to the platform token?
The token lives in your own .env inside your infrastructure. We neither see it nor receive it.
How isolated is the bot container?
The image runs as non-root, with a read-only filesystem, all Linux capabilities dropped (cap_drop ALL) and no-new-privileges. There is no ordinary way in, and a compromised dependency can neither persist nor write to disk. A container cannot be fully closed off from the root administrator of the host itself — that is how Docker works, not an omission on our side — but everything you need is observable from outside, so going in is never required.
How do we get logs for diagnostics without opening the container?
Logs are written to the host and read from outside: docker compose logs -f app, or dumped to a file with one command. They carry review metadata only — models, severity, tokens; no code and no diffs. The logs stay with you and never reach us.
Check it yourself
Everything described above is verifiable on your own deployment: bring the bot up inside your network and watch what goes out and what stays in.