EQVPS
Inizia

Ospita il tuo server MCP su un VPS

5 lug 2026 · 5 min di lettura · EQVPS Team

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.

Tratta l'endpoint per ciò che è — un'API con autorità reale — e gran parte del rischio sparisce.

I limiti onesti

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.

FAQ

Mi serve un IP dedicato per ospitare un server MCP?

Per un endpoint HTTPS pubblico, sì. I piani NAT inoltrano una sola porta SSH e non esporranno la porta 443 a internet. Un piano con IP dedicato ti dà ogni porta e un dominio che puoi puntare direttamente alla macchina.

stdio o HTTP — quale trasporto ospito?

HTTP (SSE o il più recente streamable-HTTP). Un server stdio parla solo con un client sulla stessa macchina; qualsiasi cosa tu voglia raggiungibile in rete deve parlare HTTP dietro un URL.

Un solo VPS può far girare più server MCP?

Sì. Lega ciascun server a una porta locale diversa e dai a ciascuno il proprio sottodominio nel reverse proxy. La RAM è il limite pratico, e i server di tool ne usano pochissima.

Quanta RAM serve a un server MCP?

Di solito poca. Un server di tool è I/O-bound — aspetta API e database invece di macinare numeri, quindi 1–2 GB bastano per la maggior parte. Far girare un modello per generare le risposte è un lavoro separato, molto più pesante.

← Torna al blogVedi piani e prezzi →

Commenti

Ancora nessun commento. Sii il primo.

Lascia un commento

I commenti sono moderati prima di comparire.