Ai scris un server MCP. Local merge bine — agentul tău îl apelează, uneltele se declanșează, totul e legat. Apoi închizi laptopul și a dispărut. Dacă vrei ca serverul să fie accesibil oricând are agentul nevoie de el — de pe altă mașină, din configurarea unui coleg, dintr-o sarcină programată la 3 dimineața —, trebuie să trăiască undeva mereu pornit, cu o adresă stabilă și HTTPS. Pentru asta e un VPS.
Iată cum îți muți serverul MCP de pe laptop pe o mașină pe care chiar o controlezi, cu note cinstite despre unde se duce efortul.
Local vs la distanță: ce înseamnă de fapt „găzduirea”
Serverele MCP vin în două forme.
Un server stdio rulează ca proces local și vorbește cu un client de pe aceeași mașină prin intrarea/ieșirea standard. E perfect cât construiești — dar nimic nu ajunge la el prin rețea.
Un server la distanță vorbește HTTP (Server-Sent Events sau noul transport streamable-HTTP), printr-un URL. Orice client care știe URL-ul și are datele de acces potrivite îl poate apela. A-ți găzdui propriul server MCP înseamnă să rulezi tipul la distanță undeva public și stabil.
De ce să nu faci pur și simplu un tunel spre laptop
Tehnic poți expune o mașină de acasă cu un tunel, iar pentru o demonstrație rapidă e în regulă. Pentru orice pe care te bazezi, moștenești problemele mașinii: intră în repaus, furnizorul de internet îți rotește IP-ul, uploadul e lent, iar acum un serviciu plin de unelte reale stă în rețeaua de acasă, lângă tot restul. Un VPS îți dă un IP public fix, un domeniu real, disponibilitate cum trebuie și izolare. Pentru câțiva dolari pe lună, șterge o categorie întreagă de întrebări de tipul „de ce și-a pierdut agentul conexiunea”.
Stackul, concret
Alege o mașină mică. Un server MCP de unelte e mai ales I/O — așteaptă după API-uri, fișiere și baze de date; nu face matematică grea. 1–2 GB de RAM ajung din plin pentru majoritatea. (Rularea unui model direct ca să răspundă e altă poveste — vezi găzduirea unui LLM cu Ollama.)
Rulează serverul legat de localhost, de exemplu Node sau Python ascultând pe 127.0.0.1:3100. Ține-l departe de interfața publică — de asta se ocupă proxy-ul.
Pune în față un reverse proxy care termină TLS pe domeniul tău. Caddy o face în aproximativ patru rânduri și obține automat un certificat gratuit:
mcp.yourdomain.com {
reverse_proxy 127.0.0.1:3100
}
Îndreaptă mcp.yourdomain.com spre IP-ul VPS-ului, reîncarcă Caddy, iar serverul tău e online la https://mcp.yourdomain.com, prin streamable-HTTP.
Ține-l mereu pornit
Un server care moare la prima cădere sau repornire nu e „găzduit” — e „pornit deocamdată”. Pune-l într-o unitate systemd, ca să repornească după căderi și să revină după o repornire:
[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 și e cu adevărat mereu pornit. (Același tipar ține orice agent sau bot în viață 24/7.)
Partea pe care oamenii o ratează: ai nevoie de un port accesibil
Un endpoint MCP public are nevoie de un port de intrare — 443 — accesibil de pe internet. Pe un plan NAT primești exact un port redirecționat pentru SSH și nimic altceva; nu poți deschide 443 spre lume. Ca să găzduiești un server MCP public prin HTTPS, vrei un plan cu IP dedicat, unde fiecare port e al tău și poți îndrepta un domeniu direct spre mașină. Asta e diferența dintre „agentul de pe același laptop ajunge la el” și „orice client de oriunde ajunge la el”.
Închide-l bine — e un API cu privilegii
Un server MCP expune de obicei unelte care fac lucruri: citesc fișiere, apelează API-uri plătite, mută bani. Nu pune așa ceva gol pe internetul deschis.
- Cere un token la fiecare apel. Respinge cererile anonime; verifică un bearer token sau o cheie API înainte să ruleze orice unealtă.
- Pune după firewall tot, în afară de 443 și portul tău SSH.
- SSH doar cu chei, fără autentificare cu parolă. (Iată lista de zece minute.)
Tratează endpointul ca ce e — un API cu autoritate reală — și cea mai mare parte a riscului dispare.
Limitele cinstite
- Operațiunile sunt acum ale tale. Actualizările sistemului, sănătatea procesului, urmărirea logurilor. Caddy îți reînnoiește singur certificatul, dar restul e al tău. O funcție administrată din cloud ascunde asta; un VPS ți-o dă ție, în schimbul controlului și al unei facturi mult mai mici.
- Specificația MCP încă se mișcă. Transporturile și tiparele de autentificare se schimbă de la o versiune la alta. Fixează versiunea SDK-ului și așteaptă-te să o actualizezi din când în când.
- O mașină cu CPU e potrivită pentru servere de unelte, nu pentru generarea răspunsurilor cu un model local. Dacă serverul tău rulează un LLM ca să răspundă, aia e altă mașină, mai grea — vezi ghidul Ollama.
- Nu expune niciodată unelte distructive fără autentificare și un pas de confirmare. O unealtă deschisă care șterge lucruri va da până la urmă peste un bot care scanează tot.
Plata
Te înregistrezi cu un e-mail și plătești în USDC sau USDT — fără card, fără act de identitate. Iar dacă legi asta pentru un agent, același fel de mașină poate fi comandat și plătit programatic prin propriul nostru server MCP — agentul se înregistrează, alimentează un sold și comandă singur.
Găzduiește serverul o dată, iar uneltele tale sunt acolo ori de câte ori agentul întinde mâna după ele.
Configurare gata făcută: vezi VPS pentru servere MCP — planul recomandat și un deploy cripto de un minut.
Comentarii
Încă nu există comentarii. Fii primul.