Self-hosting a gateway is its own decision, separate from which governance features matter most — you're trading a managed product for full inspection rights, no vendor lock-in, and the operational work of running it yourself. Here's what's genuinely open source in this space today, with the specifics that actually separate them.

What to Actually Look For Before Comparing These

• Where the open core actually stops. Several of these split a genuinely open project from a paid "Enterprise" tier that adds IdP integration, hosted deployment, or risk scoring. Know exactly where that line sits before assuming a feature is included in the free version.
• Deployment complexity, honestly stated. Docker Compose and a Kubernetes multi-cluster federation are not the same lift. "Self-hosted" spans a huge range of actual operational effort.
• What the access-control model actually is. A UI toggle that hides a tool from view is not the same as a policy engine evaluating a request against rules. Several open-source options are closer to the former than their marketing suggests.
• Runtime and language, if performance matters at your scale. A Python-based gateway and a Go-based one carry meaningfully different per-request overhead — worth knowing if you're routing high-volume agent traffic through it.
• Protocol scope. Some of these only aggregate existing MCP servers; others can convert plain REST or gRPC APIs into MCP-compatible tools, or federate MCP alongside A2A agent traffic. That's a real capability difference, not a marketing distinction.
• Rate limiting and quota control. Whether limits can be set per tool, per tenant, or per agent role — not just whether the gateway survives a traffic spike.
• Observability depth. Whether tool-call activity is queryable and exportable to a SIEM, or whether "observability" just means a log file nobody's built a way to search.

The Options

Lunar.dev (MCPX)

Lunar's open source MCP gateway and AI control plane, giving a single governed entry point for every agent-to-tool interaction. The open core handles aggregation, access control, and observability; deeper governance — SSO/RBAC, secret isolation, automated MCP server risk scoring, hosted deployment — sits in a separate Enterprise tier.

What's good:

• Real third-party credibility: recognized by Gartner as a Representative Vendor in the MCP Gateways category, SOC 2 certified at the Enterprise tier, deployed at Fortune 200 companies
• Genuinely fast onboarding — running via Docker in minutes
• A live customer reference: HiBob credits it with giving them "the identity-based governance we needed to approve MCP usage, without turning security into a blocker"

Current gaps:

• The open-source access-control model is closer to a UI/profile toggle than a full policy engine — the deeper governance (SSO/RBAC, secret isolation, risk scoring) is Enterprise-tier
• DLP is not a documented feature of MCPX itself — it lives in Lunar's separate commercial gateway line
• Aggregates existing MCP servers only — no REST/gRPC-to-MCP conversion

Best fit: teams that want an open-source foundation with a credible, well-documented path to enterprise governance if they need it later.

Docker MCP Gateway

Docker's approach treats MCP servers as container workloads — each one isolated with its own CPU and memory limits, cryptographically signed images for supply-chain security, registered dynamically, deployed through familiar Docker Compose or Docker Desktop.

What's good:

• Container isolation is the strongest in this list — genuinely useful if running untrusted or third-party MCP servers safely is the actual concern
• Zero new operational model for teams already fluent in Docker/Kubernetes patterns
• Straightforward secrets management and dynamic server discovery

Current gaps:

• Designed primarily for developer-local and container-native environments, not multi-tenant enterprise governance — cross-team access control and org-wide policy enforcement need additional tooling layered on top
• No LLM traffic routing — teams running both LLM and MCP tool traffic need a separate AI gateway alongside it

Best fit: teams already standardized on Docker/Kubernetes, prioritizing container isolation and comfortable owning the governance layer themselves.

Microsoft MCP Gateway

An open-source, MIT-licensed Kubernetes-native reverse proxy for session-aware routing and lifecycle management of MCP servers you already run. It routes and orchestrates — it doesn't convert REST APIs into MCP tools. Microsoft's separate, commercial path is Azure API Management acting as an auth and security gateway for MCP traffic, leveraging Azure APIM's existing scale.

What's good:

• Enterprise auth ships through Azure Entra ID and role-based access control built for multi-tenant deployments, without a separate paid tier for the open-source piece itself
• The natural default if the rest of the stack already leans on Azure/Kubernetes
• Session-aware routing built specifically for the lifecycle patterns MCP servers actually need

Current gaps:

• Routing and orchestration only — no REST/gRPC-to-MCP conversion, and no LLM-traffic governance without pairing it with Azure APIM separately
• Real enterprise governance (beyond routing) increasingly pushes toward the commercial Azure APIM path rather than staying in the open-source piece alone

Best fit: Azure-native shops extending existing API governance to cover MCP traffic specifically.

IBM ContextForge

The option in this list built specifically for one job the others aren't: a single federated control plane connecting AI agents to MCP tools, A2A agents, and REST/gRPC APIs across multiple clouds and regions — without standing up a separate gateway stack per region. An open-source registry and proxy (published on PyPI as ^{mcp-contextforge-gateway}) that federates all of this behind a single endpoint. Its standout capability is protocol translation — converting existing REST and gRPC services into MCP-compatible tool definitions, plus "virtual server composition," letting multiple MCP servers appear as one logical endpoint to an agent.

What's good:

• The broadest protocol scope in this list — MCP, A2A, and REST/gRPC federation in one place, genuinely answering the "one runtime instead of separate stacks" requirement directly
• Auto-discovery, health monitoring, and capability merging across distributed, multi-cluster deployments — built for exactly the multi-region/multi-cloud case, not retrofitted onto it
• Apache 2.0 licensed, deployable via PyPI, Docker, or Kubernetes with Redis-backed caching

Current gaps:

• Built in Python, which produces meaningfully higher per-request overhead than Go-based alternatives — worth weighing if latency at scale is a real constraint
• Enterprise governance and access-control depth is explicitly less mature and less documented than its federation capabilities
• Described by IBM itself as a community project, not an officially supported IBM product — there's no commercial support line to call if something breaks in production

Best fit: large organizations with sophisticated DevOps teams that need genuine multi-protocol federation and can absorb the operational and support tradeoffs that come with it.

Obot

The most complete open-source bundle on this list — an MIT-licensed gateway, server catalog, hosting, and chat client shipped as one deployment, running on Kubernetes or Docker.

What's good:

• Multi-role RBAC (Admin, Owner, Power User, Auditor, User), scoped per catalog, per server, and per tool, ships in the open core — not gated behind a paid tier
• GitHub and Google IdP integration work without an Enterprise license; Okta and Microsoft Entra are gated to the Enterprise Edition specifically
• GitOps-compatible admin — server configuration and catalog entries manageable as code
• Broadest single-deployment functionality in this list, including an end-user chat client most competitors don't bundle

Current gaps:

• The full enterprise-IdP story (Okta, Entra) requires the paid Enterprise Edition — the open core covers smaller-scale IdP needs only
• Broader scope (catalog + hosting + chat client) means more surface area to operate and secure than a narrower, single-purpose gateway

Best fit: teams wanting the broadest functionality out of a single open-source deployment, with a credible upgrade path if enterprise IdP integration becomes a requirement later.

When Open Source Isn't Actually the Requirement — On-Prem Might Be

Worth naming directly: most teams reaching for "open source" here aren't actually optimizing for inspectable code. They're optimizing for two things open source happens to guarantee — data never leaving infrastructure you control, and no dependency on a vendor's hosted uptime. Self-hosting is one way to get both. It's not the only way, and it comes with a real cost: you own every upgrade, every patch, and every part of running it going forward, with no vendor support to call, and (per the gaps above) inconsistent depth in exactly the governance features that were probably the point of wanting a gateway at all.

Scalekit's Agent Gateway isn't open source, and it's worth being direct about that rather than implying otherwise. What it does offer is a fully on-prem, air-gapped deployment option — your infrastructure, your data never leaving it — but with consistent managed upgrades and enterprise support behind it, instead of your team owning that maintenance alone, and without the governance-depth gap that shows up in nearly every open-source option above once you look past the open core. For a lot of teams, that's a better match for what they were actually trying to get from "open source" in the first place: real ownership of where the data lives, without also taking on being your own release-engineering and security-patching team indefinitely.

If code inspection itself is the actual requirement — not just data control — the open-source options above remain the right category to be looking at. Understanding MCP security risks in the enterprise is worth doing regardless of which deployment model you choose.

How to Choose

FAQ

Is Scalekit's Agent Gateway open source?

No. It offers on-prem and air-gapped deployment, which addresses data-residency and control concerns the way self-hosted open source does, but the code itself isn't open. Teams evaluating MCP authentication build vs. buy decisions should factor in operational overhead alongside licensing terms.

If I want zero vendor dependency, is on-prem-but-managed actually equivalent to open source?

Not fully — you can't fork or inspect the code, and you're still depending on the vendor for updates and support. What it removes is the operational burden of running and patching the software yourself, and your data still never leaves your infrastructure. Whether that trade-off is equivalent depends on whether code inspection or data control was the actual requirement.

Do these open-source options include enterprise IdP integration for free?

Usually not fully — most split a genuinely open core from a paid tier that adds Okta/Entra/Google Workspace federation. Obot's core does include GitHub and Google IdP without payment, but Okta and Entra specifically require its Enterprise Edition — check exactly where each vendor's line sits rather than assuming. For teams evaluating how enterprise MCP identity and SSO actually work, the distinction between open-core IdP support and full enterprise federation matters significantly.

What's the real operational cost of self-hosting one of these?

Beyond the software itself: connector runtime management, credential handling and rotation, observability, and keeping up with updates — all work a managed product would otherwise absorb. IBM ContextForge in particular is explicit that its governance depth still trails its federation capabilities, meaning even after standing it up, some of the governance work may still be manual. Agent tool observability is one area where the gap between open-source tooling and a managed platform tends to show up quickly in production.

Does the runtime language of the gateway actually matter?

At meaningful scale, yes. A Python-based gateway like ContextForge carries higher per-request overhead than a Go-based alternative — not disqualifying, but worth factoring in if you're routing high volumes of agent traffic rather than running a handful of internal tools.

Can I connect agents to MCP tools across multiple cloud environments through one federated control plane, without deploying a separate gateway stack per region?

Of the options here, IBM ContextForge is built for exactly this — multi-cluster federation with auto-discovery across distributed deployments, plus the ability to federate MCP alongside A2A agent traffic and REST/gRPC APIs in the same runtime. None of the other four options in this list are built primarily for that use case. Teams thinking about access control for multi-tenant AI agents at this scale should evaluate governance depth alongside federation capabilities before committing to a deployment model. It's also worth understanding the difference between MCP and APIs when planning your integration architecture.