The three ways to run a server
Local: the server runs as a process on the same machine as the client, launched on demand over stdio. This is how most MCP servers are used today, and for a single developer it is the simplest option — nothing to deploy, nothing exposed to the network.
Self-hosted remote: you run the server on your own infrastructure and clients reach it over HTTP. This makes sense when a team needs to share one server, or when the server needs to sit close to data that lives in your environment.
Managed remote: a vendor hosts the server and you connect to their endpoint, usually with OAuth. You trade control for not having to operate anything — the vendor handles uptime, updates and scaling.
When local is enough
If you are one person connecting a server to your own client, run it locally. Deploying a server to shared infrastructure to solve a single-user problem adds an attack surface, an uptime obligation and a maintenance burden for no benefit.
Local also keeps credentials on your machine rather than on a server others can reach, which for something like a filesystem or database server is a meaningful security advantage. The limit is simply that a local server is only available to that machine — nobody else can use it, and it is not running when your laptop is closed.
When to self-host a remote server
Self-hosting becomes worthwhile when multiple people or agents need the same server, or when the server must run somewhere specific — inside your network, next to a database, on a schedule independent of any laptop.
It comes with the responsibilities of any service you expose: authentication so that only authorized clients can connect, transport security so traffic is encrypted, and monitoring so you notice when it breaks. A remote MCP server with no auth in front of it is an open door to whatever it can do, which for a server holding real credentials is a serious risk. Our guide to MCP security red lines covers what not to skip.
When managed hosting makes sense
Managed hosting is the right call when the server is offered as a product by the vendor whose system it talks to — a SaaS company's official MCP server, hosted by them. You get first-party maintenance and no operational load, at the cost of routing your access through their infrastructure.
The trade-off to weigh is trust and data flow: a managed server sees the requests you send it, so for sensitive data you may prefer to self-host even when a managed option exists. For connecting to a vendor's own service you were already using, managed hosting usually adds no new exposure and saves real effort.
If your client only speaks stdio and the server is remote, you may need a bridge to connect the two — our guide to mcp-remote covers that case.