Self-Hosted MCP Gateways Compared: Which One Fits Your Stack

Once your AI agents talk to more than two or three MCP servers, wiring every client to every server stops scaling. You need a model context protocol gateway in the middle: one endpoint that handles auth, routing, and logging for every tool call. Managed options are fine, but if you want credentials and audit logs in your own infrastructure, you’re picking among a handful of self-hosted MCP gateways. I went through the 2026 landscape (Obot, October 2026) (Data Science Collective, October 2026) and broke down the five that keep coming up.

TL;DR

• Bifrost is a Go-native MCP and LLM gateway in one binary. Maxim reports microsecond-level overhead, but its RBAC and audit trails stay lighter than governance-focused platforms (Obot, October 2026).
• IBM ContextForge federates MCP servers, A2A agents, and plain REST/gRPC services behind one endpoint, with OpenTelemetry tracing out of the box (Data Science Collective, October 2026).
• Obot gives you centralized OAuth2, tool-level access control, and audit trails; its Docker quickstart is eval-only, so plan for Kubernetes in production (Obot, October 2026).
• Docker’s MCP gateway governs one machine well and nothing beyond it. Single-user by design, container-isolated, great for local dev (Data Science Collective, October 2026).

Contents

• What Does an MCP Gateway Actually Do?
• What Makes Bifrost a Popular Self-Hosted MCP Gateway?
• Why Do Teams Pick IBM ContextForge?
• Can Obot Handle Governance Without a Managed Service?
• Is the Docker MCP Gateway Enough for a Team?
• Where Does Microsoft’s Self-Hosted Option Fit?
• Can You Run an MCP Gateway With docker-compose?
• How Do the Gateways Compare Side by Side?
• Which One Fits Your Stack?
• FAQ

What Does an MCP Gateway Actually Do?

An MCP gateway sits between your AI clients (Claude Code, Cursor, custom agents) and the MCP servers they call. Instead of configuring credentials per client, you point everything at one gateway URL. It handles three jobs:

1. Auth and access control. It holds upstream OAuth tokens so agents never see raw credentials, and decides which user can call which tool.
2. Routing. It aggregates many MCP servers behind one endpoint and can translate REST or gRPC services into MCP tools.
3. Observability. It logs every tool call so you can audit who did what.

The managed vs self-hosted tradeoff comes down to where those credentials and logs live; Speakeasy covers that decision in depth (Speakeasy, 2026), and hosted platforms like Composio or the open-source AI gateway Lunar.dev cover parts of the same ground. This post covers the options you run yourself.

What Makes Bifrost a Popular Self-Hosted MCP Gateway?

Bifrost comes from Maxim AI, is written in Go, and ships under the Apache 2.0 license. Its pitch: the MCP gateway and the LLM gateway live in one binary, so routing, failover, and budget controls for model calls sit next to your tool calls (Data Science Collective, October 2026). Inbound auth supports virtual keys or OAuth 2.1, and upstream per-user OAuth means a user’s identity reaches the tool.

On mcp observability, model spend and tool calls land in the same logs under the same key, and Enterprise adds signed audit logs plus in-VPC or air-gapped deployment for regulated industries. The honest tradeoff: RBAC and audit trails are lighter than purpose-built governance platforms (Obot, October 2026). If latency on long tool-call chains worries you most, Bifrost is the one reviewers keep pointing at; if it’s compliance, keep reading.

Why Do Teams Pick IBM ContextForge?

ContextForge is IBM’s MCP gateway, written mostly in Python, Apache 2.0 licensed, currently shipping 1.0 release candidates. Its differentiator is federation: it puts MCP servers, A2A agents, and plain REST or gRPC services behind one endpoint, translating gRPC via server reflection (Data Science Collective, October 2026). Virtual MCP servers get RBAC and user-scoped OAuth.

Two details matter for small teams: OpenTelemetry tracing ships with Phoenix, Jaeger, and Zipkin backends, so mcp observability is nearly free if you already run a tracing stack. And Redis-backed federation across gateway instances suits multi-cluster setups, though it’s overkill for two people. Reviewers also flag higher baseline latency than Go alternatives and no official commercial support (Obot, October 2026).

Can Obot Handle Governance Without a Managed Service?

Obot is MIT-licensed and genuinely self-hostable on Kubernetes or Docker, running the same codebase as its managed offering (Obot, October 2026). The governance story is the strongest here:

• Centralized OAuth2 at the gateway edge. Agents never see raw credentials. Google and GitHub SSO ship in open source; Okta and Microsoft Entra arrive in Enterprise, with SCIM since v0.27.
• Tool-level access control, not just server-level. Approve one tool inside a server, block the rest.
• Audit trails for every tool call and authentication event, sliceable by user, server, and tool.

Obot hosts npx, uvx, or containerized servers as Docker or Kubernetes workloads, proxies external servers, and bundles selected tools into composite servers for a curated catalog. One catch: the Docker quickstart mounts the Docker socket and is explicitly eval-only, so production means Kubernetes. The community is smaller too, about 1,000 GitHub stars as of October 2026 (Data Science Collective, October 2026).

Is the Docker MCP Gateway Enough for a Team?

Docker’s MCP gateway powers the docker mcp CLI and the MCP Toolkit in Docker Desktop, and it’s MIT-licensed. Its model is very Docker: every MCP server runs in its own container with restricted CPU, memory, and network, and flags like --verify-signatures and --block-network tighten things further (Obot, October 2026). Profiles decide which servers a client sees.

Auth is where it stops. The gateway is single-user by design, with only a local token blocking DNS rebinding over network transports (Data Science Collective, October 2026). No organization-wide RBAC, no central dashboard, no compliance-grade audit logging. For observability you get --log-calls (on by default) and --interceptor for custom hooks, plenty for a solo dev and thin for anything shared. I wire MCP servers into my editors daily, covered in my guide to adding an MCP server to your Flutter/Dart tooling and the React Native tooling version, and for that workflow Docker’s gateway is exactly the right size.

Where Does Microsoft’s Self-Hosted Option Fit?

Microsoft actually ships two relevant pieces. The first is the Azure API Management self-hosted gateway: a containerized APIM you run on-premises or in Kubernetes, inheriting the policy engine, Entra ID auth, and Azure Monitor integration while syncing config from the cloud APIM instance. If your organization already exposes APIs through APIM, exposing MCP servers through the same plane is the natural move.

The second is Microsoft’s dedicated .NET 8 MCP gateway, MIT-licensed on GitHub, which requires clients on the 2026-07-28 MCP spec and uses Entra ID for role-based access; Azure deployment comes via Bicep templates provisioning AKS, Container Registry, and Cosmos DB, so you pay for those resources (Data Science Collective, October 2026). Reviewers note its observability is thinner: no payload inspection or per-user upstream credentials documented.

Can You Run an MCP Gateway With docker-compose?

Yes, and Docker’s gateway is the easiest to demo. Here’s the setup you’d run for a local self-hosted MCP server fleet (verify flags against current docs; the CLI moves fast).

First the CLI smoke test:

docker mcp gateway run --servers=github-official,fetch --log-calls

Then the same thing as an mcp gateway docker compose file:

# docker-compose.yml
services:
  mcp-gateway:
    image: docker/mcp-gateway:latest
    command:
      - --transport=streaming
      - --servers=github-official,fetch
      - --log-calls
      - --block-network=false
    ports:
      - "8811:8811"
    volumes:
      # The gateway launches MCP servers as sibling containers
      - /var/run/docker.sock:/var/run/docker.sock

docker compose up -d
# Point any MCP client at http://localhost:8811/mcp

Note the Docker socket mount: it’s how the gateway spawns each server in its own container, and why the quickstart shouldn’t face the public internet. For Obot or ContextForge, expect Helm charts or Kubernetes manifests instead; that’s the cost of moving up the governance ladder.

How Do the Gateways Compare Side by Side?

One landscape note before the verdict: the MCP spec dated 2026-07-28 deprecated dynamic client registration in favor of Client ID Metadata Documents, and self-hosting alone doesn’t govern requests. The nginx-ui incident (2,600+ Shodan-exposed instances with an unauthenticated invocation endpoint) showed self-hosting controls where data lives, not whether calls are governed (Obot, October 2026). Put whatever you pick behind your own auth.

Which One Fits Your Stack?

1. Solo developer on one machine: Docker’s MCP gateway. Container isolation, profiles, and --log-calls cover local development, with nothing multi-user to configure.
2. Small team already running a tracing stack: IBM ContextForge. OpenTelemetry support, REST/gRPC federation, no licensing surprises; budget for the Python latency profile and self-support.
3. Small team needing governance without a platform team: Obot. Centralized OAuth, tool-level access control, and audit logs in an MIT package, with Kubernetes as the production target.
4. Latency-sensitive workloads, or anyone wanting the LLM gateway unified with MCP: Bifrost. Go-native speed and one binary for model and tool routing, accepting lighter RBAC.
5. Azure-first organization: Microsoft’s APIM self-hosted gateway or the .NET MCP gateway. Entra ID, existing policies, and monitoring in a plane you already operate.

I’ve said it before in my three-month comparison of Claude Code, Copilot Agent, and Cursor: tool choice matters less than matching the tool to your workflow. Pick the gateway that fits the infrastructure you run, not the best landing page.

FAQ

What is a self-hosted MCP gateway?

It’s a server you run in your own infrastructure between AI agents and MCP servers. It centralizes authentication, routes tool calls to the right server, and logs invocations, so clients never hold upstream credentials.

Is a self-hosted MCP gateway more secure than a managed one?

It shifts responsibility, not risk. Self-hosting keeps credentials and audit logs in your infrastructure and helps with data residency, but you own patching, exposure control, and governance. The nginx-ui incident showed unauthenticated gateways get exposed fast.

Can I run an MCP gateway with docker-compose?

Yes. Docker’s MCP gateway runs as a single docker/mcp-gateway container with a compose file, mounting the Docker socket so each MCP server launches in its own container. Obot and ContextForge target Kubernetes for production.

Which MCP gateway is best for a solo developer in 2026?

Docker’s MCP gateway. It’s single-user by design, ships in Docker Desktop’s MCP Toolkit, isolates every server in a container, and logs calls by default. You trade away multi-user auth and dashboards, which a solo developer rarely needs.

Does the Docker MCP Gateway support multi-user auth?

No. It’s single-user by design, with only a local token blocking DNS rebinding on network transports. There’s no organization-wide RBAC or dashboard. If multiple people need per-user permissions, look at Obot or ContextForge.