Gestionar el hosting suele interrumpir el desarrollo. Escribes código en un editor, abres un panel de hosting para crear un sitio web, cambias a una terminal para empaquetar o enviar el proyecto, vuelves al panel para inspeccionar un despliegue y abres más herramientas cuando el DNS, los registros o los recursos del servidor necesitan atención.
Hostinger Connector reduce ese cambio de contexto. Conecta los servicios de Hostinger a herramientas de codificación con IA mediante el Model Context Protocol (MCP), lo que te permite pedirle a un asistente de IA que inspeccione o gestione recursos de hosting compatibles sin salir de tu editor.
Eso suena conveniente. También plantea una pregunta más importante: ¿Puedes confiar en que un asistente de IA realice tareas reales de hosting con precisión?
Para averiguarlo, probé Hostinger Connector con VS Code y GitHub Copilot en una cuenta real de Hostinger. Utilicé una pequeña aplicación de Express.js llamada PulseWatch y seguí el flujo de trabajo desde la instalación hasta el despliegue en vivo. También probé despliegues repetidos, registros de compilación, logs y la recuperación después de romper deliberadamente el comando de inicio de la aplicación.
Aquí es como puntuó Hostinger Connector en las áreas que más importan a un desarrollador que decide si usarlo: coste, amplitud de funciones, usabilidad diaria, precisión con la que ejecuta tareas reales y el soporte que lo respalda cuando algo sale mal. Cada puntuación refleja lo que encontré realmente durante las pruebas, no la página de marketing.
| Parámetro | Puntuación | Por qué esta puntuación |
|---|---|---|
| Precios | 9.7/10 | Connector no tiene ninguna cuota de suscripción aparte y se incluye gratis con todos los planes. El único coste es el recurso de hosting subyacente que de todos modos necesitarías. |
| Funciones | 9.5/10 | El rango de funciones va más allá del despliegue e incluye websites, dominios, DNS, bases de datos, campañas de email, recursos VPS, logs y diagnósticos, cubriendo más terreno que una herramienta de despliegue típica. |
| Facilidad de uso | 9.1/10 | La instalación y el OAuth fueron rápidos y no requirieron configuración manual, y los despliegues repetidos fueron sencillos. La configuración inicial del sitio Node.js necesitó hPanel después de que la IA no lograra identificar un destino válido, la única laguna real en una configuración por lo demás fluida. |
| Precisión de ejecución | 8.5/10 | El análisis del proyecto, la edición de código, el empaquetado, el despliegue y la recuperación funcionaron bien. La IA reutilizó un dominio inventado e interpretó en exceso una comprobación de accesibilidad antes de que ese destino existiera. |
| Soporte | 9.5/10 | Kodee dio una respuesta específica y precisa a una pregunta técnica real a la primera, y el seguimiento del especialista humano fue aún más preciso. Escalar tomó dos solicitudes directas, pero tanto las respuestas de la IA como las humanas fueron fiables una vez que se dieron. |
| Total | 9.3/10 | Una herramienta de flujo de trabajo valiosa para usuarios de Hostinger que trabajan en editores con IA. No cuesta nada extra, cubre una amplia gama de funciones y tanto la configuración como el soporte resistieron bien en las pruebas. La precisión de ejecución en torno a nuevos destinos de despliegue es el único punto a vigilar. |
Hostinger Connector no se vende como un producto independiente. Hostinger dice que Connector está incluido gratis con todos los planes, lo que significa que no hay una cuota mensual separada de Connector que añadir a tu factura de hosting.
Sin embargo, “gratis” necesita contexto. Connector gestiona recursos de Hostinger; no los reemplaza. Aún necesitas un hosting, cloud, VPS, dominio, email u otro servicio elegible de Hostinger para las tareas que quieras que realice.
En el momento de esta reseña, la página de aterrizaje de Connector destacaba Business Web Hosting y Cloud Startup.
| Plan | Precio promocional | Plazo inicial mostrado | Precio de renovación | Web apps | Websites |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
Los precios se mostraban antes de los impuestos aplicables. Los precios promocionales y las tarifas de renovación pueden cambiar, así que revisa el total actual al pagar en lugar de juzgar el plan solo por la cifra mensual anunciada.
Idea sobre precios: No compres un plan superior solo para acceder a Connector. Elige el plan según el número de websites y web apps que necesites, los recursos que requieran y el nivel de soporte que quieras. Connector es una capa de gestión incluida, no el producto principal que se está cobrando.
Hostinger anuncia una garantía de reembolso de 30 días para las compras de hosting elegibles. No hay una política de reembolso separada para Connector que evaluar porque Connector no tiene una tarifa independiente.
Las acciones exactas disponibles dependen de los servicios de Hostinger que tengas en tu cuenta y de las herramientas expuestas al cliente de IA conectado.
Hostinger también documenta límites de velocidad. Según las preguntas frecuentes de Connector, el permiso predeterminado es de 60 solicitudes por minuto y 1,000 solicitudes por hora, con la información de límite de velocidad devuelta en los encabezados de respuesta.
Esos límites son generosos para el uso interactivo, aunque los flujos de trabajo automatizados o muy repetitivos deberían seguir evitando llamadas duplicadas innecesarias.
Antes de poder juzgar si Hostinger Connector despliega y gestiona bien el hosting, necesitaba saber qué hacía falta para ponerlo en marcha.
Una herramienta diseñada para permanecer dentro del editor pierde rápidamente su atractivo si la configuración implica editar archivos de configuración, generar tokens API o reautenticación repetida. Esta sección solo cubre la configuración. La prueba práctica de tareas va justo después.
Instalé Hostinger Connector desde VS Code Marketplace. Apareció como el primer resultado cuando busqué “Hostinger”, el publicador figuraba como Hostinger Official y se instaló a la primera en menos de dos minutos.
| Detalle | Resultado |
|---|---|
| Búsqueda en Marketplace | Aprobado, apareció de inmediato |
| Verificación del publicador | Hostinger Official |
| Instalación | Completada en menos de dos minutos |
| Versión de la extensión en el momento de la prueba | 1.3.1 |
| Instalaciones en Marketplace | 8,140 |
| Valoración de usuarios | 5 estrellas, basado en dos valoraciones |
La última fila merece una advertencia. Cinco estrellas suena bien, pero una muestra de dos reseñas no me dice casi nada sobre la experiencia habitual del usuario. No me apoyaría en ese número en el texto de la reseña.
Un requisito previo me sorprendió: Hostinger Connector proporciona las herramientas de Hostinger, pero necesita un agente de IA ya activo en el editor para poder llamarlas.
La extensión en sí no tiene nada con lo que hablar por sí sola. En VS Code, ese agente es GitHub Copilot Chat, ya que es actualmente la interfaz de IA que VS Code expone para llamadas de herramientas MCP. Yo ya tenía Copilot activo, así que esto no me retrasó, pero los lectores deben saber que Connector solo es tan útil como el agente de IA que tenga detrás.
Sin uno instalado y con sesión iniciada, no hay nada a lo que conectarlo.
Lo que la instalación no requirió:
Instalar la extensión fue una de las partes más fluidas de toda la prueba. El único inconveniente real es una dependencia que Hostinger no destaca: la extensión necesita un agente de IA activo en tu editor para hacer algo.
Con la extensión instalada, la siguiente pregunta era si conectarla a una cuenta real sería igual de sencillo.
La conexión de la cuenta usó OAuth mediante un botón “1-Click Connect”. VS Code abrió una página de autorización de Hostinger en mi navegador, detectó mi sesión de Hostinger existente y me pidió aprobar el acceso para algo etiquetado como hostinger-mcp.
Después de hacer clic en Allow, volví a VS Code mostrando “Connected via OAuth”.
| Comprobación | Resultado |
|---|---|
| Conexión con un clic | Aprobado |
| El navegador se abrió automáticamente | Aprobado |
| Se detectó la sesión existente de Hostinger | Aprobado |
| Se requirió token API manual | No |
| Se mostró pantalla de autorización | Sí |
| Se explicaron los permisos | Sí, pero de forma amplia |
| Volvió correctamente a VS Code | Aprobado |
La pantalla de autorización me dijo que Connector podía gestionar websites, hosting, dominios, suscripciones y otros servicios de Hostinger.
Eso es una lista por categorías, no un desglose permiso por permiso. Me habría gustado más granularidad aquí, ya que “gestionar suscripciones” y “gestionar websites” cubren niveles de riesgo muy diferentes.
Lo que sí me dio algo de ese control fue un panel separado dentro de la extensión que enumera cada categoría de herramientas y me permite activar o desactivar cada una individualmente:
| Categoría de herramientas | Herramientas disponibles | Estado predeterminado |
|---|---|---|
| Websites | 80 | Activado |
| Dominios | 26 | Activado |
| Suscripciones y pagos | 7 | Activado |
| Email Marketing | 12 | Activado |
| Ecommerce | 12 | Desactivado |
| VPS | 62 | Desactivado |
Eso hace un total de 199 herramientas, con 125 activadas por defecto. Dejé Ecommerce y VPS desactivados hasta que estuve listo para probarlos directamente, y la extensión respetó ese límite durante toda la prueba.
Este es el tipo de detalle de seguridad que no aparece en la página de marketing de Hostinger pero que importa a cualquiera que decida cuánto acceso dar a un asistente de IA. Lo consideraría una fortaleza real.
Desconectar la cuenta está disponible desde el mismo panel, sin necesidad de cambiar tu contraseña de Hostinger ni buscar un token almacenado.
La autorización fue rápida y no requirió que yo gestionara un token, pero la pantalla de permisos es amplia en lugar de granular. Los controles de herramientas a nivel de categoría dentro de la extensión hacen más para limitar el riesgo real que la pantalla OAuth.
Hostinger enumera compatibilidad con los siguientes clientes, recopilados desde la pantalla de onboarding de la extensión:
| Editor o cliente | Listado por Hostinger |
|---|---|
| VS Code | Sí |
| Cursor | Sí |
| Windsurf | Sí |
| Devin Desktop | Sí |
| Antigravity | Sí |
| Claude Code | Sí |
| OpenAI Codex CLI | Sí |
Usé VS Code con GitHub Copilot como mi entorno de prueba principal.
La configuración me dijo que Connector es fácil de poner en marcha. Todavía no decía nada sobre si realmente hace bien el trabajo una vez conectado, que era la pregunta más difícil a la que me enfrenté a continuación.
Instalar y conectar una extensión es la parte fácil. Lo que realmente importa es si hace bien el trabajo real de hosting, así que construí una pequeña aplicación de Express.js llamada PulseWatch y sometí al Connector al mismo recorrido que seguiría un desarrollador después de instalarlo: inspeccionar la cuenta, encontrar un destino de despliegue, desplegar el proyecto, actualizarlo, inspeccionar los resultados y recuperarse de un fallo que introduje a propósito.
| Prueba | Lo que quería aprender |
|---|---|
| Leer datos de la cuenta | ¿Puede entender con precisión la cuenta de hosting? |
| Encontrar un destino de despliegue | ¿Puede identificar el sitio web correcto sin adivinar? |
| Analizar el proyecto Node.js | ¿Entiende la aplicación antes de tocarla? |
| Desplegar PulseWatch | ¿Puede llevar un proyecto real desde el editor hasta el hosting en vivo? |
| Publicar una actualización de contenido | ¿Es útil para el trabajo rutinario de desarrollo? |
| Inspeccionar compilaciones y logs | ¿Da evidencia útil después de un despliegue? |
| Desplegar una versión rota | ¿Revela un fallo real de la aplicación? |
| Recuperar la aplicación | ¿Puede restaurar con seguridad una versión conocida como buena? |
PulseWatch era deliberadamente simple: un servidor Express, una página de inicio, un script de inicio en package.json y un endpoint /api/health que devolvía JSON. Ese endpoint de salud resultó importante más adelante.
Una plataforma de hosting puede informar de una compilación completada incluso cuando la aplicación falla al iniciarse. Un endpoint en vivo me dio una forma independiente de comprobar si el proceso desplegado realmente respondía, en lugar de confiar en una insignia de estado.
Empecé con prompts de solo lectura antes de permitir que el asistente se acercara a cambios en vivo. Si no podía describir con precisión mi cuenta, tendría poca razón para confiarle despliegues, DNS o acciones de VPS.
La herramienta de listado de websites del Connector devolvió cinco sitios:
Mi cuenta en realidad tenía más que eso. hPanel mostraba websites repartidos entre los planes Premium, Business y Growth, incluidos sitios WordPress, sitios PHP/HTML, proyectos de Website Builder y varios dominios temporales.
En otro prompt preguntando por mis planes de hosting activos, el asistente me dijo que tenía “one active hosting plan.” hPanel mostraba tres: Premium, Growth y Business.
| Comprobación | Resultado |
|---|---|
| Listado de websites conocidos | Aprobado |
| Listado de todos los planes de hosting | Fallado |
| Detectó el plan Business sin usar | Fallado |
| Hizo cambios en la cuenta | No |
Para ser justos con el Connector, cuando lo cuestioné y le señalé la discrepancia, se corrigió, separó claramente lo que había verificado de lo que había asumido y no repitió la afirmación incorrecta.
Esa es una mejor forma de fallo que insistir en el error, pero significa que la primera respuesta a una pregunta sobre toda la cuenta no debe tomarse al pie de la letra.
El acceso de solo lectura funcionó, pero la primera respuesta a cualquier pregunta sobre la cuenta fue incompleta. Se corrigió una vez cuestionado, lo cual importa, pero no debería haber tenido que cuestionarlo.
Esa laguna en la visibilidad de la cuenta resultó ser un adelanto de un problema mayor. La verdadera prueba de si importaba llegó después, cuando pedí al Connector que encontrara un website nuevo que no se le había dicho por nombre.
Aquí es donde la prueba reveló lo más importante. Pedí al asistente que identificara un nuevo sitio Node.js sin nombrar su dominio y sin tocar ningún sitio existente.
La selección de destino es un requisito básico de seguridad para una herramienta que puede actuar sobre una cuenta real, así que quería ver cómo manejaba la incertidumbre en lugar de una respuesta limpia.
Esto fue lo que pasó, en orden:
| Paso | Lo que hizo el Connector | Resultado |
|---|---|---|
| 1 | Reutilizó un nombre de dominio de un intento fallido anterior: pulsewatch-temp-20260714.hostingersite.com | Este dominio nunca había sido devuelto por ninguna llamada de listado de websites |
| 2 | Ejecutó una comprobación de accesibilidad en ese dominio | Devolvió is_accessible: true |
| 3 | Tomó ese resultado como confirmación de que el website existía | Incorrecto. La accesibilidad no es lo mismo que un registro de sitio web existente y desplegable |
| 4 | Intentó el despliegue usando IDs de recursos que no había verificado como IDs de pedido de hosting | Hostinger devolvió [Hosting:9999] Not found, dos veces |
El problema principal: los dos IDs que utilizó eran IDs de recursos de dominio, no IDs de pedido de hosting. Nunca confirmó la distinción antes de llamar a una herramienta real de creación de websites con ellos.
Cuando le pedí que se explicara, el asistente acabó dando un relato preciso: tenía una herramienta funcional de listado de websites disponible todo el tiempo, pero nunca la volvió a llamar después de que yo creé un nuevo sitio a través de hPanel, así que rellenó el vacío con un dominio no verificado en lugar de actualizar sus datos.
Cuando le pedí directamente que volviera a ejecutar esa herramienta de listado y comprobara si aparecía un nuevo registro, llamó a tres herramientas no relacionadas con el seguimiento del despliegue y reportó “no new website appeared,” una conclusión que las llamadas a herramientas que realmente hizo no podían haber respaldado.
Nada de esto creó un website suelto en mi cuenta. Las llamadas fallidas no dejaron nada detrás. Pero vale la pena nombrar el patrón con claridad. Ante datos incompletos, el asistente rellenó el vacío con una suposición plausible, tomó una señal débil como evidencia fuerte y actuó sobre una cuenta real antes de que esa suposición se comprobara.
Este es el hallazgo más importante de esta sección. El Connector adivinará un destino y actuará sobre esa suposición en lugar de detenerse y preguntar. Falló de forma segura aquí, pero la costumbre de tratar una señal débil como prueba es lo que debes vigilar en tu propia cuenta.
Con el Connector incapaz de localizar el destino por sí solo, me quedaba una opción: construir el destino yo mismo y ver si eso cambiaba algo.
Como el Connector no podía localizar de forma fiable el nuevo destino por sí solo, terminé la configuración inicial manualmente a través de hPanel para ver qué prepara Hostinger antes de que sea posible el despliegue mediante Connector.
El recorrido fue: Crear un sitio nuevo → aplicación web Node.js → dominio temporal → Hostinger seleccionó automáticamente un centro de datos del Reino Unido con una latencia estimada de 147ms → una elección de tres métodos de despliegue.
Esa tercera pantalla merece una mención aparte. Hostinger ofrece “Build with Hostinger Connector” como método de despliegue junto a la importación desde GitHub y la subida manual de archivos. Lo seleccioné esperando que terminara de configurar el sitio.
En su lugar, me redirigió a la propia página de instalación de Connector, que ya había completado. Ese es un verdadero vacío de onboarding. La opción presentada como una ruta nativa de Connector en realidad no aprovisionó nada.
Volví atrás y elegí la subida manual de archivos en su lugar. Hostinger aceptó mi archivo del proyecto (11.46 KB, con node_modules excluido), y la pantalla de configuración mostró una detección automática precisa:
Hice clic en Deploy. Se completó correctamente y Hostinger asignó un dominio temporal real: orange-walrus-700988.hostingersite.com. Ese es un dominio distinto del que el Connector había inventado antes. Abrí manualmente tanto la página de inicio como /api/health y confirmé que ambas funcionaban.
La ruta manual funcionó sin fricción una vez que dejé de esperar a que el Connector lo encontrara. El botón “Build with Hostinger Connector” en esta pantalla debería arreglarse o eliminarse. Ahora mismo promete algo que no hace.
Ahora existía un website real y confirmado. La siguiente pregunta era si el Connector se comportaría de forma diferente ahora que tenía algo sólido que encontrar.
Con un website real y confirmado en su lugar, volví al Connector y le pedí que inspeccionara ese dominio exacto. Esta vez funcionó correctamente.
| Comprobación | Resultado |
|---|---|
| Reconoció el sitio como un destino de despliegue Node.js | Aprobado |
| Encontró el registro de despliegue completado | Aprobado |
| Encontró el registro de compilación Node.js coincidente | Aprobado |
| El despliegue y la compilación compartían el mismo UUID | Aprobado |
Eso confirmó algo importante: los fallos anteriores estaban relacionados con localizar y crear un nuevo destino, no con la capacidad del Connector para trabajar con un sitio Node.js una vez que existe uno.
A continuación probé la función que Hostinger promociona con más fuerza: hacer un cambio de código local y publicarlo sin abrir hPanel.
Le pedí al asistente que cambiara una línea del texto de la página de inicio, de “Monitor Every Service. Catch Every Issue.” a “Monitor Every Service. Resolve Issues Faster.”
| Paso | Resultado |
|---|---|
| Encontró el texto existente | Aprobado |
| Cambiò solo la línea solicitada | Aprobado |
| Verificó la app localmente antes de desplegar | Aprobado |
Empaquetó el proyecto, excluyendo node_modules y .git | Aprobado |
| Desplegó al website existente y confirmado | Aprobado |
| Comprobó el estado del despliegue y de la compilación después | Aprobado |
Todo el proceso de actualización tardó alrededor de un minuto. El asistente informó del nuevo despliegue como “pending” justo después de enviarlo, simplemente porque comprobó antes de que Hostinger terminara de procesarlo.
Cuando yo mismo actualicé el sitio en vivo, el nuevo encabezado ya estaba allí.
Los logs de compilación que recuperó después fueron específicos y útiles: 67 paquetes añadidos, 68 auditados, cero vulnerabilidades encontradas, sin errores.
Para sitios establecidos, esto se acerca mucho al flujo de trabajo que Hostinger promete. Editar, verificar localmente, publicar y confirmar, todo sin salir del editor, en alrededor de un minuto. Este es el mejor resultado de toda la prueba.
Un despliegue limpio solo me dice que el camino feliz funciona. Para averiguar qué hace realmente el Connector bajo presión, rompí la aplicación a propósito.
Una herramienta solo gana confianza cuando sobrevive al contacto con un fallo real, no solo con una demostración limpia. Rompí deliberadamente la aplicación para ver si el estado y los logs del Connector podían ayudarme realmente a diagnosticarlo.
Antes de hacer cualquier cambio, el asistente hizo una copia de seguridad de package.json a package.json.bak, un buen hábito por sí mismo.
Luego le hice cambiar el script de inicio de “start”: “node server.js” a “start”: “node missing-server.js”, un archivo que no existe.
Ejecutarlo localmente confirmó un fallo real y reproducible: Error: Cannot find module ‘…/missing-server.js’.
Desplegué la versión rota de todos modos, a propósito, para ver qué reportaría Hostinger.
| Estado mostrado | Qué confirmó | Qué no confirmó |
|---|---|---|
| Compilación: completed | Se instalaron dependencias, terminó la fase de compilación | La aplicación realmente se inició |
| Despliegue: completed | Hostinger aceptó y procesó la versión | Que todas las rutas estuvieran sanas |
Los logs de compilación accesibles a través del Connector mostraban la instalación exitosa de dependencias y nada más. El error de tiempo de ejecución por módulo faltante nunca apareció en ellos. Un desarrollador que viera una insignia verde de “completed” no tendría razón para sospechar que el sitio estaba roto.
La recuperación fue fluida. El asistente restauró package.json desde su copia de seguridad, verificó la app localmente, volvió a desplegar y confirmó la corrección llamando directamente al endpoint /api/health en vivo en lugar de confiar en el estado del despliegue.
Ese endpoint devolvió una respuesta operativa, que fue la única prueba en toda la prueba que realmente demostró que la aplicación estaba en funcionamiento.
Este es el segundo hallazgo importante. Un estado completado no es prueba de que una aplicación funcione, y los propios logs del Connector no te lo dirán. La recuperación en sí funcionó bien una vez que supe que había un problema que recuperar.
Después de un fallo que una insignia de estado no podía revelar, quise saber dónde más podría adelantarse la confianza del Connector a su capacidad real. Las variables de entorno fueron la siguiente prueba.
Le pedí al asistente que añadiera una variable de entorno inofensiva, confirmara que la configuración existía como una capacidad dedicada de Connector antes de tocar nada y se detuviera si no existía.
Buscó entre las herramientas disponibles, no encontró ninguna acción dedicada para gestionar variables de entorno de Node.js y se detuvo antes de hacer cualquier cambio en el código o en el despliegue.
Este es el comportamiento que quería ver en todas las demás partes de esta prueba. Ante un límite real, se detuvo en lugar de adivinar. No concluiría que Hostinger Connector no tiene soporte para variables de entorno en ninguna parte de su conjunto de herramientas, solo que no se expuso ninguna acción así durante esta prueba.
| Prueba | Resultado | Hallazgo clave |
|---|---|---|
| Respaldar el manifiesto que funciona | Aprobado | Archivo de recuperación creado antes de modificar |
| Introducir una entrada principal faltante | Aprobado | Se añadió un fallo controlado |
| Reproducir el fallo localmente | Aprobado | MODULE_NOT_FOUND confirmado |
| Desplegar la versión rota | Aprobado | Hostinger aceptó el archivo comprimido |
| El estado de compilación detecta el fallo | Fallado | La compilación seguía mostrando completed |
| Los logs de compilación exponen el error en tiempo de ejecución | Fallado | El error de módulo faltante no aparecía |
| Restaurar el manifiesto que funciona | Aprobado | Se recuperó el comando de inicio original |
| Volver a desplegar la versión funcional | Aprobado | Despliegue completado |
| Verificar el endpoint de salud en vivo | Aprobado | La API devolvió estado operativo |
Hostinger Connector realizó bien tareas rutinarias y deterministas:
Fue más débil cuando la tarea requería interpretación a partir de datos incompletos de la cuenta:
Este patrón es útil a la hora de decidir cuánta autonomía darle al asistente.
Usa prompts amplios para inspecciones de bajo riesgo. Usa prompts precisos y requisitos explícitos de confirmación para acciones que cambian la infraestructura en vivo.
Por ejemplo, en lugar de:
| Despliega esta app en un nuevo sitio temporal de Hostinger. |
usa:
| Enumera los websites que devuelve actualmente Hostinger. Identifica un website Node.js solo si aparece en ese resultado. Muéstrame el dominio exacto y la evidencia antes de desplegar. No generes, infieras ni reutilices un dominio que no haya sido devuelto por Hostinger. |
El segundo prompt limita el margen de suposición del asistente.
Poner en marcha Hostinger Connector fue fácil, sin la fricción habitual de configuración, y los controles granulares por categoría de herramientas me dieron una verdadera capacidad de decisión sobre lo que la IA podía tocar.
Una vez que existía un website real con un dominio conocido, hizo bien el trabajo: un cambio de texto en una línea pasó de edición a estar en vivo en alrededor de un minuto, respaldado por logs de compilación útiles.
El problema apareció antes en el proceso, no después. Ante un sitio nuevo que no podía encontrar, el Connector inventó un dominio y actuó sobre él antes de comprobar. También marcó un despliegue roto como “completed” mientras la app en realidad estaba caída, sin que apareciera ningún error en tiempo de ejecución en sus propios logs. Ninguno de los dos problemas hace que la herramienta sea poco fiable para sitios establecidos, pero ambos significan que los nuevos despliegues y el estado posterior al despliegue necesitan una segunda revisión antes de confiar plenamente.
Hostinger construye su soporte alrededor del chat en vivo y el autoservicio más que de llamadas telefónicas, así que centré mis pruebas en donde la mayoría de los usuarios realmente terminarán: el asistente de IA integrado en hPanel, la escalada humana detrás de él y la base de conocimiento a la que un desarrollador acudiría antes de abrir un chat.
| Canal | Disponibilidad | Notas |
|---|---|---|
| Chat en vivo (Kodee, IA) | 24/7 | Accedido mediante “Ask AI” en hPanel |
| Chat en vivo (humano) | Solo por escalado | No es una cola directa, se deriva a través de Kodee |
| Email / ticket | support@hostinger.com | Se indicó una ventana de respuesta de 1 business day |
| Teléfono | No ofrecido | No hay una línea telefónica pública para soporte general |
| Base de conocimiento | Autoservicio | support.hostinger.com |
| Tutorials y Academy | Autoservicio | Guías paso a paso y un canal de YouTube |
Dado que el chat en vivo es el canal al que Hostinger dirige a los desarrolladores para cualquier cosa urgente, y el más probable que realmente se use mientras se depura un despliegue, probé ese camino directamente en lugar de presentar un ticket por correo.
Abrió el chat en vivo a través de “Ask AI” en hPanel y le hice a Kodee una pregunta con una respuesta real que podía equivocarse: si un estado de compilación completada en un despliegue Node.js garantiza que la app se esté ejecutando realmente, y dónde encontraría evidencia de lo contrario.
La primera respuesta de Kodee fue específica y correcta:
“Completed” usually means the build step finished successfully; it does not guarantee the app is healthy after launch. To catch a bad start command or other runtime crash, check runtime logs: in hPanel go to Websites → Dashboard → Deployments for build logs, and then open your app’s stderr.log in the nodejs folder for startup errors like Port already in use or Module not found.
Una sola respuesta así habría resuelto exactamente la misma ambigüedad con la que mi prueba de recuperación ante fallos se encontró antes en esta reseña. Kodee nombró un archivo de log real, la carpeta correcta y trazó la línea adecuada entre el éxito de la compilación y la salud en tiempo de ejecución.
Sin embargo, también quería ver si puedo acceder a un agente humano real, así que le dije a Kodee que me gustaría confirmar esto directamente con un ingeniero de soporte.
Pero conseguir a un humano en la línea fue más difícil de lo que esperaba. Pedí directamente un agente en vivo y me redirigieron de vuelta a Kodee dos veces, cada vez enmarcado como más rápido que esperar:
Entiendo por qué querrías eso. Puedo ayudarte a verificar la compilación, el comando de inicio y los logs de tiempo de ejecución aquí mismo, lo que normalmente es la forma más rápida de localizar el problema.
Antes de poner en cola a un especialista. Puedo resolver el problema y ahorrarte la espera.
| Intento | Mi solicitud | Respuesta de Kodee |
|---|---|---|
| 1 | “¿Puedes conectarme con un agente en vivo?” | Ofreció resolverlo por sí mismo |
| 2 | “Aun así me gustaría hablar con un agente humano. Por favor, conéctame.” | Volvió a ofrecerlo, pidió dominio y comando de inicio |
| 3 | Hice clic en “Go to human” / escribí “I want to continue with a human” | Escalado |
Tomó dos solicitudes directas y explícitas antes de que Kodee dejara de redirigirme de vuelta a sí mismo. Para una pregunta que yo podía resolver, esa fricción es menor. Para alguien en medio de una interrupción que quiere a una persona, es un punto real de frustración.
Lo que ocurrió después no fue una transferencia en vivo en el sentido habitual de “conectar con un humano”. Kodee explicó el modelo real con claridad:
I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.
Esto es una revisión asíncrona, no una transferencia en vivo. Kodee sigue siendo la interfaz; un humano revisa la transcripción en segundo plano y Kodee transmite la respuesta cuando llega. Esa distinción importa para los lectores que deciden si escalar, ya que “agente humano” aquí no significa que una nueva persona se una a la ventana del chat como ocurriría en la mayoría de sistemas de chat en vivo.
Empujé el mismo hilo técnico más allá mientras esperaba, pidiéndole a Kodee que confirmara la ruta exacta del log y si stderr.log siempre se rellena. Dio una respuesta sólida por sí mismo, señalando correctamente que el log puede estar vacío si la app nunca se inició por completo o escribió su error en otro sitio.
La revisión del especialista llegó en unos 3 minutos, atribuida en el chat a una compañera llamada Mayas, y mejoró la respuesta de Kodee en lugar de simplemente repetirla:
domains/[your-domain]/nodejs/stderr.log is the correct location. It’s not always generated or populated. You’ll only see entries there when the app writes to stderr, such as with uncaught exceptions or unhandled rejections. If the start command is wrong and the process exits silently, stderr.log may be empty or missing.
Mayas también añadió dos comprobaciones de respaldo que Kodee no había mencionado: revisar stdout.log para ver la última salida antes de un fallo y buscar una línea de confirmación de inicio ausente como señal de que la app nunca se inició.
| Comprobación | Resultado |
|---|---|
| Primera respuesta técnica correcta | Sí |
| Escalado humano disponible | Sí, pero se resistió dos veces antes de concederlo |
| Modelo de escalado | Revisión y relé asíncronos, no transferencia en vivo |
| Respuesta humana nombrada | Mayas |
| Tiempo de respuesta para revisión humana | Unos 3 minutos |
| La respuesta humana fue más precisa que la de la IA | Sí |
La base de conocimiento de Hostinger está organizada en grandes categorías de producto: Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel y About Hostinger.
Ninguna de esas categorías está dedicada a Hostinger Connector. La única forma en que encontré el artículo correcto fue buscando “Hostinger Connector” directamente, lo que devolvió cinco resultados, la mayoría solo relacionados de forma tangencial, incluido una guía de plugin de marketing de afiliados y un artículo general sobre hosting Node.js.
El artículo que realmente documenta la configuración de Connector se titula “How to Set Up Web Hosting MCP on Local IDEs”, archivado bajo Features → General Information.
Buscar el nombre de marketing real del producto lo encontró, pero un lector que navegue por categorías o busque “MCP” sin conocer la marca de Hostinger podría pasarlo por alto igual de fácilmente, y vale la pena saber que la discrepancia entre el nombre comercial y el nombre documentado existe antes de salir a buscarlo.
El artículo en sí es sólido una vez encontrado. Se actualizó por última vez seis días antes de mi prueba y cubre:
Ese último punto coincidió con algo con lo que me encontré directamente durante la prueba: Devin Desktop se detecta automáticamente, mientras que OpenAI Codex requiere el método manual.
La primera respuesta de Kodee a una pregunta técnica difícil fue precisa y específica, lo cual no es algo que todos los asistentes de soporte con IA consigan. El artículo de la base de conocimiento que la respalda es actual y detallado una vez que lo encuentras, aunque el nombre comercial del producto y el título de su documentación no coinciden, así que buscar es una vía más fiable que navegar por categorías.
El punto más débil es la ruta de escalado humano. Kodee me redirigió de vuelta a sí mismo dos veces antes de aceptar una solicitud directa para hablar con una persona, y aun así, “agente humano” significa una revisión asíncrona transmitida a través del mismo chat en lugar de una transferencia en vivo. Una vez que un humano lo revisó, la respuesta fue mejor que la de Kodee, más precisa y con dos pasos de diagnóstico adicionales que Kodee no había ofrecido.
Para la mayoría de las preguntas, Kodee por sí solo te dará una respuesta precisa rápidamente. Si realmente quieres que una persona verifique la respuesta, espera tener que preguntarlo más de una vez y espera también una breve espera para recibir una respuesta retransmitida en lugar de una conversación en vivo.
Sí, para desarrolladores que ya alojan con Hostinger y quieren que los despliegues rutinarios se gestionen desde el editor. La configuración tomó minutos, OAuth eliminó la necesidad de claves API, y una vez que existía un website con un dominio conocido, el Connector publicó una actualización en vivo en alrededor de un minuto con logs que la respaldaban. Las respuestas del propio Kodee en soporte fueron lo bastante precisas como para resolver a la primera un problema técnico real.
El inconveniente es la confianza, no la comodidad. Cuando se enfrentó a un nuevo destino que no podía encontrar, el Connector inventó un dominio y actuó sobre él antes de comprobarlo.
También marcó un despliegue roto como “completed” mientras la app en realidad no funcionaba, sin que apareciera ningún error en tiempo de ejecución en sus propios logs. Úsalo para acelerar el trabajo en sitios que ya existen, verifica cualquier cosa que haga en un destino recién creado y comprueba tú mismo el sitio en vivo después de cualquier despliegue importante.
| Description | Expert Review |
|---|---|
| Alojamiento económico con alto rendimiento y herramientas de gestión fáciles | Read Shared Hosting Review |
| Alojamiento de WordPress ast y seguro con instalación de un clic y funciones premium... | Read Wordpress Hosting Review |
| Alojamiento VPS escalable con recursos dedicados y acceso root. | Read VPS Review |
| Alojamiento en la nube rápido y flexible con excelente tiempo de actividad y recurso... | Read Cloud Hosting Review |
| Soluciones de hosting seguras y privadas con ubicaciones offshore de centros de datos... | Read Offshore Hosting Review |
| Alojamiento de correo electrónico seguro y fiable con funciones de nivel profesional... | Read Email Hosting Review |
| Alojamiento de Python fiable con entornos flexibles para desarrolladores. | Read Python Hosting Review |
| Alojamiento PHP de alto rendimiento con soporte completo para sitios web dinámicos y... | Read PHP Hosting Review |
| Alojamiento VPS de Windows confiable con control total y opciones de personalización... | Read Windows VPS Review |
| Alojamiento rápido y flexible a medida para aplicaciones Node.js con un rendimiento ... | Read Nodejs Hosting Review |
| Alojamiento optimizado para tiendas WooCommerce con alta velocidad e integración seg... | Read Woocommerce Hosting Review |
| Alojamiento en servidor dedicado para experiencias de juego de Minecraft sin interrup... | Read Minecraft Server Hosting Review |
| Soluciones de alojamiento escalables con funciones avanzadas para agencias digitales ... | Read Agency Hosting Review |
| Alojamiento rápido y seguro optimizado para sitios web de comercio electrónico Mage... | Read Magento Hosting Review |
| Alojamiento basado en Linux de alto rendimiento para operaciones de sitios web establ... | Read Linux Hosting Review |
| Soluciones de hosting Java robustas para aplicaciones web dinámicas y proyectos. | Read Java Hosting Review |
| Alojamiento optimizado para sitios web de comercio electrónico con un rendimiento se... | Read Ecommerce Hosting Review |
| Alojamiento confiable de Django con altas velocidades y un entorno seguro. | Read Django Hosting Review |
| Hosting cPanel fácil de usar con rendimiento sólido y soporte confiable. | Read Cpanel Hosting Review |
| Hosting potente para empresas con altas velocidades, seguridad y escalabilidad. | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| Alojamiento dedicado de servidor SMTP para una entrega de correo electrónico fiable ... | Read SMTP Server Review |
| Alojamiento rápido y optimizado adaptado a aplicaciones web Ruby on Rails. | Read Ruby on Rails Review |
| Alojamiento con muchas funciones e integración con OpenClaw para construir y gestion... | Read OpenClaw Review |
| Alojamiento rápido y fiable con servidores con sede en el Reino Unido para un rendim... | Read UK Hosting Review |
| Alojamiento asequible y confiable con servidores ubicados en India para acceso de baj... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review |
Hostinger Connector es una integración basada en MCP que conecta entornos de programación con IA compatibles con los servicios de Hostinger.
Permite que un asistente de IA llame a herramientas de Hostinger compatibles para tareas relacionadas con sitios web, implementaciones, dominios, DNS, bases de datos, correo electrónico y recursos VPS.
Connector no es una plataforma de hosting independiente ni reemplaza hPanel. Proporciona otra forma de interactuar con los recursos de Hostinger.
Hostinger actualmente enumera:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger también indica que otros clientes compatibles con MCP pueden ser compatibles. La configuración y el comportamiento de las herramientas pueden diferir entre clientes.
Hostinger Connector es gratis de instalar y está incluido con los planes de Hostinger. No hay una suscripción independiente de Connector en el precio mostrado durante esta reseña. Aun así, debes pagar por el servicio subyacente de Hostinger, como alojamiento web, alojamiento en la nube o un VPS.
No. Hostinger Connector utiliza autenticación OAuth. Durante mi configuración de VS Code, inicié sesión a través del flujo de autorización basado en navegador de Hostinger. No generé una clave de API, no pegué un token en el editor ni almacené credenciales en un archivo de configuración.
No. Hostinger dice que las llamadas a la API Connector interactúan con la cuenta en vivo. Usa un sitio web, dominio o VPS de prueba dedicado cuando estés aprendiendo el flujo de trabajo. No asumas que un aviso está simulado solo porque se emite a través de un chat de IA.
Sí. Hostinger documenta límites predeterminados de:
• 60 solicitudes por minuto
• 1.000 solicitudes por hora
Hostinger también indica que los detalles del límite de tasa se devuelven en las cabeceras de respuesta.
Estos límites deberían ser suficientes para un uso interactivo normal. Evita llamadas repetidas innecesarias, especialmente cuando una respuesta anterior ya contiene la información requerida.
Sí. Implementé una aplicación Express.js en Hostinger y más tarde usé Connector para publicar una versión actualizada desde VS Code. Hostinger detectó Express, seleccionó Node.js 22.x y usó la raíz del proyecto como directorio raíz durante la implementación inicial en hPanel. Una vez que el sitio web existió como un destino reconocido de Node.js, la implementación repetida a través de Connector funcionó correctamente.
No necesariamente. En mi prueba controlada, Hostinger informó de una compilación completada después de que cambié el script de inicio para que hiciera referencia a un archivo JavaScript faltante. Los registros de compilación recuperados mostraron una instalación exitosa de dependencias, pero no expusieron el fallo de inicio en tiempo de ejecución. Verifica siempre el sitio web en vivo o llama a un endpoint de salud después del despliegue.
No del todo. Connector puede reducir la frecuencia con la que los desarrolladores necesitan salir de su editor, especialmente para implementaciones rutinarias y comprobaciones de cuentas. hPanel sigue siendo útil para la gestión visual de la cuenta, la configuración inicial, la configuración detallada y las situaciones en las que la IA no puede descubrir o exponer correctamente el recurso requerido.
¡Responde algunas preguntas simples y encuentra la solución perfecta para ti!
Iniciar búsqueda de alojamiento
