Self-Hosted vs Managed MCP Gateway: Which Fits Your Team?

Self-host an MCP gateway when you must run custom servers, keep traffic inside your network or integrate with internal identity, and you have staff to operate it. Choose a managed gateway when you want shared access to business data quickly and accept that a vendor holds the endpoint. The deciding factors are control, operations and what you need to host.

The two routes in one sentence each

Self-hosted: you deploy and run the gateway, on a server, container host or Kubernetes cluster, and you own everything from certificates to patching.

Managed: a vendor runs the endpoint. You connect sources, issue keys and point clients at a URL.

A third pattern sits between them: a vendor product you install in your own environment. It brings support but also your operations burden, so we treat it as self-hosted for planning purposes.

What changes between them

Dimension	Self-hosted	Managed
Time to first working endpoint	Days to weeks	Minutes to hours
Custom MCP servers	Yes, you run them	Depends; some host only data connections
Data location	Inside your boundary	With the vendor
Identity integration	Whatever you build or the project supports	What the vendor offers
Upgrades and patching	Yours	Vendor’s
Incident response	Yours	Shared, depends on the contract
Cost shape	Staff time, infrastructure	Subscription or usage fees
Lock-in	Lower, if you use open standards	Higher unless you can export policy and logs

What self-hosting actually involves

The Microsoft mcp-gateway README gives a realistic picture of a serious self-hosted setup. It targets Kubernetes, using StatefulSets and headless services. It stores metadata in Redis for local deployments and Cosmos DB for cloud ones. Its Azure deployment includes an application gateway, container registry, AKS, Cosmos DB, Application Insights and a managed identity, defined in Bicep templates. Authentication uses Entra ID tokens.

That is a good design for a team that already runs Azure and Kubernetes. It is a lot of new surface for a team that does not. List the things you would own:

1. Cluster or host provisioning and capacity.
2. TLS certificates and DNS.
3. Identity provider integration.
4. A database or cache for metadata.
5. Monitoring, alerting and on-call rotation.
6. Upgrades, including protocol revisions. The same README notes this version requires clients on the 2026-07-28 MCP revision.
7. Security reviews of every server you put behind it.

Key takeaway: with self-hosting, the software is free and the operations are not. Price the people, not the download.

What managed hosting changes

A managed endpoint removes most of that list. BusinessMCP’s managed MCP hosting page describes an endpoint served at /api/mcp, authenticated with a Bearer key, where you do not run a container, keep a tunnel open or copy config to each machine. Its access model, tool scoping and approval rules are visible in the generated tool reference.

It also states its own limits, which is the part to read first: it hosts your business data connections, not your MCP server code; it is not a marketplace of third-party SaaS connectors; the free tier is small; and the endpoint is only useful once you connect data sources. For a team that wants analytics, CRM or ads data inside an assistant, those limits may not matter. For a team whose goal is to run its own servers, they decide the question.

Questions that decide it

Answer these honestly and the choice usually becomes obvious.

Question	If yes, lean toward
Do we need to run our own MCP server code?	Self-hosted
Must data and logs stay inside our network?	Self-hosted
Do we lack platform engineers?	Managed
Do we need cloud assistants to reach it publicly this month?	Managed
Do we need custom identity integration?	Self-hosted, or enterprise managed tier
Do we only need business data in assistants?	Managed
Will compliance require a vendor assessment we cannot get?	Self-hosted

Security trade-offs

Neither route is automatically safer. Self-hosting concentrates risk in your own competence: a misconfigured public endpoint is a real exposure, and remote servers have a larger attack surface because they are reachable over the network. BusinessMCP’s remote versus local guide makes the same point about remote servers in general: authentication becomes mandatory, operations get heavier and the endpoint is publicly reachable.

Managed hosting moves the risk to a vendor and to your contract. You depend on their key management, tenant isolation and logging. Review the baseline in our security guide and ask for their security documentation and data processing terms before connecting anything sensitive.

Cost without the guesswork

Neither route has a universal price, and we will not invent one. What you can do is list cost lines for each and fill them in with your own numbers.

For self-hosting, count infrastructure, the engineer time to deploy and maintain it, the share of an on-call rotation it consumes, security review of each server you front and the upgrades that follow each protocol revision. A common mistake is to count only the first item.

For a managed endpoint, count the subscription or usage fees, the time to connect sources and issue keys, the compliance work to assess the vendor and the cost of leaving if you must. BusinessMCP’s pricing page is where it publishes plan details; its hosting page says the plans run from Free up to $499 per month overall without itemising each tier, and describes the Free tier as small. Treat any figure as something to verify on the day you decide, since plans change.

The honest comparison is time to value against control. Managed gets you a working, access-controlled endpoint quickly. Self-hosted gets you the freedom to run anything and keep everything inside your boundary, at the price of owning every failure.

Hybrid is normal

Many teams end up with both. A managed endpoint serves shared business data to assistants. A self-hosted gateway fronts internal servers that cannot leave the network. A local proxy handles developer experiments. All three can be configured in the same client, and each is governed by its own allowlist and keys.

A practical way to choose

1. Write down every tool and server you intend to expose.
2. Mark which must run in your environment and which are only data connections.
3. For the second group, trial a managed endpoint on a free tier with test data.
4. For the first group, pick a self-hosted candidate from our open source roundup and run a small pilot.
5. Score both with the evaluation checklist.
6. Decide what you would do if you needed to switch, and test that exit path before committing.

Revisit the decision yearly. Needs, products and your team change.