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
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.