Du skrev en MCP-server. Lokalt fungerar den bra — din agent anropar den, verktygen avfyras, allt är uppkopplat. Sedan stänger du din laptop och den är borta. Om du vill ha den servern nåbar närhelst din agent behöver den — från en annan maskin, från en kollegas uppsättning, från ett schemalagt jobb klockan 3 på natten — måste den leva någonstans som är always-on, med en stabil adress och HTTPS. Det är vad en VPS är till för.
Här är hur du flyttar din MCP-server från din laptop och till en box du faktiskt kontrollerar, med ärliga noteringar om var ansträngningen går.
Lokalt vs remote: vad "hosting" faktiskt betyder
MCP-servrar kommer i två former.
En stdio-server körs som en lokal process och pratar med en klient på samma maskin över standard input/output. Den är perfekt medan du bygger — men den kan inte nås av något över nätverket.
En remote-server talar HTTP (Server-Sent Events, eller det nyare streamable-HTTP-transportet) över en URL. Vilken klient som helst som känner till URL:en och har rätt uppgifter kan anropa den. Att hosta din egen MCP-server betyder att köra remote-typen någonstans publikt och stabilt.
Varför inte bara tunnla din laptop
Du kan tekniskt exponera en hemmamaskin med en tunnel, och för en snabb demo är det bra. För allt du förlitar dig på ärver du maskinens problem: den sover, din ISP roterar din IP, din uppladdning är långsam, och nu sitter en tjänst full av riktiga verktyg på ditt hemnätverk bredvid allt annat. En VPS ger dig en fast publik IP, en riktig domän, ordentlig drifttid, och isolering. För ett par dollar i månaden raderar det en hel kategori av "varför tappade min agent anslutningen"-frågor.
Stacken, konkret
Välj en liten box. En MCP-verktygsserver är mestadels I/O — den väntar på API:er, filer, och databaser; den gör ingen tung matematik. 1–2 GB RAM räcker gott för de flesta. (Att köra en modell inline för att svara är en annan historia — se att självhosta en LLM med Ollama.)
Kör din server bunden till localhost, säg Node eller Python som lyssnar på 127.0.0.1:3100. Håll den borta från det publika gränssnittet direkt — proxyn hanterar det.
Sätt en reverse proxy framför för att terminera TLS på din domän. Caddy gör det på ungefär fyra rader och hämtar automatiskt ett gratis certifikat:
mcp.yourdomain.com {
reverse_proxy 127.0.0.1:3100
}
Rikta mcp.yourdomain.com mot din VPS-IP, ladda om Caddy, och din server är live på https://mcp.yourdomain.com över streamable-HTTP.
Håll den always-on
En server som dör vid första kraschen eller omstarten är inte "hostad" — den är "körande för tillfället." Slå in den i en systemd-unit så att den startar om vid krasch och kommer tillbaka efter en omstart:
[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 och den är genuint always-on. (Samma mönster håller vilken agent eller bot som helst vid liv 24/7.)
Delen folk missar: du behöver en nåbar port
En publik MCP-endpoint behöver en inkommande port — 443 — nåbar från internet. På ett NAT-plan får du exakt en vidarebefordrad port för SSH och inget annat; du kan inte öppna 443 för världen. För att hosta en publik HTTPS-MCP-server vill du ha ett dedikerat-IP-plan, där varje port är din och du kan peka en domän rakt mot boxen. Det är skillnaden mellan "min agent på samma laptop kan nå den" och "vilken klient som helst var som helst kan."
Lås ner det — det är en API med privilegier
En MCP-server exponerar oftast verktyg som gör saker: läser filer, träffar betalda API:er, flyttar pengar. Sätt inte det naket på det öppna internet.
- Kräv en token vid varje anrop. Avvisa anonyma förfrågningar; kontrollera en bearer-token eller API-nyckel innan något verktyg körs.
- Brandväggsskydda allt utom 443 och din SSH-port.
- Nyckel-endast SSH, ingen lösenordsinloggning. (Här är tio-minuters-checklistan.)
Behandla endpointen som vad den är — en API med verklig auktoritet — och det mesta av risken försvinner.
De ärliga gränserna
- Du äger driften nu. OS-uppdateringar, att hålla processen frisk, att bevaka loggar. Caddy förnyar certifikatet åt dig, men resten är din. En managed cloud-funktion döljer detta; en VPS lämnar det till dig i utbyte mot kontroll och en mycket lägre räkning.
- MCP-specen är fortfarande i rörelse. Transport och auth-mönster ändras release till release. Pinna din SDK-version och förvänta dig att uppdatera den då och då.
- En CPU-box är rätt för verktygsservrar, inte för att generera svar med en lokal modell. Om din server kör en LLM för att svara är det en separat, tyngre maskin — se Ollama-guiden.
- Exponera aldrig destruktiva verktyg utan auth och ett bekräftelsesteg. Ett öppet verktyg som raderar saker kommer så småningom att möta en bot som skannar allt.
Att betala för det
Registrera dig med en e-post och betala i USDC eller USDT — inget kort, inget ID. Och om du kopplar upp detta för en agent, kan samma typ av box beställas och betalas programmatiskt via vår egen MCP-server — agenten registrerar, finansierar ett saldo, och beställer på egen hand.
Hosta servern en gång, och dina verktyg är där närhelst agenten sträcker sig efter dem.
Färdig uppsättning: se VPS för MCP-servrar — det rekommenderade planet och en en-minuts krypto-deploy.
Kommentarer
Inga kommentarer än. Bli först.