Top 10 Open-Source MCP Gateways for Self-Hosting in 2026

Compare 10 open source MCP gateway projects for self-hosting in 2026 on license, language, release cadence, dependencies, high availability, and per-user auth.

TL;DR

  • An open source MCP gateway is a self-hostable proxy that puts many Model Context Protocol servers behind one governed endpoint, under a license that permits inspection and private deployment.
  • Bifrost ranks first for self-hosting: it ships as a single Go binary or container, governs MCP tools and model traffic together, and adds 11 microseconds of overhead per request at 5,000 requests per second.
  • Day-two cost is driven by dependencies, not the license: ContextForge needs PostgreSQL and Redis in production, MCP Gateway & Registry needs MongoDB and an identity provider, and Microsoft MCP Gateway needs Kubernetes.
  • Release cadence varies widely: six of the ten projects shipped a release in the two weeks before October 5, 2026, while MetaMCP’s last tagged release dates to December 2025.
  • The MCP 2026-07-28 specification removed protocol sessions, so check whether a gateway routes statelessly before planning multi-replica deployments.

An open source MCP gateway is a self-hosted service that sits between AI agents and MCP servers, holding upstream credentials, filtering which tools each caller can see, and logging every tool call. Teams self-host these gateways for one reason above others: tool calls carry source code, customer records, and internal API tokens, and many organizations will not route that traffic through a third party’s cloud. This guide ranks ten open source MCP gateway projects on what self-hosting actually demands: license terms, maintenance activity, runtime dependencies, high availability, and authentication depth.

What Is an Open Source MCP Gateway?

An open source MCP gateway is an MCP gateway whose source is published under an OSI-approved license, so a team can audit the code, run it inside its own network, and keep operating it if the vendor changes direction. It aggregates MCP servers behind one endpoint, enforces tool-level access policy, brokers upstream authentication, and records an audit trail.

This guide is deliberately narrower than its companions. The broader top MCP gateways comparison also covers managed services such as AWS AgentCore Gateway and Cloudflare MCP server portals. The MCP gateway registry comparison focuses on server catalogs and discovery, and the MCP governance tools comparison focuses on policy models. Here the question is operational: what does it take to run each project yourself for a year?

What Self-Hosting an MCP Gateway Involves

Self-hosting an MCP gateway means owning four things around the proxy: shared state (configuration, credentials, and rate-limit counters), an identity provider integration, a telemetry pipeline, and an upgrade process. How a project handles those four determines its real cost far more than its feature list does.

Shared state is the first divergence. A gateway that stores OAuth tokens per user needs those tokens available to every replica, which usually means an external database. Identity is the second: per-user authentication requires an OIDC provider such as Okta, Entra ID, or Keycloak, and each project integrates with a different set.

The protocol itself changed in 2026. The MCP 2026-07-28 specification made requests stateless and self-contained, and the release announcement notes that remote servers can now sit behind an ordinary round-robin load balancer. For self-hosters, this lowers the cost of running several gateway replicas, but only once clients and servers support the new revision. Mixed fleets still need a gateway that handles the 2025 handshake.

How These Open Source MCP Gateways Were Evaluated

Each project was assessed from its own repository and documentation as read in early October 2026. Release dates were taken from GitHub on October 5, 2026.

CriterionWhat was checkedWhy it matters when self-hosting
LicenseOSI license; what sits behind an enterprise tierDetermines what can be audited and forked
MaintenanceLatest release date and cadenceA stalled project becomes a migration
DependenciesDatabases, caches, orchestrators, IdPEach one is sized, patched, and paged on
High availabilityHow replicas share stateWhether policy holds across instances
Authentication depthPer-user credentials vs shared service accountsDecides whether audit logs name a person
ScopeMCP only, or MCP plus model trafficDecides how many control planes to run

Open Source MCP Gateways Compared: License, Language, and Activity

The table below is the quick filter. Release recency is a reliable signal of whether security fixes will arrive.

GatewayLicenseLanguageLatest release
BifrostApache 2.0 (Enterprise tier separate)Gov2.2.5, Oct 2, 2026
IBM ContextForgeApache 2.0Pythonv1.0.11, Sep 28, 2026
Kuadrant MCP GatewayApache 2.0Gov1.0.1, Sep 25, 2026
Docker MCP GatewayMITGov0.44.1 tag, Sep 16, 2026
PomeriumApache 2.0Gov0.33.4, Oct 2, 2026
ObotMITGov0.26.2, Oct 2, 2026
MCP Gateway & RegistryApache 2.0Python1.32.0, Oct 4, 2026
UnlaMITGo, TypeScript UIv0.10.0, Aug 4, 2026
Microsoft MCP GatewayMITC#No tagged releases; commits to main
MetaMCPMITTypeScriptv2.4.22, Dec 19, 2025

1. Bifrost

Bifrost is an Apache 2.0 open-source AI gateway in Go, built by Maxim AI, that governs MCP tool calls and LLM traffic from one deployment. It starts with npx -y @maximhq/bifrost or a single Docker container, stores configuration in SQLite by default, and switches to PostgreSQL for production. In sustained benchmarks at 5,000 requests per second it adds 11 microseconds of overhead per request.

Running as an open-source MCP gateway, Bifrost connects to upstream servers over STDIO, HTTP, or SSE and exposes the filtered tool set at a single /mcp endpoint. Tool access is deny-by-default per virtual key, and MCP authentication supports none, headers, OAuth 2.0, per-user OAuth, per-user headers, and token exchange (enterprise). Code Mode replaces large tool catalogs with four meta-tools and a Starlark sandbox; across 508 tools on 16 servers it cut input tokens by 92.8%.

What matters for self-hosters:

  • Small footprint. One binary or container, no required cache, and an optional PostgreSQL store. The Kubernetes deployment guide covers cluster installs.
  • One control plane. The same deployment is an LLM gateway with provider failover, so model and tool traffic share virtual keys, budgets, and RBAC instead of two policy systems.
  • Telemetry included. Gateway-level observability exposes Prometheus metrics, OpenTelemetry traces, and per-tool duration and failure rates, and guardrails for secrets and PII run on the same request path.
  • Path beyond the data center. Bifrost Edge, in early access, extends the gateway’s governance and security to employee machines and inventories the MCP servers configured in apps such as Claude Code and Cursor.

Best for: In this assessment, Bifrost is the strongest open source MCP gateway for teams that want enterprise-grade performance and governance without adding a separate tool gateway. It suits regulated environments that require air-gapped, VPC, or on-premises deployment and full control over data and execution.

Deployment note: the open-source build runs as a single high-performance node, and the enterprise tier adds multi-node clustering, token exchange, and advanced access profiles when a deployment grows across teams.

2. IBM ContextForge

IBM ContextForge is an Apache 2.0 registry and proxy in Python that federates MCP servers, A2A agents, and REST or gRPC APIs behind one endpoint. Version 1.0 shipped in May 2026, followed by eleven point releases through September.

ContextForge offers JWT and SSO authentication, RBAC with teams, user-scoped OAuth tokens, 40+ plugins, an admin UI, and OpenTelemetry tracing. It installs from PyPI, Docker, or Helm.

Best for: teams that need to federate many MCP servers and legacy REST or gRPC services into one self-hosted endpoint.

Limitations: SQLite is for development only; production uses PostgreSQL plus Redis for caching and multi-replica operation, so the footprint is larger than single-binary gateways.

3. Kuadrant MCP Gateway

Kuadrant MCP Gateway is an Apache 2.0 Envoy-based gateway in Go from the Kuadrant project, and it is the upstream for the MCP gateway that Red Hat ships as a Technology Preview in Red Hat Connectivity Link on OpenShift. It aggregates multiple MCP servers behind one endpoint and runs in controller mode on Kubernetes or in a standalone mode configured with YAML.

A broker serves the MCP endpoint, a router plugs into Envoy as an external processor, and a controller discovers servers from Gateway API HTTPRoute resources. Tools are prefixed per server to avoid name conflicts, and Kuadrant AuthPolicy resources validate tokens, with tool access mapped to identity-provider groups in the Keycloak example. A Redis-backed session store supports horizontal scaling.

Best for: Kubernetes and OpenShift platform teams that already use Gateway API and Kuadrant policies for authentication and rate limiting.

Limitations: it depends on a Kubernetes cluster with Gateway API and a provider such as Istio, and the Red Hat build is a Technology Preview that Red Hat does not recommend for production.

4. Docker MCP Gateway

Docker MCP Gateway is an MIT-licensed Go project that runs each MCP server in an isolated container. It ships as the docker mcp CLI plugin, powers the MCP Toolkit in Docker Desktop, and can run standalone on Docker Engine.

Servers are grouped into profiles, pulled from OCI-based catalogs, and given secrets from Docker’s secret store. Per-server tool allow-lists and built-in OAuth flows round out the controls.

Best for: developers and CI pipelines that run third-party MCP servers and want container isolation by default.

Limitations: it requires a Docker runtime on every host and is oriented to a single machine, with no organization-wide identity, budgets, or shared policy store.

5. Pomerium

Pomerium is an Apache 2.0 identity-aware proxy in Go that can front internal MCP servers. It authenticates users through the organization’s identity provider over OAuth 2.1, then acquires, caches, and refreshes upstream OAuth tokens and injects them into proxied requests, so clients never see upstream credentials.

Tool-level rules use the mcp_tool criterion in Pomerium Policy Language, and every tool call is logged with method, tool name, and parameters.

Best for: organizations that already use Pomerium for zero-trust access to internal applications.

Limitations: a single replica can keep state in memory, but multiple replicas require PostgreSQL for the databroker. Pomerium is an access proxy, so it does not aggregate servers or address tool-catalog token cost.

6. Obot

Obot is an MIT-licensed Go platform that combines an MCP gateway, an LLM gateway, and registries for MCP servers and skills. It can host MCP servers itself as Docker containers or Kubernetes workloads.

Obot integrates with enterprise identity providers, brokers OAuth credentials, and correlates audit logs across gateways and devices. A Docker setup works for evaluation.

Best for: teams that want to host approved MCP servers and distribute them to employees from one self-hosted platform.

Limitations: production runs on Kubernetes with external PostgreSQL, and hosting workloads makes Obot a larger system to operate than a pure gateway.

7. MCP Gateway & Registry

MCP Gateway & Registry is an Apache 2.0 community project that splits into an nginx data plane and a FastAPI control plane. It registers MCP servers, A2A agents, and skills, and supports semantic search for runtime tool discovery.

Authentication integrates with Keycloak, Entra ID, Okta, Auth0, Cognito, and PingFederate. Per-user egress OAuth keeps third-party tokens off user laptops, and a security scanner gates newly registered servers. Releases arrive frequently; 1.32.0 shipped on October 4, 2026.

Best for: AWS-oriented teams that want a registry-first gateway with strong identity integration.

Limitations: it requires MongoDB or DocumentDB plus an identity provider, and its documented deployment paths (EC2, ECS, EKS) center on AWS.

8. Unla

Unla is an MIT-licensed gateway in Go that turns existing REST, gRPC, and WebSocket services into MCP servers through YAML configuration, and also proxies existing MCP servers. Configuration hot-reloads and can live on disk or in SQLite, PostgreSQL, or MySQL.

A web UI manages configuration, OAuth pre-authentication protects servers, and Redis Pub/Sub can sync configuration across replicas.

Best for: teams that need to expose internal HTTP APIs as MCP tools without writing server code.

Limitations: its governance model (per-user identity, tool-level policy, audit) is thinner than the gateways above, and the latest release dates to August 2026.

9. Microsoft MCP Gateway

Microsoft MCP Gateway is an MIT-licensed C# reverse proxy and control plane for running MCP servers on Kubernetes. It deploys servers as StatefulSets and manages their lifecycle through an API and a React management portal.

The current version requires MCP 2026-07-28 clients and adapters and routes each request statelessly, so router instances scale without session affinity. Resource metadata lives in Redis locally or Cosmos DB in Azure, and cloud deployments use Entra ID app roles.

Best for: platform teams that want to host their own MCP servers on Kubernetes, especially on AKS.

Limitations: there are no tagged releases to pin against, and clients or servers that cannot move to the new specification must stay on an older image.

10. MetaMCP

MetaMCP is an MIT-licensed TypeScript aggregator that groups MCP servers into namespaces, applies middleware, and serves each namespace as its own SSE or streamable HTTP endpoint. It supports API keys, MCP OAuth, and OIDC login, and runs as a Docker Compose stack with PostgreSQL.

Best for: small teams that want to remix a handful of servers into curated endpoints on a single host.

Limitations: the README acknowledges maintenance delays, and the last tagged release is from December 2025, so self-hosters should plan for slower security fixes.

Self-Hosting Footprint: What Each Gateway Needs to Run

The footprint table answers the question that licenses do not: what else has to be deployed, monitored, and patched alongside the gateway.

GatewayRequired beyond the gatewayMulti-replica statePer-user upstream auth
BifrostNothing (PostgreSQL optional)Independent nodes; Enterprise clusteringYes, per-user OAuth and headers
IBM ContextForgePostgreSQL, RedisRedis-backed federationUser-scoped OAuth tokens
Kuadrant MCP GatewayKubernetes, Gateway API provider such as IstioRedis-backed session storeNot published
Docker MCP GatewayDocker runtimeSingle hostOAuth via Docker Desktop
PomeriumIdentity providerPostgreSQL databrokerYes, upstream OAuth brokering
ObotKubernetes, PostgreSQLPostgreSQLYes, credential brokering
MCP Gateway & RegistryMongoDB, identity provider, nginxMongoDBYes, per-user egress OAuth
UnlaOptional databaseRedis Pub/Sub config syncOAuth pre-authentication
Microsoft MCP GatewayKubernetes, Redis or Cosmos DBStateless routingEntra ID roles
MetaMCPPostgreSQLSingle stackOIDC for MetaMCP users

The pattern mirrors what the open source LLM gateway comparison found for model traffic: projects that keep the database off the request path are cheaper to run at three replicas than projects that need a cache for every policy decision.

How to Choose an Open Source MCP Gateway

Choosing an open source MCP gateway starts with scope, then footprint. If model calls and tool calls should share one policy system, a combined gateway avoids reconciling two audit trails during an incident. If only tools need governing, the choice depends on the stack the team already runs.

  • Choose Bifrost when one self-hosted control plane should govern MCP tools and model traffic with per-user authentication and token cost control.
  • Choose ContextForge or MCP Gateway & Registry when federating many servers, agents, and legacy APIs into a registry is the main job.
  • Choose Kuadrant MCP Gateway or Microsoft MCP Gateway when Kubernetes and Gateway API are the platform standard.
  • Choose Pomerium when zero-trust access to internal MCP servers is the requirement and Pomerium is already deployed.
  • Choose Docker MCP Gateway for local isolation of untrusted servers on developer machines.
  • Choose Obot, Unla, or MetaMCP for hosting servers, wrapping REST APIs, or small single-host setups.

Frequently Asked Questions

What is an open source MCP gateway?

An open source MCP gateway is a self-hostable proxy, published under an OSI license, that sits between AI agents and MCP servers. It aggregates servers behind one endpoint, enforces which tools each caller may use, brokers upstream credentials, and logs tool calls, while letting the team audit the code and keep traffic inside its own network.

Is there an open source MCP gateway with per-user OAuth?

Yes. Bifrost supports per-user OAuth and per-user headers in its open-source build, Pomerium brokers upstream OAuth tokens per user, MCP Gateway & Registry offers per-user egress OAuth, and ContextForge supports user-scoped OAuth tokens. Per-user modes matter because shared service credentials make every tool call look identical in audit logs.

Can I self-host an MCP gateway without Kubernetes?

Yes. Bifrost, Pomerium, and Unla run as single binaries or containers, Docker MCP Gateway runs on any Docker host, and ContextForge and MetaMCP run with Docker Compose. Microsoft MCP Gateway and production Obot deployments are built around Kubernetes.

Which open source MCP gateway is fastest?

Bifrost publishes the most specific figure among these projects: 11 microseconds of added overhead per request at 5,000 requests per second in sustained benchmarks. Most other projects publish no comparable latency benchmark, so teams should load-test candidates with their own tool mix.

Do open source MCP gateways support the MCP 2026-07-28 specification?

Support varies and is changing quickly. Microsoft MCP Gateway already requires the 2026-07-28 revision and routes statelessly. For other projects, check release notes before upgrading clients, because a gateway that only speaks the 2025 handshake cannot serve clients that have dropped it, and the reverse is also true.

Should I use an open source MCP gateway or a managed one?

Use an open source MCP gateway when tool traffic carries data that must stay in your network, when air-gapped or on-premises deployment is required, or when you need to audit the code. Managed options such as AWS AgentCore Gateway reduce operations work but tie agent traffic to one cloud provider.

Running Bifrost as a Self-Hosted MCP Gateway

Among the ten projects, Bifrost combines the smallest required footprint with the broadest scope: one binary, deny-by-default tool access, per-user authentication, Code Mode for large catalogs, and model routing in the same process. Running Bifrost as a self-hosted MCP gateway also leaves room to grow, since Bifrost Edge carries the same governance to MCP servers on employee laptops through endpoint MCP governance.

For the model-traffic side of the same decision, see five open source LLM gateways for self-hosted deployments. The gateway setup guide covers running Bifrost as a self-hosted MCP gateway.

All articles