Do I need a dedicated IP to host an MCP server?

For a public HTTPS endpoint, yes. NAT plans forward a single SSH port and won't expose port 443 to the internet. A dedicated-IP plan gives you every port and a domain you can point straight at the box.

stdio or HTTP — which transport do I host?

HTTP (SSE or the newer streamable-HTTP). A stdio server only talks to a client on the same machine; anything you want reachable over the network has to speak HTTP behind a URL.

Can one VPS run several MCP servers?

Yes. Bind each server to a different local port and give each its own subdomain in the reverse proxy. RAM is the practical limit, and tool servers use very little of it.

How much RAM does an MCP server need?

Usually little. A tool server is I/O-bound — it waits on APIs and databases rather than crunching numbers, so 1–2 GB handles most. Running a model to generate the answers is a separate, much heavier job.

Host your own MCP server on a VPS

You wrote an MCP server. Locally it works fine — your agent calls it, the tools fire, everything's wired up. Then you close your laptop and it's gone. If you want that server reachable whenever your agent needs it — from another machine, from a teammate's setup, from a scheduled job at 3am — it has to live somewhere that's always on, with a stable address and HTTPS. That's what a VPS is for.

Here's how to move your MCP server off your laptop and onto a box you actually control, with honest notes on where the effort goes.

Local vs remote: what "hosting" actually means

MCP servers come in two shapes.

A stdio server runs as a local process and talks to a client on the same machine over standard input/output. It's perfect while you're building — but it can't be reached by anything across the network.

A remote server speaks HTTP (Server-Sent Events, or the newer streamable-HTTP transport) over a URL. Any client that knows the URL and holds the right credentials can call it. To host your own MCP server means running the remote kind somewhere public and stable.

Why not just tunnel your laptop

You can technically expose a home machine with a tunnel, and for a quick demo that's fine. For anything you rely on, you inherit the machine's problems: it sleeps, your ISP rotates your IP, your upload is slow, and now a service full of real tools is sitting on your home network next to everything else. A VPS gives you a fixed public IP, a real domain, proper uptime, and isolation. For a couple of dollars a month it deletes a whole category of "why did my agent lose the connection" questions.

The stack, concretely

Pick a small box. An MCP tool server is mostly I/O — it waits on APIs, files, and databases; it doesn't do heavy math. 1–2 GB of RAM is plenty for most. (Running a model inline to answer is a different story — see self-hosting an LLM with Ollama.)

Run your server bound to localhost, say Node or Python listening on 127.0.0.1:3100. Keep it off the public interface directly — the proxy handles that.

Put a reverse proxy in front to terminate TLS on your domain. Caddy does it in about four lines and fetches a free certificate automatically:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

Point mcp.yourdomain.com at your VPS IP, reload Caddy, and your server is live at https://mcp.yourdomain.com over streamable-HTTP.

Keep it always on

A server that dies on the first crash or reboot isn't "hosted" — it's "running for now." Wrap it in a systemd unit so it restarts on crash and comes back after a reboot:

[Unit]
Description=My MCP server
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/mcp/server.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

systemctl enable --now my-mcp and it's genuinely always on. (The same pattern keeps any agent or bot alive 24/7.)

The part people miss: you need a reachable port

A public MCP endpoint needs an inbound port — 443 — reachable from the internet. On a NAT plan you get exactly one forwarded port for SSH and nothing else; you can't open 443 to the world. To host a public HTTPS MCP server you want a dedicated-IP plan, where every port is yours and you can point a domain straight at the box. That's the difference between "my agent on the same laptop can reach it" and "any client anywhere can."

Lock it down — it's an API with privileges

An MCP server usually exposes tools that do things: read files, hit paid APIs, move money. Don't put that on the open internet naked.

Require a token on every call. Reject anonymous requests; check a bearer token or API key before any tool runs.
Firewall everything except 443 and your SSH port.
Keys-only SSH, no password login. (Here's the ten-minute checklist.)

Treat the endpoint like what it is — an API with real authority — and most of the risk goes away.

The honest limits

You own the ops now. OS updates, keeping the process healthy, watching logs. Caddy renews the cert for you, but the rest is yours. A managed cloud function hides this; a VPS hands it to you in exchange for control and a much lower bill.
The MCP spec is still moving. Transports and auth patterns change release to release. Pin your SDK version and expect to update it now and then.
A CPU box is right for tool servers, not for generating answers with a local model. If your server runs an LLM to respond, that's a separate, heavier machine — see the Ollama guide.
Never expose destructive tools without auth and a confirmation step. An open tool that deletes things will eventually meet a bot that scans everything.

Paying for it

Sign up with an email and pay in USDC or USDT — no card, no ID. And if you're wiring this up for an agent, the same kind of box can be ordered and paid for programmatically over our own MCP server — the agent registers, funds a balance, and orders on its own.

Host the server once, and your tools are there whenever the agent reaches for them.