By Nolan Sullivan, Founding Growth EngineerA managed MCP gateway is a Model Context Protocol (MCP) gateway that a vendor operates on infrastructure the vendor runs. A self-hosted MCP gateway is one your team deploys, upgrades, and operates on infrastructure you control. The choice decides who carries the operations work and whose infrastructure tool-call traffic crosses. It does not, on its own, decide whether the gateway can be reached from the public internet.
An MCP gateway sits between AI agents and the MCP servers they call. It authenticates the caller, decides which tools that caller may use, logs each call, and usually holds the upstream OAuth tokens and API keys for every system behind it. That last property is why the hosting question comes up early in security reviews. Whoever runs the gateway runs a credential store for the organization’s tools.
Self-host when the data path is the requirement, meaning tool-call payloads may not cross a third party, data has to stay in a named account, or the network is air-gapped. When the requirement is that MCP traffic stays off the public internet, a managed gateway with private network access usually meets it with less work. The rest of this page walks through the six questions that separate those cases.
What is the difference between a managed and a self-hosted MCP gateway?
The difference is who operates the software and on whose infrastructure the traffic runs. In practice there are several models between the two ends, and some vendors sell more than one. Ordered from least to most that your team runs:
| Model | Who operates it | Where tool traffic flows | Examples |
|---|---|---|---|
| Multi-tenant managed | The vendor | The vendor’s infrastructure | Cloudflare MCP server portals, Speakeasy |
| Vendor-operated in your account | The vendor | Your cloud account or VPC | Docker MCP Enterprise Gateway, “managed in your cloud” |
| Managed control plane, self-hosted data plane | The vendor runs configuration; you run the proxy nodes | Your nodes | Kong Konnect in hybrid mode |
| Self-hosted | Your team | Your infrastructure | IBM ContextForge, Docker MCP Gateway, self-managed Kong Gateway |
| Air-gapped | Your team, sometimes on a vendor appliance | A network with no outbound connection | Docker MCP Enterprise Gateway air-gapped appliance |
Docker’s MCP Enterprise Gateway page lists three deployment options: Docker-operated inside your own account or VPC, an air-gapped appliance on private Kubernetes, and a multi-tenant Docker-managed cloud that the page describes as coming. Kong’s deployment topologies split a cluster into a control plane, where configuration is managed, and data planes that serve traffic, and the data planes can be Kong-managed or self-managed.
Exposure is a separate axis. A self-hosted gateway behind a public load balancer is as reachable from the internet as any hosted one, and a managed gateway can be private when the vendor joins it to your network. What is a private MCP gateway? covers that distinction in full. This page uses it only where it changes who should run the gateway.
What is the case for self-hosting an MCP gateway?
The case for self-hosting is strong, and for some organizations it settles the question before any other criterion is considered:
- The gateway sees the most sensitive traffic agents produce. Tool arguments and results carry customer records, source code, tickets, and query results. Running the gateway yourself removes a processor from that data flow and a vendor from the list of parties whose breach becomes yours.
- Upgrades happen on your schedule. You can test each release against your own MCP servers, pin versions in change management, and roll back without waiting on anyone.
- You can read the code. IBM ContextForge is Apache 2.0 licensed and Docker MCP Gateway is MIT licensed. A security team can audit what the gateway does with credentials instead of relying on a vendor’s description.
- Internal servers are already reachable. A gateway deployed in the same VPC as your internal MCP servers needs no tunnel and no connector.
- Some environments allow nothing else. Air-gapped networks, and contracts that forbid third-party processing, rule out multi-tenant managed gateways outright.
Each of these is a real advantage, but the cost is that the gateway becomes a tier-zero service your team runs, upgrades, and answers pages for. And several requirements that start the self-hosting conversation turn out, when written down, to be about exposure, which both models can meet.
How do you decide between a managed and a self-hosted MCP gateway?
Work through the six questions in order. Data path and reachability are the two that can rule an option out entirely, while operations, upgrades, identity, and compliance mostly change what each option costs.
Operations burden: who runs a tier-zero service?
A self-hosted MCP gateway is more than a proxy process. IBM ContextForge’s documentation recommends PostgreSQL and Redis alongside the gateway for production, offers Docker Compose and Helm deployments, points to a configuration reference of more than 300 environment variables, and lists secrets that must be set before production, including the JWT signing key, the credential encryption key, and the bootstrap admin password. Any gateway that stores credentials needs the same.
Around the gateway itself, your team takes on high availability, backups of the token store, rotation of the key that encrypts stored credentials, TLS, monitoring, log export, base image patching, and on-call. Multi-node deployments need extra care with session state. Kong’s AI MCP Proxy plugin lists session sharing between instances as not supported, which is worth testing before putting several data plane nodes behind one load balancer.
A managed gateway moves that work to the vendor and replaces it with a dependency. When the vendor’s platform is down, the MCP servers behind it are unreachable, and your incident response is a status page. Kong’s hybrid mode reduces this risk for the traffic path, because its data planes keep serving with their last known configuration when the control plane is offline.
The deciding question is whether you already run a platform team that operates stateful, credential-holding services with on-call. If you do, a self-hosted gateway is one more of those. If you don’t, the gateway would be the first, and standing up that capability is a larger project than the gateway.
Upgrade cadence: who decides when the gateway changes?
MCP changes at the protocol level often enough that gateway versions matter. Kong’s AI MCP Proxy documentation says the plugin uses protocol version 2025-06-18, supports upstream servers on 2025-06-18 and 2025-11-25, and doesn’t support 2024 versions. It also records that before Kong Gateway 3.14, a request denied by an access rule returned a JSON-RPC INVALID_PARAMS error, and that 3.14 changed this to an HTTP 403 to match the 2025-11-25 authorization specification. Cloudflare’s MCP server portals already accept stateless MCP 2026-07-28 clients alongside 2025 Streamable HTTP. ContextForge introduced multi-tenancy, teams, and RBAC in v0.7.0, and its SSO documentation tells deployments upgrading from 0.6.0 to review the migration guide and changelog first.
Every one of those changes is something an operator has to roll out. With a self-hosted gateway, you choose the timing and test each release against your servers first. You also own the lag: when a client adopts a newer protocol revision, or a security fix ships, it waits for your next upgrade window. With a managed gateway, changes arrive when the vendor ships them. You don’t schedule the work, and you can’t defer a change that breaks one of your workflows, so ask each vendor how it announces breaking changes and whether changes can be staged.
The deciding question is how your change management treats infrastructure. If every version is pinned and tested before production, self-hosting fits the process you already have. If your process accepts SaaS changes under a vendor’s notice policy, a managed gateway removes the upgrade work entirely.
Data path and residency: whose infrastructure sees tool traffic?
This is the question that can rule a managed gateway out. Every call through an MCP gateway carries the tool’s arguments and its result, and with a multi-tenant managed gateway both cross the vendor’s infrastructure. Anything the gateway stores, such as logs, transcripts, or upstream tokens, lives there too.
With a managed vendor, ask:
- What does the gateway store by default, and what is opt-in?
- How long is stored data retained, and can you shorten it?
- In which regions is data processed and stored, and can you choose?
- Which subprocessors handle sign-in, logging, or storage?
- Who controls the keys that encrypt stored credentials and sign tokens?
A self-hosted gateway keeps traffic and storage wherever you deploy it, and it makes you the custodian of every upstream credential it brokers. ContextForge, for example, requires an AUTH_ENCRYPTION_SECRET passphrase for encrypting stored credentials, so generating, storing, and rotating that key is your team’s job.
Between the two, Docker’s vendor-operated option runs the gateway inside your own account or VPC, where, per Docker, data and traffic stay in your environment. For an air-gapped network, Docker’s appliance runs on private Kubernetes with no outbound connection. A multi-tenant managed gateway cannot meet an air-gap requirement under any configuration.
The deciding question is whether tool arguments and results may cross a third party’s infrastructure under a data processing agreement. If they may not, multi-tenant managed gateways are out, and the choice is between self-hosting and a vendor-operated deployment in your account. If they may, the data path becomes an item in vendor review rather than an architecture decision.
Network reachability: what has to be public?
Reachability runs in two directions, and the two favor different models.
From the gateway to MCP servers. A self-hosted gateway in your VPC reaches internal MCP servers directly. A managed gateway needs a route in, usually an MCP tunnel: a small agent inside your network opens an outbound connection to the gateway, so internal servers need no public address and no inbound firewall rule. Check the details per vendor. Cloudflare’s portals reach private MCP servers through Cloudflare Tunnel with Gateway routing turned on, but the documentation states that the OAuth authorization and token endpoints must be accessible on the public internet.
From agents to the gateway. List your callers. Agents on managed laptops and CI runners can sit on a private network. Hosted agents, such as remote connectors in ChatGPT or Claude, call MCP servers from the vendor’s cloud and can only reach a public endpoint. That holds regardless of who runs the gateway. A self-hosted gateway that has to serve hosted agents still needs public ingress, and its exposure is then whatever your load balancer, ingress controller, and DNS say it is, which can change in a later deploy.
The requirement that often sits behind “we need to self-host” is “the gateway can’t have a public listener.” That is a reachability requirement, and a managed gateway meets it if the vendor can join the gateway to your private network. Few managed MCP gateways document this. Where one does, you keep vendor operations and remove the public listener, at the costs the private MCP gateway page lays out: every client has to be enrolled in the network, a network outage takes tool access with it, and OAuth flows to an external identity provider usually still need the internet. Speakeasy offers this as Tailscale private access for Enterprise organizations, covered in the note at the end of this page.
The deciding question is which of your callers run on devices you manage, which run in a vendor’s cloud, and which of your MCP servers live inside your network. If hosted agents are callers, some path has to be public whichever model you choose. If every caller is on your network, both a self-hosted gateway in your VPC and a managed gateway with private access work, and the choice falls back to operations and data path.
Identity integration: who maintains the mapping?
Both models integrate with your identity provider. The difference is who builds the mapping from directory groups to per-tool permissions and who keeps it working. On the self-hosted side, ContextForge documents SSO with GitHub, Google, IBM Security Verify, Microsoft Entra ID, Keycloak, Okta, and generic OIDC, creates users on their first SSO login, and maps identity provider groups to teams. Kong authenticates MCP callers with its OpenID Connect or Key Auth plugins and, from version 3.13, applies per-tool ACLs to Consumers and Consumer Groups.
Whichever model you choose, check three things:
- Offboarding. Creating a user on first login handles joiners. Removing access when someone leaves the directory needs SCIM or another sync, so confirm which one the gateway supports and test it.
- Upstream credentials. Decide whether each user connects their own account to each upstream service, or whether one shared credential per server is acceptable, and who can revoke either.
- The identity provider’s own location. Okta and Microsoft Entra ID are SaaS, so self-hosting the gateway rarely removes the internet dependency for sign-in.
The deciding question is whether your identity team wants to own the group-to-tool mapping as configuration it maintains, which suits a self-hosted gateway, or wants directory sync with a vendor keeping the integration current, which suits a managed one.
Compliance: whose controls get audited?
Compliance frameworks ask for controls and evidence: access control, logging, change management, encryption, and vendor management. They rarely specify who runs the software. With a managed gateway, the vendor’s SOC 2 Type II or ISO 27001 report covers its operation of the gateway, you add the vendor to your third-party risk program, and your evidence covers your own configuration. With a self-hosted gateway, the gateway falls inside your audit scope, so your team produces the evidence for patching, access reviews, log retention, and key management.
Neither model makes an organization compliant. Both need the same per-call audit trail exported to your SIEM, which self-hosted options support through OpenTelemetry in ContextForge and an audit log of allowed and denied ACL decisions in Kong’s plugin. Where the two diverge is a contract or regulator that forbids a third-party processor, or a government network that requires an authorization the vendor doesn’t hold. Those rule out multi-tenant managed gateways the same way the data path question does.
The deciding question is whether your auditor will accept a vendor’s report for the gateway layer. If they will, a managed gateway reduces your evidence work. If a contract rules out the processor, self-host or use a vendor-operated deployment in your account.
Which should you choose?
The table summarizes where each question points.
| Question | Points to managed when | Points to self-hosted when |
|---|---|---|
| Operations burden | No team runs stateful, credential-holding services with on-call | A platform team already operates services like it |
| Upgrade cadence | Vendor-scheduled changes with notice are acceptable | Every version has to be pinned and tested first |
| Data path and residency | Tool traffic may cross a vendor under a data processing agreement | Tool traffic may not leave your account, region, or network |
| Network reachability | Hosted agents are callers, or the vendor can join your private network | Every caller and server is already on a network you run |
| Identity integration | You want directory sync maintained by the vendor | Your identity team wants to own the mapping as configuration |
| Compliance | The auditor accepts a vendor’s SOC 2 or ISO 27001 report | A contract or regulator rules out a third-party processor |
Each choice also has its own way of going wrong. A managed gateway can go down with its vendor, change under you on the vendor’s schedule, or support only the private networks the vendor has integrated with. A self-hosted gateway can fall behind on upgrades until it is the least-patched service holding the most credentials, drift into public exposure after a load balancer or DNS change, and turn a credential-store breach into your incident rather than a vendor’s. Picking managed accepts the first set of risks, and picking self-hosted accepts the second.
Which self-hosted MCP gateways are available?
Each entry covers what the vendor documents as of October 2026. The best MCP gateways for enterprise in 2026 scores a wider set of products, and Which MCP gateway architecture do I need? compares routing infrastructure with governance platforms. For head-to-head comparisons, see Speakeasy vs Docker MCP Gateway, Speakeasy vs IBM ContextForge, Speakeasy vs Kong, and Speakeasy vs Cloudflare MCP server portals.
Docker MCP Gateway
Docker MCP Gateway is Docker’s open source gateway. It runs each MCP server in an isolated container with restricted privileges, network access, and resources, starts servers on demand, injects credentials, and includes logging and call tracing. It powers the MCP Toolkit in Docker Desktop and can run on Docker Engine without Desktop, with servers grouped into profiles and per-tool allowlists set from the CLI. Its strength is server isolation, which matters most for the local npx and uvx servers that otherwise run with a developer’s full permissions.
The open source gateway is built around a developer’s machine. Organization-wide governance, with SSO, group-scoped tools, per-call policy, and SIEM audit, is in the separate MCP Enterprise Gateway, which Docker sells through its sales team, and Docker’s documentation describes MCP Gateway as part of Docker AI Governance as invite-only. The Enterprise Gateway’s deployment options (in your account, air-gapped, and a planned Docker-managed cloud) are in the table near the top of this page.
IBM ContextForge
ContextForge is an open source registry and proxy that federates MCP servers, A2A agents, and REST or gRPC APIs behind one endpoint. It adds virtual servers that bundle selected tools, an admin UI, more than 40 plugins, OpenTelemetry tracing, and multi-cluster Kubernetes deployment with Redis-backed federation, and it supports SSO with the major identity providers. It suits a platform team that wants to self-host and bring existing non-MCP services into the same catalog.
The trade is operational scope: production use means running ContextForge with PostgreSQL and Redis, working through a large configuration surface, and following its migration guides between versions, as the operations and upgrade sections above describe.
Kong AI Gateway
Kong adds MCP to its API gateway through the AI MCP Proxy plugin, which requires the AI Gateway Enterprise offering. Kong AI Gateway 2.0 replaces the plugin with an AI MCP Server entity, so the details here are for the 3.x plugin. The plugin can proxy existing MCP servers, convert REST APIs described by OpenAPI into MCP tools, and aggregate tools from several services behind one MCP endpoint. Kong’s authentication, rate limiting, and logging plugins then apply to MCP traffic, and per-tool ACLs filter both tool listing and invocation. For an organization that already runs Kong for its APIs, this puts MCP under the policies and operations it already has, and hybrid mode lets Kong run the control plane while you host the data planes.
Kong documents its gaps plainly. The plugin’s scope-of-support table lists AI Guardrails on MCP requests and responses, WebSocket and gRPC upstreams, structured output, tool-change notifications, and session sharing between instances as not supported.
Managed options to compare against
Cloudflare MCP server portals, part of Cloudflare One, are the closest managed comparison for an organization already on Cloudflare. A portal puts several MCP servers behind one endpoint, uses Cloudflare Access identity policies to decide who reaches it, curates and renames tools, logs tool requests, and can route traffic through Cloudflare Gateway for HTTP logging and DLP scanning. Private servers connect over Cloudflare Tunnel. Cloudflare’s documentation notes two boundaries: OAuth authorization and token endpoints for private servers must be public, and a user blocked by a portal’s Access policies can still reach an MCP server through its direct URL unless Access is configured as that server’s OAuth provider.
A note on Speakeasy
We build the Speakeasy MCP gateway, so this section isn’t neutral. The gateway runs as part of the AI Control Plane and is managed by Speakeasy by default.
Need to self-host?
Self-hosting is available for Enterprise customers. Book time with our team to learn more.
For teams whose requirement is reachability, Speakeasy’s Tailscale private access is the middle path, and it requires an Enterprise organization. An org admin connects a tailnet once with a dedicated Tailscale OAuth client, and the gateway gets a private hostname on that tailnet. Each MCP server or gateway is then set to public only, public and private, or private only, so clients can move one server at a time. Private-only servers stop serving on public URLs with no automatic public fallback, so a tailnet outage leaves them unreachable rather than exposed. Tailscale membership adds a network check, and MCP authentication and tool permissions still apply to every private connection.
The limits are specific. Tailscale is the only private network provider today. Private access covers how MCP clients reach hosted endpoints, and it doesn’t make the dashboard, management APIs, or outbound connections to tool backends private. For servers inside your network, tunneled MCP servers run a tunnel agent that opens one outbound connection with no inbound firewall rule, and the two can be combined so neither end of the path is public. The private MCP gateway release post describes that pairing.
On the other four questions, Speakeasy ships changes to the hosted gateway continuously and records them in the changelog. Its platform security documentation says the platform processes customer data in transit, makes storage of session transcripts, tool telemetry, and tool inputs and outputs opt-in, and retains stored logs for 90 days by default. It names WorkOS as the dependency for SSO and directory sync, and it doesn’t describe a customer-selected data region, so ask if residency in a named region is contractual. Customer-managed signing keys in your own cloud KMS are enabled per organization. Directory Sync assigns roles from identity provider groups and removes access when people leave the directory, roles narrow access to specific servers or tools, and Enterprise Managed Auth lets people sign in once with Okta and reach their MCP servers without a separate OAuth prompt per service. Administrative changes appear in Audit Logs, and Speakeasy holds SOC 2 Type II and ISO 27001 (security).
If you’re partway through a security review and the self-hosting question is still open, we’d like to hear which requirement is driving it. Talk to us.