MCP server hosting: how to run MCP servers for a team

An MCP server is a process. The Model Context Protocol defines how a client discovers and calls tools on that process, but it says nothing about where the process runs or who keeps it alive. That part is yours. Hosting an MCP server means answering four questions: where the process runs, who can reach it, what it can reach, and who is accountable for each tool call it serves.

This guide is for platform engineering and AI enablement teams moving MCP servers off developer laptops and onto shared, governed infrastructure. If you need one server on your own machine, you can stop after the transport section. Stacklok runs this layer on our customers’ own Kubernetes clusters and secures more than 20 million tool calls a month, so the steps below cover what a production setup has to handle, which is far more than getting a server online.

Here’s what you’ll take away from this post:

• Use Streamable HTTP for any server more than one person shares. Stdio servers can still be hosted centrally once they’re containerized and fronted by a proxy.
• Self-hosting on Kubernetes is where most teams land once a server touches internal data or needs an audit trail. The process is easy to run; the governance around it is the work.
• Add identity, segmentation, isolation, and observability before anyone connects a real server to a real AI client. They are much harder to retrofit.
• Stacklok runs the runtime, registry, vMCP gateway, and authorization server inside your cluster, with no SaaS dependency.

Stdio or HTTP: the transport decides how a server can be hosted

MCP servers use one of two transports, and everything else follows from that choice.

Stdio. The client spawns the server as a child process, often with npx or uvx, and talks to it over standard input and output. There is no port, no URL, and no network identity. Each client gets its own process.

Streamable HTTP. The server listens on a port and behaves like any other web service, so many clients can share one deployment. Inside a container, it has to listen on an address the rest of the cluster can reach. Get that wrong and the server starts cleanly but nothing can talk to it.

How the two compare on the points that matter for hosting:

• Who starts it: for stdio, the MCP client, once per session. For HTTP, an orchestrator, once.
• Who can reach it: for stdio, only the local machine. For HTTP, anything that can route to the URL.
• Concurrency: for stdio, one client per process. For HTTP, many clients per deployment.
• Where credentials usually live: for stdio, a local config file. For HTTP, a secret store, or they should.
• What remote hosting requires: for stdio, a proxy that exposes it over HTTP, plus a container. For HTTP, a container and the controls around it.

Transport affects more than deployment. When we load-tested MCP servers in Kubernetes, transport choice was the biggest single factor in performance and scaling. Plan on HTTP for anything shared. A stdio server can still be hosted centrally once it is wrapped and containerized; Step 3 covers how.

Three places to run MCP servers, and when each one fits

Local stdio on a laptop

For one person experimenting, a local stdio server is the right call. You add a block to your AI client’s config, the client spawns the server on demand, and the API key sits beside it. The cracks show when a second person needs the same server: credentials get copied between machines, each install drifts to its own version, and nothing records who called which tool, because the call never crossed a boundary you control.

A vendor-managed cloud endpoint

Someone else keeps the process alive and you get a URL. For public or read-only servers that touch nothing sensitive, that’s a reasonable trade for the speed. The cost is that tool invocations, credentials, and agent context leave your network, and reaching an internal system means either opening it to the vendor or handing credentials to infrastructure you don’t control. Under data-residency rules or an internal no-SaaS policy, that usually ends the discussion.

Self-hosted on your own infrastructure

Once a server touches internal data, falls under data-residency requirements, or has to be audited, most teams self-host. The server process itself is usually a small service of the kind your platform team already runs. The effort goes into everything around it: inventory, provenance, isolation, identity, policy, and audit.

Many teams use a mix, with local servers for development and governed remote servers for anything shared. Stacklok’s hybrid deployment model is built for that split. For the full argument on where the control layer should sit, read why your MCP gateway, registry, and runtime belong on your own infrastructure.

What production MCP hosting needs beyond a URL

A deployed server with no access control is a tool endpoint that anyone on your network can call. Reachability is the easy half. A production setup also needs:

• An inventory of the MCP servers already running.
• Vetted server sources with verified provenance.
• A separate container for each server.
• Network and filesystem limits for each server.
• Identity checked on every inbound request.
• Tool segmentation by team, and per-user credentials for downstream calls.
• Observability and audit that feed your existing stack.
• Operational controls: token cost management, circuit breakers, and a kill switch.

Identity integration, tool segmentation, container isolation, and instrumentation are all much harder to retrofit once teams depend on a deployment. In our experience, the cheapest time to add them is before anyone connects a real server to a real AI client.

Step 1: find the MCP servers already running

Your developers are probably already running MCP servers you don’t know about, each configured separately, with personal tokens in local config files and no rotation policy. Take an inventory before you centralize anything: which servers, which versions, which credentials, and which clients.

Then plan to retire the local copies. A governed endpoint that half the team bypasses is a second path to the same servers, and the ungoverned path is where your audit gaps will open. Aim for one governed path per server.

Step 2: choose server sources you can trust

MCP servers are software dependencies. The ecosystem is young, and an attacker who compromises an upstream server package gets whatever permissions you granted that server.

• Pin explicit versions. An unpinned npx -y or uvx command resolves to whatever is latest when the container starts, so two replicas started at different times can run different tool sets.
• Verify provenance. Pinning tells you which version you asked for, not where it came from. Stacklok integrates Sigstore and GitHub Attestations to verify a server’s origin and detect tampering before deployment. We cover the details in solving the MCP server trust problem.
• Curate an internal registry. When server URLs live in Slack threads, nobody knows what has been approved. Stacklok’s Registry Server implements the official MCP Registry API, so teams discover approved servers from one catalog. See how the registry works and browse our curated registry of MCP servers.

Stacklok is a maintainer of the official MCP registry, so we have a direct stake in getting this right.

Step 3: package each server as its own container

Run every MCP server in its own container. When all servers share one runtime, one compromised or misbehaving server gives an attacker a path to the others. Separate containers give each server its own permission boundary, which Step 5 tightens.

For published Node.js and Python packages, you don’t need to write a Dockerfile. Stacklok builds the container from the package at deploy time; see running Node.js and Python MCPs without a Dockerfile.

Stdio servers need one more piece: a proxy in front of the process that translates HTTP requests from clients into the stdin and stdout traffic the server expects. Deploy through the ToolHive Kubernetes Operator and the proxy is configured for you.

Keep tokens out of command arguments and config files. Arguments end up in plain-text manifests and can appear in process listings. Inject credentials at launch from a secret store instead. Stacklok’s managed runtime does this, so credentials never live in the image or on the command line.

Step 4: deploy declaratively on Kubernetes

Kubernetes lets you manage MCP servers the same way you manage your other workloads, with the same RBAC, namespaces, scheduling, and GitOps pipelines. One of our customers put it this way:

“Everything we do at project44 is Kubernetes-native. If all of our services run on Kubernetes, it would not make sense for our MCP servers to operate differently.”

Read how project44 centralized control of MCP server access and governance. Here is the declarative workflow with the ToolHive Kubernetes Operator:

1. Install the Operator with Helm.
2. Declare each server as an MCPServer custom resource. The server definition lives in Git next to the rest of your infrastructure, so reviews and rollbacks follow the process you already use.
3. Let the Operator provision RBAC. For each MCPServer, it creates a dedicated, namespace-scoped ServiceAccount, Role, and RoleBinding with minimal permissions. Nobody has to configure a ClusterRole by hand.
4. Add gateway and discovery resources through the same pipeline. VirtualMCPServer and EmbeddingServer resources go through your existing CI/CD like MCPServer resources do.
5. Scope the Operator for multi-team clusters. The Registry Server can watch MCPServer resources across namespaces, and the allowedNamespaces setting controls which namespaces the Operator governs. See multi-namespace support in the ToolHive Operator.

Treat upgrades like any other platform component: test them in a staging cluster first, and watch the ToolHive GitHub repository for breaking-change notices. For the broader reasoning, see why Kubernetes is the right platform for running MCP servers in production and our MCP runtime.

Step 5: restrict what each server can reach

Identity controls decide who can call a tool. Container isolation decides what the tool can do once it is called. They cover different threat surfaces and need different controls.

• Limit network egress per server. Allow outbound connections only to the hosts and ports the server needs. A GitHub MCP server needs outbound HTTPS to the GitHub API and nothing else on your network.
• Mount the filesystem read-only by default. Grant write access only when a server has a specific need for it.
• Apply profiles before exposure. In Stacklok, you set network access and filesystem scope for each server through JSON permission profiles. Put them in place before anyone can reach the server.

These limits contain the damage. If an upstream package turns malicious, it can only reach what you allowed. For more detail, read who are your MCP servers talking to? and our MCP security best practices for Kubernetes teams.

Authenticating users and agents to hosted MCP servers

Authentication answers who is calling. Authorization answers what that caller may do, and for MCP it should be evaluated on every tool call, not once per session.

Many hosted MCP setups blur session-level and request-level checks. A bearer token issued at session start creates ambient authority: the agent can do anything the token allows, at any point, for any task, until the token expires. The token only proves that someone authenticated at a certain time. It doesn’t prove that a specific tool call, triggered by a specific request, was authorized under a specific policy. Per-request identity closes that gap by validating the identity token on every tool invocation, so each call is authorized and audited on its own.

The model that holds up is simple. Users authenticate once through your enterprise identity provider, and that identity governs access to every hosted server. There is no per-device MCP configuration, no credentials stored on laptops, and nothing local to rotate. When someone leaves the company, you revoke access in one place.

In Stacklok, an embedded authorization server runs in-process inside your cluster. It supports OIDC and OAuth 2.0 and integrates with Okta, Microsoft Entra ID, and Google Workspace. No vendor-hosted authorization endpoint sits in the request path, and connecting your IdP is a configuration step rather than a development project. For a worked example, see deploying an Okta-authenticated BigQuery MCP server on Kubernetes. For the design reasoning, read getting authentication right is critical to running MCP servers.

Per-request identity through OIDC and OAuth 2.0 is production-ready today. Native SPIFFE/SVID workload identity, which would let Stacklok accept attested workload identities directly from SPIRE, is on our roadmap and has not shipped. If your security team needs workload attestation now, SPIRE can run alongside Stacklok. Our post on SPIFFE and relationship-based authorization for AI agents covers that architecture.

Step 6: segment tools by team and scope downstream credentials

Without segmentation, one endpoint exposes every tool to every user. A developer shouldn’t be able to call your HubSpot MCP server, and your marketing team shouldn’t reach your internal engineering metrics API.

Stacklok’s Virtual MCP Server (vMCP) creates segmented endpoints. Each endpoint aggregates a subset of your servers and is gated by identity provider group membership: engineering gets one endpoint, marketing gets another, and a shared endpoint carries tools everyone needs, such as Slack or Google Drive. Access is evaluated per request, and a user whose token lacks the required group claim is rejected before the request reaches any MCP server.

Segmentation can go deeper than the endpoint. You can scope policy per agent identity, per team, per server, or per tool, so read operations can be allowed while write operations are denied inside the same server. Stacklok expresses these rules in the Cedar policy language. See secure-by-default authorization for MCP servers.

Then deal with the other direction. Many MCP gateways authenticate the user at the front door and then call every backend with a single service credential. The gateway’s log shows who asked; the backend’s log shows only the service account. As we explain in if your MCP gateway calls backends as one service principal, your audit log names nobody, that breaks attribution at the point your compliance team will look. Token exchange (RFC 8693) issues short-lived, scoped tokens so the backend sees the real user. See token delegation for multi-user AI systems.

Agree with your security team on which tools belong in which segment before go-live, so you aren’t deciding it during an incident.

Step 7: instrument hosted servers before go-live

Once AI agents start originating tool calls, the familiar trail disappears. A developer who runs a bad query shows up in your logs and can be traced to a person. An agent can run thousands of tool calls and stay invisible unless the MCP layer itself is instrumented.

At minimum, instrument three things before launch:

• Request volume for each server and each access group, so you can spot unusual usage patterns.
• Authentication failures. An unexpected spike points to either a misconfigured policy or an access attempt outside normal patterns.
• Full request metadata for tool calls that touch sensitive systems, structured and exported to your SIEM.

Stacklok exports OpenTelemetry metrics and traces that follow the OTel MCP semantic conventions, along with structured JSON audit logs that work with Splunk, Datadog, New Relic, and Elastic. Standard attribute names mean your existing observability stack can ingest MCP telemetry without a custom integration layer.

Step 8: run many servers without runaway cost or cascading failures

Hosting one server is a deployment task. Hosting dozens is an operations task, and three problems show up as the count grows.

• Tool catalog bloat. When every agent loads the full tool catalog of every connected server at startup, token costs multiply. The MCP Optimizer embedded in vMCP surfaces tools on demand through hybrid semantic and keyword search. In our write-up of MCP platforms for multi-agent workflows, we report a 60–85% per-request token reduction for every agent connected through vMCP.
• Degraded backends. vMCP includes circuit breakers that isolate a degraded backend server, so one failing tool doesn’t take down every workflow that runs through the gateway.
• A server that changes behavior. An MCP server your team approved six weeks ago can start making calls nobody recognizes, perhaps because a dependency changed underneath it. You need a way to cut it off fast. We explain why in why organizations need a kill switch for their MCP servers.

Connecting a cloud-hosted AI client to servers behind your firewall

Self-hosting creates a structural problem for teams using a cloud-hosted model: the model runs at the provider while the data sits behind your firewall. A traditional remote MCP deployment would expose internal infrastructure to inbound traffic, and security teams usually reject that outright.

Anthropic MCP Tunnels reverse the direction of the connection. Your infrastructure connects outward to Anthropic over mutual TLS with an additional Anthropic-managed encryption layer, so you don’t open inbound ports or change firewall rules. On Anthropic’s side, a service called Toolbox acts as the MCP client for Claude Code, Claude Enterprise, and agentic products, so one tunnel serves all of those surfaces.

The tunnel is a transport layer. Deciding which employees can use which tools, enforcing segmentation, and producing an audit log all fall outside its job; those controls belong on your side of the tunnel, and that is the layer Stacklok provides. The one dependency to plan for is that the tunnel requires an outbound connection to Anthropic. Everything else, including server management, identity federation, vMCP routing, and observability, can run inside your private cloud. Our five tips for deploying Anthropic MCP Tunnels in a regulated environment go through the setup.

Common MCP server hosting mistakes

• Tokens in arguments or local config files. They leak through manifests, process listings, and copied configs. Use environment variables backed by a secret store.
• Unpinned, unverified packages. Replicas drift apart, and a compromised upstream release goes straight into production.
• All servers in one runtime or with one broad permission set. One bad server becomes a route to every other server and to the network around them.
• A shared URL with no per-user identity. You can see that someone called a tool but not who. A gateway that calls every backend as one service account has the same problem one layer down.
• Personal local copies left running. Half the team uses the governed endpoint and half still runs servers locally with personal tokens. That isn’t centralization.
• Controls added after adoption. Identity, segmentation, and observability are much harder to add once teams depend on the deployment.

For a structured risk framework, see how Stacklok addresses the OWASP MCP Top 10.

Where Stacklok fits, and where it doesn’t

Stacklok suits teams that already run Kubernetes and want MCP hosting, identity, policy, and audit inside their own cluster, managed like their other workloads. The platform runs the runtime, registry, vMCP gateway, and Portal inside your infrastructure. Our platform engineering page describes how teams run it day to day.

Two limits. First, the full enterprise feature set (the Kubernetes Operator, vMCP gateway, embedded authorization server, and Portal) requires Kubernetes. If your organization cannot operate container infrastructure, other options will suit you better. Second, native SPIFFE support is on our roadmap and has not shipped.

Get started

Want to see how this would apply to your current servers and identity provider? Book a demo and we’ll walk through it with you. If you’d rather start hands-on, ToolHive, Stacklok’s Apache 2.0 open source project, is the fastest way to run a proof of concept, and you can move to the Stacklok enterprise platform when you need the full feature set. Questions along the way? Join our team on Discord at https://discord.gg/stacklok. Still evaluating options? The MCP platform buyer’s guide for platform teams sets out the questions to ask any vendor, including us.

Frequently asked questions

What is MCP server hosting?
MCP server hosting means running the MCP server process somewhere other than a single client’s machine, with a stable endpoint, identity on each request, access control, and audit. The process is usually simple to run. Most of the hosting work is the governance layer around it.

Should a hosted MCP server use stdio or HTTP?
HTTP, for anything shared. Stdio servers have no URL and serve one client per process. You can still host them centrally by putting a proxy in front and running them in a container, which the ToolHive Kubernetes Operator configures automatically.

Can MCP servers be hosted on Kubernetes?
Yes. With the ToolHive Kubernetes Operator, you declare each server as an MCPServer custom resource and deploy it through Helm and your existing GitOps pipeline. The Operator provisions a namespace-scoped ServiceAccount, Role, and RoleBinding for each server automatically.

How do users authenticate to a hosted MCP server?
Through your enterprise identity provider, using OIDC or OAuth 2.0, with the identity validated on every request. With Stacklok, the authorization server runs inside your cluster and federates to Okta, Microsoft Entra ID, or Google Workspace, so no credentials are stored on developer machines.

How do you stop one team from reaching another team’s tools?
Create separate vMCP endpoints, each gated by identity provider group membership and evaluated on every request. A request without the required group claim is rejected before it reaches any MCP server.

Can hosted MCP servers run in a VPC or on-prem with no SaaS dependency?
Yes. Stacklok is designed for private cloud and self-hosted deployment, and all of its components can run inside your own infrastructure. The one exception is connecting a cloud model provider through something like Anthropic MCP Tunnels, which requires an outbound connection to that provider.

Does a single hosted server need a gateway?
If one person is using one server that touches nothing sensitive, probably not. Once several people share a server or it reaches internal data, you need identity, segmentation, and audit, and a gateway is where those controls get enforced consistently.