Hai scritto un server MCP. In locale funziona bene — il tuo agente lo chiama, i tool scattano, è tutto collegato. Poi chiudi il laptop e se n'è andato. Se vuoi che quel server sia raggiungibile ogni volta che il tuo agente ne ha bisogno — da un'altra macchina, dal setup di un collega, da un job pianificato alle 3 di notte — deve vivere da qualche parte che è sempre attiva, con un indirizzo stabile e HTTPS. È a questo che serve un VPS.
Ecco come spostare il tuo server MCP dal laptop a una macchina che controlli davvero, con note oneste su dove va lo sforzo.
Locale vs remoto: cosa significa davvero "ospitare"
I server MCP arrivano in due forme.
Un server stdio gira come processo locale e parla con un client sulla stessa macchina tramite standard input/output. È perfetto mentre stai costruendo — ma non può essere raggiunto da nulla attraverso la rete.
Un server remoto parla HTTP (Server-Sent Events, o il più recente trasporto streamable-HTTP) su un URL. Qualsiasi client che conosce l'URL e possiede le credenziali giuste può chiamarlo. Ospitare il tuo server MCP significa far girare il tipo remoto da qualche parte pubblica e stabile.
Perché non fare semplicemente un tunnel dal laptop
Puoi tecnicamente esporre una macchina di casa con un tunnel, e per una demo veloce va bene. Per qualsiasi cosa su cui fai affidamento, erediti i problemi della macchina: va in sospensione, il tuo ISP ruota il tuo IP, il tuo upload è lento, e ora un servizio pieno di tool reali sta sulla tua rete domestica accanto a tutto il resto. Un VPS ti dà un IP pubblico fisso, un dominio reale, uptime adeguato e isolamento. Per un paio di dollari al mese cancella un'intera categoria di domande "perché il mio agente ha perso la connessione".
Lo stack, concretamente
Scegli una piccola macchina. Un server di tool MCP è per lo più I/O — aspetta API, file e database; non fa calcoli pesanti. 1–2 GB di RAM bastano e avanzano per la maggior parte. (Far girare un modello inline per rispondere è un'altra storia — vedi self-hosting di un LLM con Ollama.)
Esegui il tuo server legato a localhost, per esempio Node o Python in ascolto su 127.0.0.1:3100. Tienilo fuori dall'interfaccia pubblica direttamente — il proxy gestisce quello.
Metti un reverse proxy davanti per terminare il TLS sul tuo dominio. Caddy lo fa in circa quattro righe e recupera automaticamente un certificato gratuito:
mcp.yourdomain.com {
reverse_proxy 127.0.0.1:3100
}
Punta mcp.yourdomain.com all'IP del tuo VPS, ricarica Caddy, e il tuo server è live su https://mcp.yourdomain.com in streamable-HTTP.
Tienilo sempre attivo
Un server che muore al primo crash o riavvio non è "ospitato" — è "in funzione per ora". Avvolgilo in una unit systemd così si riavvia in caso di crash e torna dopo un riavvio:
[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 ed è genuinamente sempre attivo. (Lo stesso schema tiene qualsiasi agente o bot vivo 24/7.)
La parte che la gente si perde: ti serve una porta raggiungibile
Un endpoint MCP pubblico ha bisogno di una porta in entrata — la 443 — raggiungibile da internet. Su un piano NAT ottieni esattamente una porta inoltrata per SSH e nient'altro; non puoi aprire la 443 al mondo. Per ospitare un server MCP HTTPS pubblico vuoi un piano con IP dedicato, dove ogni porta è tua e puoi puntare un dominio direttamente alla macchina. È la differenza tra "il mio agente sullo stesso laptop può raggiungerlo" e "qualsiasi client ovunque può".
Blindalo — è un'API con privilegi
Un server MCP di solito espone tool che fanno cose: leggono file, colpiscono API a pagamento, muovono denaro. Non metterlo nudo su internet aperto.
- Richiedi un token a ogni chiamata. Rifiuta le richieste anonime; verifica un bearer token o una chiave API prima che qualsiasi tool giri.
- Firewall tutto tranne la 443 e la tua porta SSH.
- SSH solo-chiavi, nessun login con password. (Ecco la checklist di dieci minuti.)
Tratta l'endpoint per ciò che è — un'API con autorità reale — e gran parte del rischio sparisce.
I limiti onesti
- Ora l'ops è tua. Aggiornamenti dell'OS, tenere il processo in salute, guardare i log. Caddy rinnova il certificato per te, ma il resto è tuo. Una cloud function gestita nasconde questo; un VPS te lo consegna in cambio di controllo e un conto molto più basso.
- La spec MCP è ancora in movimento. Trasporti e pattern di auth cambiano di release in release. Fissa la versione del tuo SDK e aspettati di aggiornarla di tanto in tanto.
- Una macchina CPU è giusta per i server di tool, non per generare risposte con un modello locale. Se il tuo server esegue un LLM per rispondere, quella è una macchina separata e più pesante — vedi la guida a Ollama.
- Non esporre mai tool distruttivi senza auth e un passo di conferma. Un tool aperto che cancella cose incontrerà prima o poi un bot che scandaglia tutto.
Pagarlo
Registrati con un'email e paga in USDC o USDT — niente carta, niente ID. E se stai cablando questo per un agente, lo stesso tipo di macchina può essere ordinato e pagato in modo programmatico tramite il nostro server MCP — l'agente si registra, finanzia un saldo e ordina da solo.
Ospita il server una volta, e i tuoi tool sono lì ogni volta che l'agente li cerca.
Configurazione pronta: vedi VPS per server MCP — il piano consigliato e un deploy in crypto di un minuto.
Commenti
Ancora nessun commento. Sii il primo.