Claude Code y Hostinger Connector: de un boceto en papel a producción con una frase

La semana pasada monté un servidor MCP en producción a mano, delante de la cámara. Tardé 17 minutos: un VPS, un usuario, systemd, un dominio, Nginx, un certificado y un puerto ocupado que casi me tira el rodaje. Al terminar dije que la próxima vez se lo pediría a Claude Code.

El problema de fondo no es solo mío. Mucha gente construye cosas con IA (Claude, Chatgpt...) y se atasca en el último metro: entre «funciona en mi máquina» y «está online» hay un muro de dominios, DNS, certificados y paneles que nadie le ha explicado.

Esta es la próxima vez. No he abierto una terminal para desplegar nada: he escrito una frase. Transparencia desde el principio: el vídeo del que sale este artículo está patrocinado por Hostinger, es el tercero y último de una serie con ellos, y la herramienta que pruebo es su Hostinger Connector. Te cuento lo que pasó en pantalla, incluido lo que no salió solo.

Vamos a ver qué es, cómo se instala, las dos demos (un boceto en papel convertido en web y el mismo servidor MCP de la semana pasada) y qué no le dejo hacer.

Qué es el Hostinger Connector (y por qué no es «otro MCP más»)

El nombre confunde. El Hostinger Connector es un plugin de Claude Code que, por dentro, es un servidor MCP. Como el que montamos en el vídeo anterior, solo que este lo ha montado Hostinger. Y no es exclusivo de Claude Code: en su web aparece también para Visual Studio Code, Cursor y Antigravity.

La diferencia es enorme. Nuestro servidor exponía un catálogo de cursos. El de Hostinger expone tu cuenta entera: webs, dominios, VPS, tienda, correo, facturación. Si está en el panel, Claude Code lo puede manejar por ti. Eso tiene dos lecturas, las dos verdaderas:

• ✅ La buena: se acabó saltar entre la terminal, el navegador y el panel del hosting.
• ⚠️ La otra: le estás dando a un agente las llaves de tu infraestructura. De eso va la última sección, la que más importa.

Y una cosa que digo yo porque no la va a decir el patrocinador: esto no te enseña a desplegar, te lo hace. Si quieres entender qué es un proxy inverso o por qué tu servicio necesita systemd, el vídeo anterior sigue siendo el primero. Antes de los platos elaborados, todo el mundo tiene que ensuciarse las manos con un huevo frito. Si ese huevo frito te falta (usuarios, permisos, servicios, SSH), el curso de Linux de la A a la Z es la base que te permite entender, y revisar, lo que el agente hace en tu servidor.

La instalación: cuatro pasos y ninguna clave de API

1. El plan

Necesitas un plan de Hostinger. En el vídeo comparo el Unlimited con el Cloud Startup, que según Hostinger es veinte veces más potente para tus webs. Para lo que voy a hacer, con el Unlimited voy sobrado. Por defecto viene a 48 meses e incluye un dominio gratis el primer año. En el checkout, el cupón FROGAMES te da un 10 % de descuento adicional.

2. El plugin

En una sesión limpia de Claude Code puedes entrar en /plugins y buscar «hostinger», o instalarlo directamente:

/plugin install hostinger

Antes de instalar te pregunta el alcance: tu usuario en todos tus proyectos, todo el que use el repositorio o solo tú en este repositorio. Como era algo muy concreto, elegí la última.

3. La autenticación

Con /mcp ves los servidores disponibles, y el de Hostinger aparece pidiendo autenticación. Le das a autenticar, se abre el navegador, entras con tu cuenta de Hostinger y permites la conexión. Ni clave de API que copiar, ni token que pegar en un fichero.

4. Comprobar que está

Repites /mcp y Hostinger sale con el check verde. Eso es toda la instalación.

Debajo de todo esto hay una idea: dejar de ser el que escribe cada línea para ser el que dirige al que las escribe. No es que no tengas que saber escribirlas; es que el trabajo repetitivo lo orquestas en lugar de hacerlo tú. Eso tiene método, y es el camino que hacemos en tres semanas en De Vibe Coder a Ingeniero Agéntico, nuestro curso más vendido de este 2026.

Demo 1: de un papel rosa a un subdominio con candado

La primera prueba es la que le importa a la mayoría: tengo algo y no sé publicarlo. El encargo:

«Te paso un boceto hecho a mano de una landing page. Constrúyela como una web estática, limpia y responsive, respetando la estructura del boceto. Cuando esté, publícala en mi hosting de Hostinger en demo.juangabrielgomila.com, con HTTPS. Ve contándome cada paso que das.»

Primer tropiezo, mío: dije que le pasaba la imagen y no se la pasé. Así que dibujé en un papel rosa, delante de la cámara, un hero, tres bullets, un hueco para imagen o vídeo y una foto con un texto sobre mí. Foto con el móvil y a la carpeta del proyecto.

Mientras tanto, Claude ya había revisado la cuenta:

• El subdominio demo no existía, así que lo creó, con su carpeta dentro de public_html.
• No tocó ni el WordPress ni el subdominio de pruebas que yo tenía.
• El registro DNS lo creó Hostinger como un alias hacia su CDN, y el dominio ya resolvía.
• Para el HTTPS reaprovechó el certificado de Let's Encrypt que yo había creado en un vídeo anterior.

En pantalla se veía el orden de las herramientas: listar webs, pedidos, dominios, DNS y subdominios; crear el subdominio; listar ficheros. Con la foto ya en su sitio identificó los cuatro bloques y, para no inventarse el contenido, buscó en mi repositorio una biografía, una foto y un vídeo de YouTube. Eligió un retrato de estudio y lo recortó para el círculo.

Resultado: la web en un dominio de verdad, con su candado, sin que yo tocara una línea de configuración. Para quien lleva meses acumulando post-its y proyectos sin publicar, este es el minuto que importa.

Demo 2: el servidor MCP del vídeo anterior, pedido en una frase

Ahora lo que vine a hacer: el mismo servidor MCP, el mismo repositorio, el que a mano me costó 17 minutos y un tropiezo. Para que la comparación fuera justa, le di el mismo contexto que tenía yo:

«Quiero desplegar el servidor MCP de este repositorio en mi VPS de Hostinger: https://github.com/joanby/servidor-mcp. Que quede accesible en https://catalogo.juangabrielgomila.com/mcp, con HTTPS, arrancando solo si el servidor se reinicia, y protegido con un token en la cabecera Authorization. El repo trae un fichero de systemd y una config de Nginx de ejemplo en despliegue/. Ojo: en ese VPS ya hay otra instancia corriendo en el puerto 8000, así que esta tiene que ir en otro puerto. Ve contándome cada paso que das.»

Primero leyó el repositorio: usaría el puerto 8001 si estaba libre, el token lo valida un middleware en servidor.py y había que cambiar el puerto en el servicio y en el proxy_pass de Nginx. Luego localizó la IP del VPS, vio que catalogo. aún no tenía DNS y exploró el servidor sin modificar nada mientras preparaba el registro.

Primer muro: el VPS rechazaba su clave SSH, como root y como el usuario del servidor. Buscó pistas en mi historial de shell y, al no dar con la forma de entrar, me preguntó cómo seguir. Le di acceso fuera de cámara.

La única línea que tuve que pegar yo

Llegó hasta el final menos una cosa: en ese VPS sudo pide contraseña, y esa no la tenía. En lugar de quedarse parado, me dejó un script de instalación de cinco pasos que se detiene en cuanto uno falla:

1. Genera el token con OpenSSL.
2. Instala el servicio en systemd y lo activa para que arranque solo.
3. Crea el site de Nginx y, si algo falla, quita el enlace antes de recargar para no tumbar el servidor.
4. Pide el certificado.
5. Hace una comprobación de salud que debería devolver un 200.

Lo pegué en una terminal, escribí mi contraseña y salió el 200. Después le pedí que comprobara la conexión, e hizo dos pruebas: desde mi Mac y sin token, que el certificado fuera válido, que redirigiera a HTTPS y que el MCP rechazara la conexión; y desde el propio VPS, con el token, una sesión MCP completa contra la URL pública. Así el token no salía del servidor ni aparecía en la conversación, algo muy sensato cuando estás grabando la pantalla.

Y entonces volvió el error 421, el mismo que me tumbó a mí la semana pasada. Esta vez lo arregló Claude, guardando antes el servidor.py original. Lo más difícil que hice yo en todo el despliegue fue pegar una línea.

Dónde pongo el límite: delegar, revisar, nunca

Esta sección la hago en todos los vídeos patrocinados, y aquí pesa más que nunca: es mi cuenta, mi servidor y mi tarjeta de crédito. Mi frontera tiene tres niveles:

• ✅ Delegado sin pensarlo: entornos de pruebas, DNS, certificados, desplegar un cambio que ya he revisado. Trabajo mecánico y que se puede deshacer.
• ⚠️ Revisado siempre: cualquier cosa que toque producción con usuarios dentro, migraciones de base de datos y, sobre todo, borrados. El agente propone; yo reviso y decido.
• ❌ Nunca en automático: facturación, contratación, cualquier cosa que toque mi cartera. Que un agente vea mi facturación es cómodo; que contrate sin que yo lo mire es peligrosísimo.

No es miedo a la herramienta. Es lo que harías con un becario nuevo con muy buena mano: le das trabajo de verdad desde el primer día, pero no la tarjeta de crédito de la empresa.

La idea clave: solo juzga al agente quien sabe hacerlo a mano

Con esto se cierra la serie, y conviene verla entera porque cuenta una historia. En el primer vídeo no tocamos nada: un asistente de IA montado en cuatro clics. En el segundo lo hicimos todo a mano, la cocina entera. En este tercero se lo he pedido a Claude Code y he cerrado el círculo.

Solo quien ha pasado por el segundo sabe valorar lo que te ahorra el agente: minutos, configuraciones, contraseñas, errores. Y solo ese sabe ver cuándo algo no está bien. Por eso el orden correcto es primero entender qué pasa por debajo y después decidir qué delegas.

Si lo que te ha picado es construir tus propios agentes, no solo usarlos, el Curso Completo de Ingeniería de Agentes de IAes el siguiente paso, y en el blog tienes más artículos como este. Y si quieres probar el Connector, el cupón FROGAMES sigue ahí.

Un papel rosa, una frase y un servidor en producción.

El último metro ya no es excusa.