MCP Server Hosting: Self-Hosted and Managed Options

An MCP server is a process that exposes tools, data or actions to a connected AI app. Where that process runs determines who can reach it, how it authenticates callers, and how much work it takes to keep online. The choice ranges from a local process that only you can use to a cloud deployment shared across a team.

Most teams start with a local server for development and move to a remote deployment when they want to share it. Tools like fenbs are remote MCP servers — they run at a URL the whole team can connect to, each person authenticating with their own account. Understanding the tradeoffs helps you decide how to host your own servers and which hosted ones to trust.

Local servers (stdio)

A local MCP server runs on your machine as a subprocess. The MCP client (Claude Desktop, Cursor, etc.) launches it by command when you start the host app, communicates through standard input and output, and terminates it when the host closes. No network is involved.

Local servers are simple to set up and need no authentication beyond running as the current user. They're ideal for personal productivity tools, local file access, development utilities, and anything you're building yourself. The limitation is that only the person running the server on that machine can use it — the server is not accessible to teammates.

Local servers also depend on the machine staying available. If you want a colleague to use the same tool, they run their own copy on their own machine. That's fine for tools that are self-contained but impractical for tools that need shared state, like a project record.

Self-hosted remote servers

A self-hosted remote server runs on infrastructure you control: a VPS (virtual private server), a Docker container, a cloud virtual machine, or a home server with a public URL. It exposes an HTTP endpoint, and clients connect to it from anywhere.

Self-hosting gives you full control over the code, data, and configuration, which matters if your tools handle sensitive data. It also means you own the operational work: deploying updates, managing SSL certificates, monitoring uptime, and handling authentication. For small teams building internal tools, this is often the right tradeoff.

Common self-hosting platforms for MCP servers include DigitalOcean Droplets, Linode/Akamai, AWS EC2, Google Cloud Compute Engine, and Azure Virtual Machines. Container-based deployments on Fly.io or Railway are increasingly popular because they handle much of the infrastructure work while still giving you control over the code.

Serverless deployments

Serverless platforms — Vercel, Cloudflare Workers, AWS Lambda, Netlify Functions — run your server code on demand rather than on a persistent process. Each incoming request may run in a fresh worker instance. This is cost-effective for low-traffic tools and scales automatically under load.

The constraint is that a serverless function has no persistent in-memory state between requests. An MCP server that stores session data in memory won't work correctly serverless — each request starts fresh. If the server stores state externally (in a database, key-value store, or similar), serverless works fine.

fenbs runs serverless on Vercel. Requests are stateless; the persistent data lives in the underlying API database. This means any connected AI app gets the same up-to-date record regardless of which Vercel instance handles the request.

What to check when evaluating a hosting provider

Before choosing a platform for a shared MCP server, run through these questions:

• Authentication: does the platform support the OAuth 2.1 flow the MCP spec requires for remote servers, or will you need to add it yourself?
• Persistence: if your server needs to store state, does the platform give you a database or key-value store, or do you need to bring your own?
• Latency: for tools called mid-conversation, a slow server makes every interaction feel sluggish. Check the platform's region options against where your users are.
• Reliability: what is the platform's uptime commitment? A downed MCP server means the AI can't access the tools it needs.
• Data residency: if your server handles data subject to GDPR, HIPAA, or similar regulations, check where the platform stores and processes data.
• Secrets management: API keys, database passwords, and OAuth secrets shouldn't be in the code. Does the platform offer environment variables or a secrets store?

Managed MCP providers

Some MCP servers are offered as managed services — you connect to them rather than hosting them yourself. Cloud providers including AWS and Azure now offer MCP servers for their own services: see the AWS MCP server and Azure MCP server guides for details. Third-party tools like fenbs and many others in the MCP server directory are also managed.

Managed servers handle hosting, uptime, updates and authentication infrastructure. The tradeoff is that you're trusting the provider with the data your requests contain. Review the provider's privacy policy and terms of service before connecting any server to tools that handle sensitive information.

How to do this with fenbs

1. Create a free account and add a project for the infrastructure work.
2. Record the team's hosting decision as a Decision in fenbs: the platform chosen, the reason, who is responsible, and the key operational rules.
3. Connect your AI apps to fenbs via Integrations. At the start of infrastructure work, ask your AI to read the project context so it knows the agreed hosting setup before it suggests changes.
4. When a hosting rule changes — a new region, a new provider, an updated process — update the Decision in fenbs so future sessions apply the current standard.

For related topics, see MCP server architecture to understand how the host, client and server roles divide responsibility, and MCP server configuration for the client-side config that points your AI apps at a hosted server.