Self-hosted vs managed MCP servers: which to choose
What running your own MCP server really involves, what managed MCP server hosting takes off your hands, and when each one is the right choice.
In this post
- What a production MCP server needs
- Self-hosted and managed, side by side
- When to self-host, and when not to
An MCP server that runs on your laptop is a few dozen lines with an SDK. An MCP server that your team or your customers connect to from Claude, ChatGPT or Cursor is infrastructure. Choosing between hosting it yourself and managed MCP server hosting comes down to who runs that infrastructure.
What a remote MCP server needs#
- A public HTTPS endpoint that speaks Streamable HTTP
- OAuth 2.1 sign-in, with the discovery and client registration MCP clients expect
- Secrets for every API and database the tools call, kept away from the model and the client
- Network rules, so a tool reaches only the hosts it should
- Deploys, rollbacks and tests before a change goes live
- Scaling, time limits and a record of every call
None of this is specific to MCP, but all of it has to be right before a remote server is safe to share.
Self-hosted MCP servers#
Self-hosting means running the server on your own machines, containers or cloud account. You control the runtime, the network and where data sits. You also own every item on the list above, and keep owning it as the MCP spec and its clients change.
- Full control over runtime, network and data location
- Can run inside a private network, next to internal systems
- You build and maintain sign-in, secrets, deploys, scaling and monitoring
Managed MCP server hosting#
With managed hosting, a platform runs the MCP infrastructure and you bring the tools. On Glxymesh you push a project of tools; the platform builds and tests it, runs it in the project's own AWS Lambda, and serves it from one endpoint with OAuth already in place.
- One authenticated endpoint per project, ready for Claude, ChatGPT, Cursor and VS Code
- Encrypted project secrets added to outbound requests at the egress gateway, so tool code never holds them
- Outbound calls only to the hosts each tool lists, with a person approving new ones
- Every call recorded with its outcome and timing in the console
Side by side#
| Job | Self-hosted · Managed |
|---|---|
| Endpoint and TLS | You run them · One HTTPS endpoint per project |
| Sign-in | You implement OAuth 2.1 · The gateway handles it |
| Secrets | Your vault and code · Encrypted, added at egress |
| Deploys | Your CI/CD · gxmesh push, tested before it goes live |
| Scaling | You size and scale · Lambda scales per call |
| Private networks | Native · Only hosts the egress gateway can reach |
When to choose each#
Self-host when the server has to run where the data lives: on a person's own machine over stdio, inside a private network with no public route, or under rules that keep all compute on your own hardware.
Choose managed MCP server hosting when the server's job is to call APIs and databases for AI clients, and you would rather spend your time on tools than on OAuth, secrets and deploys. Most teams wrapping SaaS APIs, internal HTTP services or a reachable database are in this group.
New to MCP? Start with what the Model Context Protocol is. Ready to try managed hosting? The MCP server tutorial deploys one in about ten minutes, and the pricing page lists what the free plan includes.
