Ai-je besoin d'une IP dédiée pour héberger un serveur MCP ?

Pour un point de terminaison HTTPS public, oui. Les plans NAT redirigent un unique port SSH et n'exposent pas le port 443 vers Internet. Un plan à IP dédiée vous donne tous les ports et un domaine que vous pouvez pointer directement sur la machine.

stdio ou HTTP — quel transport héberger ?

HTTP (SSE ou le plus récent streamable-HTTP). Un serveur stdio ne parle qu'à un client sur la même machine ; tout ce que vous voulez joignable par le réseau doit parler HTTP derrière une URL.

Un seul VPS peut-il faire tourner plusieurs serveurs MCP ?

Oui. Liez chaque serveur à un port local différent et donnez à chacun son propre sous-domaine dans le reverse proxy. La RAM est la limite pratique, et les serveurs d'outils en utilisent très peu.

De combien de RAM un serveur MCP a-t-il besoin ?

Habituellement peu. Un serveur d'outils est limité par les I/O — il attend des API et des bases de données plutôt que de mouliner des nombres, donc 1–2 Go suffisent pour la plupart. Faire tourner un modèle pour générer les réponses est un travail séparé, bien plus lourd.

Hébergez votre propre serveur MCP sur un VPS

Vous avez écrit un serveur MCP. En local il marche bien — votre agent l'appelle, les outils se déclenchent, tout est câblé. Puis vous fermez votre portable et il disparaît. Si vous voulez ce serveur joignable dès que votre agent en a besoin — depuis une autre machine, depuis la configuration d'un coéquipier, depuis une tâche planifiée à 3 h du matin — il doit vivre quelque part qui est toujours en marche, avec une adresse stable et du HTTPS. C'est à ça que sert un VPS.

Voici comment sortir votre serveur MCP de votre portable et le poser sur une machine que vous contrôlez vraiment, avec des notes honnêtes sur où part l'effort.

Local vs distant : ce qu'« héberger » veut vraiment dire

Les serveurs MCP viennent sous deux formes.

Un serveur stdio tourne comme un processus local et parle à un client sur la même machine via l'entrée/sortie standard. C'est parfait pendant que vous construisez — mais il ne peut être joint par rien à travers le réseau.

Un serveur distant parle HTTP (Server-Sent Events, ou le plus récent transport streamable-HTTP) via une URL. N'importe quel client qui connaît l'URL et détient les bonnes clés peut l'appeler. Héberger votre propre serveur MCP signifie faire tourner la version distante quelque part de public et de stable.

Pourquoi ne pas simplement tunneliser votre portable

Vous pouvez techniquement exposer une machine domestique avec un tunnel, et pour une démo rapide ça va. Pour quoi que ce soit dont vous dépendez, vous héritez des problèmes de la machine : elle se met en veille, votre FAI fait tourner votre IP, votre débit montant est lent, et voilà un service plein de vrais outils posé sur votre réseau domestique à côté de tout le reste. Un VPS vous donne une IP publique fixe, un vrai domaine, une vraie disponibilité et de l'isolation. Pour quelques dollars par mois, ça supprime toute une catégorie de questions « pourquoi mon agent a-t-il perdu la connexion ».

La stack, concrètement

Choisissez une petite machine. Un serveur d'outils MCP, c'est surtout de l'I/O — il attend des API, des fichiers et des bases de données ; il ne fait pas de gros calculs. 1–2 Go de RAM suffisent largement pour la plupart. (Faire tourner un modèle en ligne pour répondre, c'est une autre histoire — voir auto-héberger un LLM avec Ollama.)

Faites tourner votre serveur lié à localhost, disons Node ou Python écoutant sur 127.0.0.1:3100. Gardez-le hors de l'interface publique directe — le proxy s'en occupe.

Mettez un reverse proxy devant pour terminer le TLS sur votre domaine. Caddy le fait en environ quatre lignes et récupère un certificat gratuit automatiquement :

mcp.votredomaine.com {
    reverse_proxy 127.0.0.1:3100
}

Pointez mcp.votredomaine.com sur l'IP de votre VPS, rechargez Caddy, et votre serveur est en ligne sur https://mcp.votredomaine.com via streamable-HTTP.

Le garder toujours en marche

Un serveur qui meurt au premier crash ou redémarrage n'est pas « hébergé » — il « tourne pour l'instant ». Enveloppez-le dans une unité systemd pour qu'il redémarre au crash et revienne après un reboot :

[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 et il est réellement toujours en marche. (Le même schéma garde n'importe quel agent ou bot en vie 24/7.)

La partie que les gens oublient : il vous faut un port joignable

Un point de terminaison MCP public a besoin d'un port entrant — le 443 — joignable depuis Internet. Sur un plan NAT vous obtenez exactement un port redirigé pour SSH et rien d'autre ; vous ne pouvez pas ouvrir le 443 au monde. Pour héberger un serveur MCP HTTPS public, vous voulez un plan à IP dédiée, où tous les ports sont à vous et où vous pouvez pointer un domaine directement sur la machine. C'est la différence entre « mon agent sur le même portable peut le joindre » et « n'importe quel client, n'importe où, le peut ».

Verrouillez-le — c'est une API avec des privilèges

Un serveur MCP expose en général des outils qui font des choses : lire des fichiers, taper des API payantes, déplacer de l'argent. Ne posez pas ça tout nu sur l'Internet ouvert.

Exigez un token à chaque appel. Rejetez les requêtes anonymes ; vérifiez un bearer token ou une clé API avant qu'un outil ne s'exécute.
Pare-feu sur tout sauf le 443 et votre port SSH.
SSH par clés uniquement, pas de connexion par mot de passe. (Voici la checklist de dix minutes.)

Traitez le point de terminaison pour ce qu'il est — une API dotée d'une vraie autorité — et la plupart du risque s'en va.

Les limites honnêtes

L'ops est à vous maintenant. Mises à jour de l'OS, garder le processus en bonne santé, surveiller les logs. Caddy renouvelle le certificat pour vous, mais le reste est à vous. Une fonction cloud managée cache tout ça ; un VPS vous le remet en échange du contrôle et d'une facture bien plus basse.
La spec MCP bouge encore. Les transports et les schémas d'auth changent de version en version. Épinglez la version de votre SDK et attendez-vous à la mettre à jour de temps en temps.
Une machine CPU convient aux serveurs d'outils, pas à générer des réponses avec un modèle local. Si votre serveur fait tourner un LLM pour répondre, c'est une machine séparée et plus lourde — voir le guide Ollama.
N'exposez jamais des outils destructeurs sans auth ni étape de confirmation. Un outil ouvert qui supprime des choses finira par rencontrer un bot qui scanne tout.

Le payer

Inscrivez-vous avec un e-mail et payez en USDC ou USDT — pas de carte, pas de pièce d'identité. Et si vous câblez tout ça pour un agent, le même genre de machine peut être commandée et payée par programme via notre propre serveur MCP — l'agent s'inscrit, alimente un solde et commande tout seul.

Hébergez le serveur une fois, et vos outils sont là dès que l'agent y tend la main.

Configuration prête à l'emploi : voir VPS pour serveurs MCP — le plan recommandé et un déploiement crypto d'une minute.