Je schreef een MCP-server. Lokaal werkt hij prima — je agent roept hem aan, de tools vuren, alles is aangesloten. Dan sluit je je laptop en is hij weg. Als je die server bereikbaar wilt wanneer je agent hem nodig heeft — vanaf een andere machine, vanaf de opstelling van een teamgenoot, vanaf een geplande job om 3 uur 's nachts — moet hij ergens leven dat always-on is, met een stabiel adres en HTTPS. Daar is een VPS voor.
Hier is hoe je je MCP-server van je laptop naar een box verplaatst die je daadwerkelijk beheert, met eerlijke opmerkingen over waar de inspanning heen gaat.
Lokaal vs remote: wat "hosten" eigenlijk betekent
MCP-servers komen in twee vormen.
Een stdio-server draait als een lokaal proces en praat met een client op dezelfde machine via standard input/output. Het is perfect terwijl je bouwt — maar het kan niet bereikt worden door iets over het netwerk.
Een remote-server spreekt HTTP (Server-Sent Events, of het nieuwere streamable-HTTP-transport) over een URL. Elke client die de URL kent en de juiste inloggegevens heeft kan hem aanroepen. Je eigen MCP-server hosten betekent de remote soort ergens publiek en stabiel draaien.
Waarom niet gewoon je laptop tunnelen
Je kunt technisch een thuismachine blootstellen met een tunnel, en voor een snelle demo is dat prima. Voor alles waar je op vertrouwt, erf je de problemen van de machine: hij slaapt, je ISP roteert je IP, je upload is traag, en nu zit een service vol echte tools op je thuisnetwerk naast al het andere. Een VPS geeft je een vast publiek IP, een echt domein, goede uptime, en isolatie. Voor een paar dollar per maand verwijdert het een hele categorie "waarom verloor mijn agent de verbinding"-vragen.
De stack, concreet
Kies een kleine box. Een MCP-tool-server is grotendeels I/O — hij wacht op API's, bestanden en databases; hij doet geen zware wiskunde. 1–2 GB RAM is ruim voldoende voor de meeste. (Een model inline draaien om te antwoorden is een ander verhaal — zie een LLM zelf hosten met Ollama.)
Draai je server gebonden aan localhost, zeg Node of Python luisterend op 127.0.0.1:3100. Houd het rechtstreeks van de publieke interface af — de proxy handelt dat af.
Zet een reverse proxy ervoor om TLS op je domein te termineren. Caddy doet het in ongeveer vier regels en haalt automatisch een gratis certificaat:
mcp.yourdomain.com {
reverse_proxy 127.0.0.1:3100
}
Richt mcp.yourdomain.com op je VPS-IP, herlaad Caddy, en je server is live op https://mcp.yourdomain.com via streamable-HTTP.
Houd het always-on
Een server die sterft bij de eerste crash of herstart is niet "gehost" — het is "voorlopig draaiend." Wikkel het in een systemd-unit zodat het herstart bij een crash en terugkomt na een herstart:
[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 en het is echt always-on. (Hetzelfde patroon houdt elke agent of bot 24/7 in leven.)
Het deel dat mensen missen: je hebt een bereikbare poort nodig
Een publiek MCP-endpoint heeft een inkomende poort nodig — 443 — bereikbaar vanaf het internet. Op een NAT-plan krijg je precies één doorgestuurde poort voor SSH en niets anders; je kunt 443 niet openen voor de wereld. Om een publieke HTTPS MCP-server te hosten wil je een dedicated-IP-plan, waar elke poort van jou is en je een domein rechtstreeks naar de box kunt richten. Dat is het verschil tussen "mijn agent op dezelfde laptop kan hem bereiken" en "elke client waar dan ook kan."
Vergrendel het — het is een API met privileges
Een MCP-server stelt meestal tools bloot die dingen doen: bestanden lezen, betaalde API's raken, geld verplaatsen. Zet dat niet naakt op het open internet.
- Vereis een token op elke aanroep. Weiger anonieme requests; controleer een bearer-token of API-sleutel voordat een tool draait.
- Firewall alles behalve 443 en je SSH-poort.
- Alleen keys-SSH, geen wachtwoord-login. (Hier is de tien-minuten-checklist.)
Behandel het endpoint als wat het is — een API met echte autoriteit — en het meeste van het risico verdwijnt.
De eerlijke grenzen
- Je bezit nu de ops. OS-updates, het proces gezond houden, logs bekijken. Caddy verlengt het certificaat voor je, maar de rest is van jou. Een managed cloud-functie verbergt dit; een VPS geeft het je in ruil voor controle en een veel lagere rekening.
- De MCP-spec is nog in beweging. Transporten en auth-patronen veranderen van release tot release. Pin je SDK-versie en verwacht het af en toe bij te werken.
- Een CPU-box is juist voor tool-servers, niet voor het genereren van antwoorden met een lokaal model. Als je server een LLM draait om te antwoorden, is dat een aparte, zwaardere machine — zie de Ollama-gids.
- Stel destructieve tools nooit bloot zonder auth en een bevestigingsstap. Een open tool die dingen verwijdert zal uiteindelijk een bot ontmoeten die alles scant.
Ervoor betalen
Meld je aan met een e-mail en betaal in USDC of USDT — geen kaart, geen ID. En als je dit voor een agent aansluit, kan hetzelfde soort box programmatisch worden besteld en betaald via onze eigen MCP-server — de agent registreert, financiert een saldo, en bestelt op eigen kracht.
Host de server één keer, en je tools zijn er wanneer de agent ernaar reikt.
Kant-en-klare setup: zie VPS voor MCP-servers — het aanbevolen plan en een crypto-deploy van één minuut.
Reacties
Nog geen reacties. Wees de eerste.