All posts
Comparison & discovery··6 min read

Managed vs self-hosted MCP gateway: a buyer's framework

The managed-vs-self-hosted debate for MCP gateways is usually framed wrong: your tools and business logic stay yours in both cases. What you're really deciding is who runs the gateway layer — OAuth, token storage, rate limits, audit logs, multi-region routing. Managed wins for most teams because those are commodity capabilities with non-commodity operational cost. Self-hosting only pays back under hard requirements: data residency, strict VPC peering, or an existing gateway investment you can extend.

⌘
Command+K team
Platform engineering

The actual decision

"Managed vs self-hosted MCP gateway" is the wrong framing. The real question is which capabilities you want to own and which you want to rent. The MCP server itself — your tools, your business logic — stays yours either way. What's negotiable is the gateway layer: OAuth, transport, rate limiting, audit, tenant routing.

What a gateway actually does

  • Terminates HTTP / SSE / Streamable HTTP transports and speaks MCP upstream.
  • Hosts OAuth discovery, PKCE, dynamic client registration, token refresh.
  • Stores per-user tokens with rotation and revocation.
  • Enforces per-user, per-tool, per-tenant rate limits and quotas.
  • Writes audit logs that survive your next outage.
  • Routes to the right tenant's tool implementation.

When managed wins

  • You want OAuth, audit, and rate-limiting in week one, not quarter two.
  • Your team is small and you'd rather spend headcount on tool logic.
  • You need multi-region presence without owning the runbook.
  • Your buyers ask for SOC 2 / ISO 27001 and you'd inherit a managed provider's posture.

When self-hosting wins

  • Data residency mandates (regulated industries, government).
  • Strict VPC peering where no third party touches request payloads.
  • You already operate a comparable gateway (Kong, Envoy with custom auth) and bolting MCP on is cheap.

Default recommendation

Start managed, keep your tool code portable (config-as-code, no UI-only schemas), and migrate only if a real requirement appears. Most teams never migrate.

Command+K is the managed option built around MCP from day one — see Build MCP or compare on the pricing page.

FAQ

Why do I need a gateway in front of my MCP server at all?
Auth, rate limiting, audit logging, quota enforcement, and multi-tenant token storage are not the MCP spec's job — they're yours. A gateway centralizes them so your tool code stays focused on business logic.
When does self-hosting make sense?
Strict data-residency requirements, deep VPC peering needs, or a security team that requires every byte to traverse infrastructure you own. Otherwise the operational cost rarely pays back.
What's the hidden cost of self-hosting an MCP gateway?
Token storage with rotation, OAuth discovery + dynamic client registration, per-user rate limits, audit log durability, multi-region failover, and keeping up with the MCP spec as it evolves. Plan for an engineer-quarter to go live and an engineer-month a year to maintain.
Can I start managed and migrate later?
Yes if the managed product exposes its config as code (tool definitions, scopes, allowlists). Avoid managed products whose tool schema lives only in a UI — that's the migration blocker.

Keep reading

Go deeper