Escribiste un servidor MCP. Localmente funciona bien — tu agente lo llama, las herramientas disparan, todo está conectado. Luego cierras tu portátil y desaparece. Si quieres ese servidor accesible siempre que tu agente lo necesite — desde otra máquina, desde el setup de un compañero, desde un trabajo programado a las 3 de la madrugada — tiene que vivir en algún sitio que esté siempre activo, con una dirección estable y HTTPS. Para eso sirve un VPS.
Aquí está cómo mover tu servidor MCP de tu portátil a una máquina que de verdad controlas, con notas honestas sobre dónde va el esfuerzo.
Local vs remoto: qué significa realmente «alojar»
Los servidores MCP vienen en dos formas.
Un servidor stdio funciona como un proceso local y habla con un cliente en la misma máquina por entrada/salida estándar. Es perfecto mientras construyes — pero nada por la red puede alcanzarlo.
Un servidor remoto habla HTTP (Server-Sent Events, o el más nuevo transporte streamable-HTTP) por una URL. Cualquier cliente que conozca la URL y tenga las credenciales correctas puede llamarlo. Alojar tu propio servidor MCP significa ejecutar el tipo remoto en algún sitio público y estable.
Por qué no simplemente tunelizar tu portátil
Técnicamente puedes exponer una máquina de casa con un túnel, y para una demo rápida está bien. Para cualquier cosa de la que dependas, heredas los problemas de la máquina: duerme, tu ISP rota tu IP, tu subida es lenta, y ahora un servicio lleno de herramientas reales está en tu red doméstica junto a todo lo demás. Un VPS te da una IP pública fija, un dominio real, disponibilidad adecuada y aislamiento. Por un par de dólares al mes elimina toda una categoría de preguntas de «por qué mi agente perdió la conexión».
El stack, concretamente
Elige una máquina pequeña. Un servidor de herramientas MCP está sobre todo ligado a E/S — espera a APIs, archivos y bases de datos; no hace matemáticas pesadas. 1–2 GB de RAM es de sobra para la mayoría. (Ejecutar un modelo en línea para responder es otra historia — mira autoalojar un LLM con Ollama.)
Ejecuta tu servidor atado a localhost, digamos Node o Python escuchando en 127.0.0.1:3100. Mantenlo directamente fuera de la interfaz pública — el proxy se encarga de eso.
Pon un reverse-proxy delante para terminar TLS en tu dominio. Caddy lo hace en unas cuatro líneas y obtiene un certificado gratis automáticamente:
mcp.yourdomain.com {
reverse_proxy 127.0.0.1:3100
}
Apunta mcp.yourdomain.com a la IP de tu VPS, recarga Caddy, y tu servidor está en línea en https://mcp.yourdomain.com sobre streamable-HTTP.
Mantenlo siempre activo
Un servidor que muere al primer fallo o reinicio no está «alojado» — está «funcionando por ahora». Envuélvelo en una unidad systemd para que se reinicie en los fallos y vuelva tras un reinicio:
[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 y está genuinamente siempre activo. (El mismo patrón mantiene cualquier agente o bot vivo 24/7.)
La parte que la gente se pierde: necesitas un puerto accesible
Un endpoint MCP público necesita un puerto entrante — 443 — accesible desde internet. En un plan NAT obtienes exactamente un puerto reenviado para SSH y nada más; no puedes abrir el 443 al mundo. Para alojar un servidor MCP HTTPS público quieres un plan con IP dedicada, donde todos los puertos son tuyos y puedes apuntar un dominio directo a la máquina. Esa es la diferencia entre «mi agente en el mismo portátil puede alcanzarlo» y «cualquier cliente en cualquier lugar puede».
Ciérralo bien — es una API con privilegios
Un servidor MCP normalmente expone herramientas que hacen cosas: leer archivos, llamar a APIs de pago, mover dinero. No pongas eso desnudo en el internet abierto.
- Exige un token en cada llamada. Rechaza las solicitudes anónimas; comprueba un token bearer o una clave de API antes de que se ejecute cualquier herramienta.
- Firewall a todo excepto el 443 y tu puerto SSH.
- SSH solo con claves, sin login por contraseña. (Aquí está la checklist de diez minutos.)
Trata el endpoint como lo que es — una API con autoridad real — y la mayor parte del riesgo desaparece.
Los límites honestos
- La operación es tuya ahora. Actualizaciones del OS, mantener el proceso sano, vigilar logs. Caddy renueva el certificado por ti, pero el resto es tuyo. Una función cloud gestionada oculta esto; un VPS te lo entrega a cambio de control y una factura mucho más baja.
- La especificación MCP aún se mueve. Los transportes y patrones de auth cambian de release a release. Fija tu versión del SDK y cuenta con actualizarla de vez en cuando.
- Una máquina de CPU es la adecuada para servidores de herramientas, no para generar respuestas con un modelo local. Si tu servidor ejecuta un LLM para responder, esa es una máquina aparte, más pesada — mira la guía de Ollama.
- Nunca expongas herramientas destructivas sin auth y un paso de confirmación. Una herramienta abierta que borra cosas acabará por encontrarse con un bot que lo escanea todo.
El pago
Regístrate con un correo y paga en USDC o USDT — sin tarjeta, sin documento. Y si estás conectando esto para un agente, el mismo tipo de máquina puede pedirse y pagarse de forma programática mediante nuestro propio servidor MCP — el agente se registra, financia un saldo y pide por su cuenta.
Aloja el servidor una vez, y tus herramientas están ahí siempre que el agente las busque.
Configuración lista: mira VPS para servidores MCP — el plan recomendado y un despliegue cripto en un minuto.
Comentarios
Aún no hay comentarios. Sé el primero.