- The repository as a whole — a prompt carries only the change under review and the files it reaches
- Everything the change does not touch, and everything excluded by ignore or by an in-file marker
- The platform token and the webhook secret
- The commit history, the other merge requests, the pipelines and their logs
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. With a self-hosted platform the only outbound connection is to the model you chose, and a local model removes even that one. On github.com the bot also talks to api.github.com — the hosting you already use, not a new recipient. Every outbound connection is listed below.
self-hosted · your networkmetadata onlyair-gapped is possible
- The review prompt — always the diff of the reviewed files, your rules from config.yml and the merge request metadata (title, author, branches, description, link) — only to the model you chose, with your key
- What the settings add on top: the changed files in full and the definitions they import (whenever a judge runs, or with llm.full_file_context on), the stack versions read from your manifests (llm.environment_context), and — in reply mode — the messages of the thread with the lines of code around the one being discussed
- With a local model (Ollama, vLLM) nothing goes out at all
how the data flows
One network, one outbound connection by default
The review prompt — the diff, your rules and the merge request metadata, plus whatever the settings add — goes only to the model you chose. A cloud model receives it 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 outbound connection of a review — and only if the model is in the cloud. The endpoint and the key are yours. A local model removes it; on github.com api.github.com remains, because that is where the pull requests live.
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 self-hosted platform and 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 review prompt goes only to the model you chose, using your key. It carries the diff, your rules and the merge request metadata; the settings can add the changed files in full with the definitions they import, your stack versions and, in reply mode, the messages of the thread. The exact list is above. 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, on a self-hosted platform: a local model plus the offline license check give a deployment without a single outbound connection. On github.com it is not possible in principle — the pull requests themselves live outside your network.
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.