How to Host an MCP Server

You wrote an MCP server. It exposes a few tools, an agent on your machine calls them, and it works. Then you try to use it from somewhere else, or from a teammate’s agent, or from a production workflow, and it does not work, because it only exists on your laptop and your laptop is not a server.

That is the whole problem. An MCP server is only useful when it is running somewhere an agent can actually reach, at a URL that does not change, without you keeping a terminal open. Hosting it is how you get there.

What hosting an MCP server actually requires

People overcomplicate this. An MCP server is a normal long-running program that speaks the Model Context Protocol over HTTP. Hosting it well comes down to four things.

A stable public URL, so an agent can find it tomorrow at the same address it found it today. Always-on uptime, so it answers whether or not your machine is awake. Authentication, so only your agents call your tools and not the whole internet. And room to scale, because the day two agents call it at once is the day a single process becomes a bottleneck.

Get those four right and you have a real MCP server. Everything else is detail.

Your options

You can host it yourself on a plain virtual machine. Rent a box, install your runtime, run the server behind a reverse proxy, add TLS, set up a process manager so it restarts on crash, and handle auth yourself. Total control, and total maintenance. You now own an operating system.

You can reach for serverless functions, but most MCP servers hold a connection open and keep some state across calls, which fights the request-and-forget model that functions are built for. It can work for the simplest tools and gets awkward past that.

Or you deploy it as a managed container service, which is the natural shape for a long-running server. You hand over an image, you get back a URL that stays up and scales, and you skip the operating system entirely. That is the path below.

Deploying on Scalix Run

Scalix Run runs long-running container services with a URL, autoscaling, revisions, and rollback. An MCP server is exactly that shape, so the deploy is short.

Build your server into a container image and push it to the registry, then deploy it:

scalix-cloud run deploy --name mcp-server \
  --image registry.scalix.world/my-org/mcp-server:v1 \
  --port 8080 \
  --min-instances 1

If you would rather deploy from source than build the image yourself, push your code to a Git repository and let the build service detect the runtime from your package.json, requirements.txt, go.mod, Cargo.toml, or Dockerfile, then produce the image for you.

That gives you the stable URL and the uptime. For authentication, put your server behind an API key so only your agents can call it, the same way every other request to the platform is authorized:

curl https://mcp-server.run.scalix.world/ \
  -H "Authorization: Bearer $SCALIX_API_KEY"

Scaling is a setting, not a project. Give it a floor and a ceiling and a target, and it adds instances when agents show up and removes them when they leave:

scalix-cloud run deploy --name mcp-server \
  --image registry.scalix.world/my-org/mcp-server:v1 \
  --port 8080 \
  --min-instances 1 --max-instances 10

Every deploy is a revision, so if a change misbehaves you roll back to the last good one in one command:

scalix-cloud run rollback <service-id>

The part most guides skip

Once your MCP server is hosted, it is a service like any other, which means it needs the same things your app needs. A database for the state your tools read and write. Object storage for files. Maybe a scheduled job to refresh something on an interval. On most stacks that is three more vendors, three more bills, and three more sets of credentials for your agent to juggle.

On Scalix it is one platform and one key. Your MCP server, its database, its storage, and its functions live behind a single API key, and that same key is what an agent uses to operate all of it. You host the server your agent calls, on the cloud your agent can also run. That is the point of building it as one system instead of gluing five together.

Start on the free tier, deploy your server, and point your agent at the URL. If you want to see a hosted MCP server’s client configs before writing your own, ours are public at scalixworld/scalix-cloud-mcp.