Calor de verano — todo se derrite, hasta nuestros precios.−25%−25 % en cada plan anual, hasta el 31 de agostoVer planes
EQVPS
Empezar

Aloja tu propio servidor MCP en un VPS

5 jul 2026 · 5 min de lectura · EQVPS Team

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.

Trata el endpoint como lo que es — una API con autoridad real — y la mayor parte del riesgo desaparece.

Los límites honestos

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.

Preguntas frecuentes

¿Necesito una IP dedicada para alojar un servidor MCP?

Para un endpoint HTTPS público, sí. Los planes NAT reenvían un único puerto SSH y no exponen el puerto 443 a internet. Un plan con IP dedicada te da todos los puertos y un dominio que puedes apuntar directo a la máquina.

stdio o HTTP — ¿qué transporte alojo?

HTTP (SSE o el más nuevo streamable-HTTP). Un servidor stdio solo habla con un cliente en la misma máquina; cualquier cosa que quieras accesible por la red tiene que hablar HTTP detrás de una URL.

¿Puede un VPS ejecutar varios servidores MCP?

Sí. Ata cada servidor a un puerto local distinto y dale a cada uno su propia subdominio en el reverse-proxy. La RAM es el límite práctico, y los servidores de herramientas usan muy poca.

¿Cuánta RAM necesita un servidor MCP?

Normalmente poca. Un servidor de herramientas está ligado a E/S — espera a APIs y bases de datos en vez de triturar números, así que 1–2 GB maneja la mayoría. Ejecutar un modelo para generar las respuestas es un trabajo aparte, mucho más pesado.

← Volver al blogVer planes y precios →

Comentarios

Aún no hay comentarios. Sé el primero.

Deja un comentario

Los comentarios se moderan antes de aparecer.