Self-Hosted vs Managed MCP Server: How to Decide

Choose self-hosting when the MCP server is your product, when data cannot leave your network, or when compliance requires full infrastructure control. Choose managed hosting when you want shared AI access to business tools without owning auth, credential storage, scaling and logging. Many teams end up using both for different servers.

What you take on when you self-host

Self-hosting means the whole stack is yours. BusinessMCP’s what is MCP hosting guide lists the burden as auth, token storage, TLS, scaling, logging and protocol upkeep. That list is vendor-authored but accurate to the spec: a remote server must authenticate requests, and the MCP authorization specification builds on OAuth 2.1 for HTTP transports.

In practice, a self-hosted remote server needs:

• A runtime and a deploy process.
• HTTPS with renewed certificates.
• An auth layer, either bearer tokens or an OAuth flow with protected-resource metadata.
• A place to keep upstream credentials that is not the agent’s context.
• Rate limits and input validation.
• Logs and alerting, as in MCP server monitoring.
• Updates when the spec or SDK changes.

None of it is exotic. It is a lot of small things, repeated for every server.

What you hand over when you go managed

A managed host runs that layer. With BusinessMCP’s hosted MCP endpoint you connect sources and use one URL with a bearer key or OAuth; there is no container, tunnel or local config file. Credentials sit in an encrypted vault resolved server-side, according to its guides, and every call is logged.

What you give up is real. You trust the vendor’s isolation and logging claims. You are limited to what the platform exposes: BusinessMCP states it does not host your own server code and is not a marketplace of third-party SaaS connectors. And you inherit the vendor’s pricing, which for BusinessMCP is flat monthly tiers based on tracked users and AI runs.

Side-by-side

Factor	Self-hosted	Managed
Control over code	Total	Limited to what the platform offers
Data location	You choose	Vendor’s infrastructure
Auth and key management	You build or integrate	Provided, quality varies
Time to first working endpoint	Days	Often hours, but BusinessMCP notes the first week is mostly OAuth setup
Ongoing ops	Yours	Mostly the vendor’s
Cost shape	Compute plus engineer time	Subscription, often tiered
Audit trail	Whatever you build	Usually included
Exit	Easy, it is your code	Check export terms

Key takeaway: the choice is about where operational risk should sit, not about which option is “more real.” Put it where you are best equipped to carry it.

The cost argument, examined

BusinessMCP’s remote-versus-local guide argues that a flat subscription usually beats recurring engineer time. That is plausible for small teams with one or two servers and weak for a platform team that already runs hardened services and has idiomatic tooling for auth and observability. The honest method is to price your own engineer hours. Our cost article gives a worksheet.

When self-hosting is clearly right

1. The server is the product. You cannot outsource your product’s runtime to a platform that does not run custom code.
2. Data must stay inside a network. Regulated or contractually restricted data often cannot transit a third-party host.
3. You need unusual runtime behaviour, such as long-lived streams, GPUs or private network access.
4. You already operate comparable services and the marginal cost is low.

When managed is clearly right

1. The goal is AI access to existing SaaS and business data, not a custom tool.
2. The team has no one to carry the pager for an auth-bearing public service.
3. You need governance quickly: per-agent keys, allowlists and an audit log.
4. Several non-technical people need to connect assistants with a sign-in flow.

The hybrid that many teams land on

Run the one or two servers that are genuinely yours on your own infrastructure, and use a managed endpoint for everything standard. BusinessMCP’s page says its endpoint aggregates third-party MCP servers you connect, registering their tools under an ext_ prefix, so a self-hosted server can sit behind the same governed URL. That gives agents one connection point while keeping custom code under your control. The details of authentication for such a setup are in MCP server hosting with authentication.

How to decide this week

Write down four facts: who must reach the server, what data it touches, who will be on call, and what you would pay in hours. If the answers are “outsiders, sensitive, nobody, many,” go managed or hybrid. If they are “internal, our own, a platform team, few,” self-host. Revisit in a quarter, because the right answer shifts as usage grows. When you are ready to execute either path, the deployment walkthrough covers the self-host steps.

Questions to put to a managed vendor

If managed is on the table, ask these in writing and compare answers across vendors:

1. Does the server run my code, or only expose connected sources?
2. How are upstream credentials stored, and can an agent ever read them?
3. How is tenant data isolated? BusinessMCP says it uses database-level row-level security with workspace-scoped tables; ask every vendor what the equivalent is.
4. Can I scope each key to a tool allowlist and turn write tools off by default?
5. Is every call logged, and can I export the logs?
6. What is the exit path, and in what format does my data leave?
7. What happens to my endpoint when the MCP spec revises?

Questions to put to yourself if self-hosting

1. Who is on call for an authenticated public service, and what is their time worth?
2. How will we rotate tokens without outages?
3. Do we have monitoring that speaks MCP, not just HTTP?
4. Who reviews tool description changes for injection risk?

If any answer is “nobody” or “we have not thought about it,” that is the cost you were not counting, and it is the most common reason small teams move from self-hosted to managed within a year of launch.