EQVPS

Hosta din egen MCP-server på en VPS

5 juli 2026 · 4 min läsning · EQVPS Team

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.

Behandla endpointen som vad den är — en API med verklig auktoritet — och det mesta av risken försvinner.

De ärliga gränserna

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.

FAQ

Behöver jag en dedikerad IP för att hosta en MCP-server?

För en publik HTTPS-endpoint, ja. NAT-planer vidarebefordrar en enda SSH-port och exponerar inte port 443 för internet. Ett dedikerat-IP-plan ger dig varje port och en domän du kan peka rakt mot boxen.

stdio eller HTTP — vilket transport hostar jag?

HTTP (SSE eller det nyare streamable-HTTP). En stdio-server pratar bara med en klient på samma maskin; allt du vill ha nåbart över nätverket måste tala HTTP bakom en URL.

Kan en VPS köra flera MCP-servrar?

Ja. Bind varje server till en annan lokal port och ge var och en sin egen subdomän i reverse proxyn. RAM är den praktiska gränsen, och verktygsservrar använder väldigt lite av det.

Hur mycket RAM behöver en MCP-server?

Oftast lite. En verktygsserver är I/O-bunden — den väntar på API:er och databaser snarare än att knäcka siffror, så 1–2 GB klarar de flesta. Att köra en modell för att generera svaren är ett separat, mycket tyngre jobb.

← Tillbaka till bloggenSe planer & priser →

Kommentarer

Inga kommentarer än. Bli först.

Lämna en kommentar

Kommentarer modereras innan de visas.