mcpgate vs Obot
Both are self-hosted MCP gateways aimed at teams that want AI agents connected to their daily tools — without sending data through a vendor cloud. They overlap in surface; the trade-offs decide which one fits which team. Sources are verified against both projects’ current public docs.
Last reviewed: . We maintain mcpgate. If something on this page is off, tell us and we’ll fix it.
The 30-second verdict
Pick Obot if…
- You need real OSI-approved open source (MIT).
- You’re Kubernetes-native and want a Helm chart day one.
- You want a broader platform — gateway plus MCP server hosting plus a chat client — in one product.
- You want a tool that has already been pressure-tested by hundreds of users (777 GitHub stars).
Pick mcpgate if…
- PII handling is a hard requirement and you want it shipped, not as an engineering project. mcpgate pseudonymizes sensitive fields outbound and rehydrates them when the agent calls back. Obot doesn’t ship this layer; you could build it on top, but with mcpgate it’s already there.
- You want individual users to define their own policy hooks (not just operator-level RBAC).
- You prefer a focused gateway over a broader platform.
- You don’t mind a source-available license (BSL 1.1, free for ≤5 users).
Where each one sits
Could you build mcpgate-equivalent on Obot?
Yes. Obot is open and composable — that’s the point of MIT-licensed platform infrastructure. With engineering investment you can:
- Build a PII pseudonymization layer with on-prem rehydration into Obot’s request pipeline (the hard part is the rehydration semantics across write-flows, but it’s solvable).
- Wire user-level YAML hook configuration into the gateway plane — Obot’s extension points are documented.
- Write 22 deep service integrations with the per-service quirks (Markdown→ADF for Jira, Confluence storage-format, Slack channel resolution) yourself.
- Layer your own audit, your own admin UI, your own setup wizard.
If your team has the engineering capacity and wants to own every component end-to-end, that’s a legitimate path. Some mature teams prefer it because the stack stays in their codebase, fully visible and customisable, under an OSI-approved license they trust forever.
The trade-off is who does the engineering and who carries the maintenance cost:
- Obot + DIY: you own the entire stack, no third-party dependency on us, full OSS, but you pay the engineering hours (initial build plus ongoing keep-up as MCP spec evolves) and you wear the support pager.
- mcpgate: we’ve built the opinionated layer; you pay BSL 1.1 license terms (free ≤5 users, source-available) and trade some control for time-to-value. You can still read every line of code.
The comparison below is then about out-of-the-box parity, not architectural ceiling. Where the table says “Obot doesn’t do this”, read “Obot doesn’t ship this — you’d add it.”
Side by side
| mcpgate | Obot | |
|---|---|---|
| License | BSL 1.1 (source-available; each release converts to Apache 2.0 after 3 years) | MIT (OSI-approved open source) |
| Free tier | Up to 5 users, all features | Unlimited (open-source edition); Enterprise edition has separate paid features |
| Maturity | Public since March 2026.. Early stage — community signals (stars, third-party citations) are still catching up. The product is feature-complete for the design target; market validation is the in-progress part. | Established. ~777 stars / ~164 forks (verified 2026-05-17). Visible community contributions and a longer track record in the open. |
| Primary deployment | Docker Compose, one command, zero config | Docker run + Kubernetes Helm chart |
| Kubernetes-native | Possible with custom manifests; no official chart | Yes (Helm chart in repo) |
| PII pseudonymization with rehydration | Built in. Sensitive fields are pseudonymized outbound; mapping stays on-prem, encrypted, 24h TTL; rehydrated when the agent calls back. | Not documented as a feature. |
| Policy hooks | Two layers: company-wide hooks set by operator, plus per-user hooks each user defines from their AI client. YAML, hot-reloaded. | Gateway-level access policies (RBAC); not exposed as user-configurable hooks. |
| SSO providers | Any OIDC IdP (Google, Microsoft, Okta, Keycloak, …) via OIDC_ISSUER_URL; broker-based Google + Microsoft setup also available. | Google + GitHub (base edition); Okta + Microsoft Entra (Enterprise edition). |
| Pre-configured service integrations | 23 built-in (Jira, GitLab, GitHub, Notion, Confluence, Slack, M365, GWS, Grafana, Sentry, Amplitude, Figma, Miro, …). OpenAPI import for any REST API; any MCP server via URL. | Curated set of common MCP servers (Outlook, Slack, Notion, GitHub mentioned in marketing copy); the registry approach favors composability over a pre-built catalog. |
| Scope | Gateway only. | Gateway + MCP server hosting + MCP registry + multi-model chat client (“Obot Chat”). |
| RBAC | Operator vs. user; not fine-grained per tool. | Fine-grained, per skill / per MCP server. |
| Audit log | Yes (admin-gated viewer; tamper-evident hashing). | Yes. |
| Data residency | 100% on-prem. Nothing flows through mcpgate.de or any third party. | 100% on-prem for self-host; managed cloud trial also available. |
The case for Obot
Maturity. Obot has been in the open long enough to accumulate a real contributor base and a visible track record (~777 stars verified 2026-05-17). mcpgate is in early stage — public since March 2026. The external validation surface (stars, third-party citations, “people I can talk to who run this”) is still catching up. If “has at least N production users on record” is on your checklist today, Obot has the head start. We don’t paper over that — it’s a normal early-stage gap, not a product gap.
License clarity. Obot ships under the MIT license, which is OSI-approved and widely understood. If your procurement team has a hard rule against source-available licenses, that’s a fair veto on mcpgate’s BSL 1.1.
Kubernetes day one. Obot’s repo includes a Helm chart and the deployment story is built around K8s. mcpgate works on Kubernetes — it’s containerized — but you build the manifests yourself.
Wider platform. Obot bundles MCP server hosting, a registry, and a chat client around the gateway. If you want a one-shop deployment that covers more than just the gateway layer, Obot reduces the integration surface.
The case for mcpgate
PII pseudonymization. This is the sharpest functional difference. mcpgate replaces sensitive fields (emails, names, phone numbers, customer IDs) with stable pseudonyms before the request reaches the LLM. The mapping stays on-prem, encrypted at rest, with a 24-hour TTL. When the agent calls back into the source system, the real values are rehydrated. The practical consequence: your LLM provider literally never sees the real names. Obot focuses on access control at the gateway layer; pseudonymization is not in its current feature set. If your security review explicitly asks “how do you prevent customer names from leaking to an external LLM?” you don’t have a good answer with Obot today.
User-defined policy hooks. Most gateways let the operator set policies. mcpgate also lets each end-user define their own hooks, hot-reloaded from their AI client. Example: an individual user can say “always set assignee=me on Jira tickets I create through Claude” without filing a request with the operator. This is YAML, no code, and a real productivity unlock for teams where individuals have idiosyncratic preferences. Obot’s policy model is one-way (operator down).
Broader pre-built service catalog. mcpgate ships 23 services pre-configured (Jira, GitLab, GitHub, Notion, Confluence, Slack, M365, Google Workspace, Grafana, Sentry, Amplitude, Figma, Miro, Joan, Transifex, Home Assistant, Phase-6 Content, App Store Connect, Google Play, Bigquery, Metabase, Wordpress, Supernova). Obot leans on its registry: you compose from existing MCP servers, but the out-of-box catalog is smaller.
Focused scope, smaller learning curve. Obot is four products in one. That’s strength if you want the bundle; it’s overhead if you only want the gateway. mcpgate is one thing.
Tradeoffs
- License. BSL 1.1 is source-available, not open source. We picked it deliberately to fund maintenance, and each release auto-converts to Apache 2.0 after 3 years. But if your org will only adopt OSI-approved licenses, Obot fits and mcpgate doesn’t.
- Market validation. mcpgate is early stage — public since March 2026. Obot has a longer track record in the open with a contributor base. The product is built; community traction is the in-progress part.
- Per-user / per-role RBAC. Obot’s per-skill RBAC is more granular as a classic role-based access model. mcpgate’s governance shape is different: action-level discovery + risk gating shipped May 2026 (
gateway_search_actions,gateway_activate, risk annotations on every action,default_activeflag for compliance allow-lists, BM25 retrieval index). If your security review specifically requires “Alice cannot calljira_create_issue” classic-RBAC denylists, Obot maps to that shape better. - Helm chart. mcpgate doesn’t publish an official Helm chart. If K8s with declarative templates is non-negotiable, Obot wins on day one of the install.