Governance for the AI requests your applications are already making.
Synapse AI Gateway sits between your applications and any LLM — local or cloud — and enforces governance controls on every request. Single Docker container. Running in under five minutes.
- 195 MB image
- <50 MB idle
- 69 tests · ~88% coverage
- 5 min quick start
$ docker compose up -d ✔ synapse-postgres Healthy ✔ synapse-backend Running :8080 ✔ synapse-frontend Running :5173
The gap in the middle.
Teams in regulated organisations face the same tension: pressure to adopt AI quickly, alongside real obligations around data residency, audit trails, and responsible use. The available tooling falls into three camps.
Too complex.
LiteLLM, Kong, Azure APIM. Good tools, but built for teams that already have DevOps capacity and infrastructure budgets.
Too expensive.
Enterprise AI governance platforms with six-figure contracts.
Too cloud-dependent.
Require sending data to a third party — a non-starter under data residency rules.
Synapse AI Gateway lives between those three. The governance layer a small team can deploy in an afternoon.
Governance bound to the credential.
Every API key the gateway issues is bound at creation to a system prompt, a model allowlist, a team identity, and rate limits. Applications cannot override that binding from the request body.
Use-case approval becomes a technical control instead of a wiki page. A team approved for an HR assistant cannot quietly use the same key for something else — the system prompt and the model allowlist will refuse.
Every request passes through five layers.
- 1
Authentication and use-case scoping
Validates the key, injects the bound system prompt, checks the model allowlist. Invalid key or unapproved model returns 403 immediately.
- 2
Prompt-layer DLP
Built-in regex engine scans every incoming prompt. Three outcomes per category: block, redact, alert. No external service involved.
- 3
Hybrid model routing
Routes to on-premises (Ollama, vLLM) or cloud (OpenAI, Anthropic, Azure, Google). Data classification on the key decides — sensitive data stays on-prem.
- 4
Immutable audit logging
Every request, including rejected ones, writes a row to PostgreSQL. SHA-256 hashes of prompts and responses, never plaintext.
- 5
Output filtering and anomaly detection
Response-side DLP. Webhook alerts on usage spikes, repeated DLP blocks, off-hours bursts.
Five minutes from clone to first request.
git clone https://github.com/synapse-ai-gateway/synapse-ai-gatewaycd synapse-ai-gatewaycp .env.example .envdocker compose up -d
- 1Admin console at
http://localhost:5173. Log in. - 2Create a team. Pick a model, set a system prompt, choose
sensitiveornon_sensitive. - 3The API key is shown once. Copy it.
- 4Point any OpenAI SDK at
http://localhost:8080/v1with the team key as the bearer token. You are done.
When you should use something else.
Use Synapse AI Gateway when…
- You are 5–100 people exploring AI for the first time.
- You have data residency or sovereignty obligations.
- You need an audit trail and DLP today, not in eighteen months.
- You want a single container, no Redis, no message broker.
Use LiteLLM or Kong when…
- You are routing millions of requests per day.
- You already have a platform team and a budget for AI infrastructure.
- You need 100+ provider adapters out of the box.
- You are happy operating a more complex deployment.
Both tools are right. They are right for different teams at different stages.
What's in the box.
Single container
195 MB backend image, 49 MB admin console. Under 50 MB idle memory.
CI you can trust
GitHub Actions runs Bandit static security and Trivy CVE scanning on every push. 69 tests, ~88% line coverage.
Audit you can defend
Append-only PostgreSQL schema. Prompt and response hashes only. Designed for regulatory examination.
OpenAI-compatible
Drop-in replacement at the API layer. Any OpenAI SDK works. Switching backends never touches your application code.