Deployment
You decide where it runs.
The same three services can run inside three different boundaries. The only meaningful difference between them is what leaves your network.
- Models
- 3
- Services
- 3
- Setup
- one command
- Air-gapped
- supported
Models
Three boundaries.
Air-gapped does not switch verification off; the judge degrades to the pure-Python lexical fallback.
Managed SaaS
We run it. The fastest start; what travels to the model provider is masked text.
Your own VPC
The same three services run in your cloud. The database and the audit log stay inside your boundary.
Air-gapped
Local-model mode. With no outbound call available the judge degrades to the pure-Python lexical fallback; verification does not disappear.
| model | leaves the network | judge |
|---|---|---|
| Managed SaaS | Model provider | Model judge |
| Your own VPC | Model provider only | Model judge |
| Air-gapped | None | Lexical fallback |
Services
Three containers, via Docker Compose.
It comes up with a single command, and the database and audit log stay inside whichever boundary you deployed into.
backend
FastAPI · :8000
db
PostgreSQL + pgvector · :5435
frontend
React · :5173
How do you prove “no request leaves the machine”?
We run our own load tests on exactly that profile: local-model mode with an unreachable local model address. The whole security chain still executes, the judge falls back to the lexical path, and no call goes out. The latency figure we publish was measured on that profile.
See it with your own data.
In a technical session we run your prompts and your policy through it live.