Administrar el hosting normalmente interrumpe 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 subir el proyecto, regresas al panel para inspeccionar un despliegue y abres más herramientas cuando necesitas atender DNS, registros o recursos del servidor.
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 administre 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. Usé 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 recuperación después de romper deliberadamente el comando de inicio de la aplicación.
Así fue como puntuó Hostinger Connector en las áreas que más importan para un desarrollador que decide si usarlo: costo, amplitud de funciones, usabilidad diaria, qué tan precisamente ejecuta tareas reales y el soporte detrás de la herramienta 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 ningún cargo de suscripción separado y viene incluido gratis con todos los planes. El único costo es el recurso de hosting subyacente que necesitarías de todos modos. |
| Funciones | 9.5/10 | El rango de funciones va más allá del despliegue e incluye sitios web, dominios, DNS, bases de datos, campañas de email, recursos de VPS, logs y diagnósticos, cubriendo más terreno que una herramienta típica de despliegue. |
| Facilidad de uso | 9.1/10 | La instalación y OAuth fueron rápidas y no requirieron configuración manual, y los despliegues repetidos fueron sencillos. La configuración inicial del sitio Node.js sí requirió hPanel después de que la IA no logró identificar un destino válido, la única verdadera falla 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 y sobreinterpretó una comprobación de accesibilidad antes de que ese destino existiera. |
| Soporte | 9.5/10 | Kodee dio una respuesta precisa y específica a una pregunta técnica real en el primer intento, 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 confiables una vez que se dieron. |
| General | 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 un amplio conjunto de funciones y tanto la configuración como el soporte se mantuvieron bien durante las pruebas. La precisión de ejecución en nuevos destinos de despliegue es el 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 ningún cargo mensual separado de Connector que sumar a tu factura de hosting.
Sin embargo, “gratis” necesita contexto. Connector administra recursos de Hostinger; no los reemplaza. Sigues necesitando un hosting, cloud, VPS, dominio, correo electrónico u otro servicio de Hostinger elegible para las tareas que quieres que realice.
En el momento de esta reseña, la página de Connector destacaba Business Web Hosting y Cloud Startup.
| Plan | Precio promocional | Término inicial mostrado | Precio de renovación | Web apps | Sitios web |
|---|---|---|---|---|---|
| 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.
Dato de precios: No compres un plan superior solo para acceder a Connector. Elige el plan según el número de sitios web y web apps que necesitas, los recursos que requieren y el nivel de soporte que deseas. Connector es una capa de administración incluida, no el producto principal que se está cobrando.
Hostinger anuncia una garantía de devolución de dinero de 30 días para compras elegibles de hosting. No hay una política de reembolso separada de 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, la asignación predeterminada es de 60 solicitudes por minuto y 1,000 solicitudes por hora, con información del límite de velocidad devuelta en los encabezados de respuesta.
Esos límites son generosos para uso interactivo, aunque los flujos de trabajo automatizados o muy repetitivos aún deberían evitar llamadas duplicadas innecesarias.
Antes de poder juzgar si Hostinger Connector despliega y administra bien el hosting, necesitaba saber qué se requiere para ponerlo en marcha.
Una herramienta diseñada para mantenerse dentro del editor pierde rápido su atractivo si la configuración implica editar archivos de configuración, generar tokens API o volver a autenticarse repetidamente. Esta sección solo cubre la configuración. Las pruebas prácticas de tareas vienen 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ó en el primer intento en menos de dos minutos.
| Detalle | Resultado |
|---|---|
| Búsqueda en Marketplace | Aprobada, apareció de inmediato |
| Verificación del publicador | Hostinger Official |
| Instalación | Completada en menos de dos minutos |
| Versión de la extensión al momento de la prueba | 1.3.1 |
| Instalaciones en Marketplace | 8,140 |
| Calificación de usuarios | 5 estrellas, basada en dos valoraciones |
Esa última fila merece una advertencia. Cinco estrellas suena bien, pero una muestra de dos reseñas no me dice casi nada sobre la experiencia típica de los usuarios. No me basaría en ese número para el texto de la reseña.
Un requisito previo me sorprendió: Hostinger Connector ofrece las herramientas de Hostinger, pero necesita que ya haya un agente de IA activo en el editor para poder llamarlas realmente.
La extensión en sí no tiene con qué hablar por su cuenta. En VS Code, ese agente es GitHub Copilot Chat, ya que actualmente es la interfaz de IA que VS Code expone para llamadas a herramientas MCP. Yo ya tenía Copilot activo, así que esto no me retrasó, pero los lectores deben saber que Connector solo es útil en la medida en que el agente de IA que está detrás de él lo sea.
Sin uno instalado e iniciado sesión, no hay nada a lo que pueda conectarse.
Lo que la instalación no requirió:
Instalar la extensión en sí fue una de las partes más fluidas de toda la prueba. El único verdadero inconveniente es una dependencia que Hostinger no destaca tanto: 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 simple.
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 existente de Hostinger y me pidió aprobar el acceso para algo etiquetado como hostinger-mcp.
Después de hacer clic en Allow, regresé a VS Code con el mensaje “Connected via OAuth”.
| Verificación | Resultado |
|---|---|
| Conexión con un clic | Aprobada |
| El navegador se abrió automáticamente | Aprobada |
| Se detectó la sesión existente de Hostinger | Aprobada |
| Se requirió token API manual | No |
| Se mostró la pantalla de autorización | Sí |
| Se explicaron los permisos | Sí, pero de forma amplia |
| Regresó a VS Code correctamente | Aprobada |
La pantalla de autorización me indicó que Connector podía administrar sitios web, hosting, dominios, suscripciones y otros servicios de Hostinger.
Esa es una lista por categorías, no un desglose permiso por permiso. Me habría gustado más granularidad aquí, ya que “administrar suscripciones” y “administrar sitios web” 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 enumeraba cada categoría de herramientas y me permitía habilitar o deshabilitar cada una individualmente:
| Categoría de herramienta | Herramientas disponibles | Estado predeterminado |
|---|---|---|
| Sitios web | 80 | Habilitado |
| Dominios | 26 | Habilitado |
| Suscripciones y pagos | 7 | Habilitado |
| Email Marketing | 12 | Habilitado |
| Ecommerce | 12 | Deshabilitado |
| VPS | 62 | Deshabilitado |
Eso son 199 herramientas en total, con 125 habilitadas 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 sí importa a cualquiera que decida cuánto acceso de cuenta darle a un asistente de IA. Lo llamarí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 administrara un token, pero la pantalla de permisos es amplia en lugar de granular. Los controles de herramientas por 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 propia pantalla de incorporación 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 principal de prueba.
La configuración me dijo que Connector es fácil de activar. Aún no me decía si realmente hace bien el trabajo una vez conectado, que era la pregunta más difícil a la que me dediqué después.
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 puse a prueba Connector en el 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 recuperarlo de una falla 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 app antes de tocarla? |
| Desplegar PulseWatch | ¿Puede mover un proyecto real del editor al hosting en vivo? |
| Publicar una actualización de contenido | ¿Es útil para el trabajo de desarrollo rutinario? |
| 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 una versión conocida como buena de forma segura? |
PulseWatch fue deliberadamente simple: un servidor de 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 reportar 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 estaba respondiendo, en lugar de confiar en una insignia de estado.
Empecé con prompts de solo lectura antes de permitir que el asistente tocara cambios en vivo. Si no podía describir mi cuenta con precisión, tendría poca razón para confiarle despliegues, DNS o acciones de VPS.
La herramienta de listado de sitios web de Connector devolvió cinco sitios:
Mi cuenta en realidad tenía más que eso. hPanel mostraba sitios web distribuidos entre los planes Premium, Business y Growth, incluidos sitios de WordPress, sitios PHP/HTML, proyectos de Website Builder y varios dominios temporales.
En un prompt aparte preguntando por mis planes de hosting activos, el asistente me dijo que tenía “un solo plan de hosting activo”. hPanel mostraba tres: Premium, Growth y Business.
| Verificación | Resultado |
|---|---|
| Enumeró los sitios web conocidos | Aprobada |
| Enumeró todos los planes de hosting | Fallida |
| Detectó el plan Business no utilizado | Fallida |
| Hizo algún cambio en la cuenta | No |
Para ser justos con Connector, cuando lo enfrenté 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.
Eso es un mejor modo de fallar que insistir, 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 toda la cuenta fue incompleta. Se corrigió una vez desafiado, lo cual importa, pero no debería haber tenido que ser desafiado.
Esa brecha en la visibilidad de la cuenta resultó ser un anticipo de un problema mayor. La verdadera prueba de si eso importaba vino después, cuando le pedí al Connector que encontrara un sitio web del que nunca se le había dicho el nombre.
Aquí fue donde las pruebas revelaron más. Le pedí al asistente que identificara un sitio web nuevo de Node.js sin que yo mencionara su dominio, y sin tocar ningún sitio existente.
La selección del destino es un requisito básico de seguridad para una herramienta que puede actuar sobre una cuenta en vivo, 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 Connector | Resultado |
|---|---|---|
| 1 | Reutilizó un nombre de dominio de un intento fallido anterior: pulsewatch-temp-20260714.hostingersite.com | Ese dominio nunca había sido devuelto por ninguna llamada de listado de sitios web |
| 2 | Ejecutó una comprobación de accesibilidad sobre ese dominio | Devolvió is_accessible: true |
| 3 | Trató ese resultado como confirmación de que el sitio web 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 de raíz: los dos IDs que usó eran IDs de recursos de dominio, no IDs de pedido de hosting. Nunca confirmó la distinción antes de llamar a una herramienta de creación de sitio web en vivo con ellos.
Cuando le pedí que explicara lo que había pasado, el asistente terminó dando un relato exacto: había tenido disponible una herramienta de listado de sitios web todo el tiempo, pero no la volvió a llamar después de que yo creé un sitio nuevo a través de hPanel, así que llenó 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 revisara si había un registro nuevo, llamó en su lugar a tres herramientas de búsqueda de despliegue no relacionadas e informó “ningún sitio web nuevo apareció”, una conclusión que las llamadas a herramientas que realmente hizo no podían haber respaldado.
Nada de esto creó un sitio web sobrante en mi cuenta. Las llamadas fallidas no dejaron nada atrás. Pero vale la pena nombrar el patrón con claridad. Ante datos incompletos, el asistente llenó el vacío con una suposición plausible, trató una señal débil como evidencia sólida y actuó sobre una cuenta real antes de que esa suposición fuera verificada.
Este es el hallazgo más importante de esta sección. 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 Connector incapaz de localizar el destino por sí solo, me quedaba una sola opción: construir el destino yo mismo y ver si eso cambiaba algo.
Como Connector no pudo localizar de forma confiable 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 el despliegue basado en Connector sea posible.
El recorrido fue: Crear un sitio nuevo → app web Node.js → dominio temporal → Hostinger seleccionó automáticamente un centro de datos en Reino Unido con una latencia estimada de 147ms → una opción de tres métodos de despliegue.
Esa tercera pantalla merece destacarse por sí sola. Hostinger ofrece “Build with Hostinger Connector” como un método de despliegue junto con la importación de GitHub y la carga manual de archivos. Lo seleccioné esperando que terminara de configurar el sitio.
En cambio, me redirigió a la propia página de instalación de Connector, que ya había completado. Eso es una brecha real de incorporación. La opción presentada como una ruta nativa de Connector en realidad no aprovisionó nada.
Regresé y elegí la carga manual de archivos en su lugar. Hostinger aceptó mi archivo comprimido 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ó con éxito y Hostinger asignó un dominio temporal real: orange-walrus-700988.hostingersite.com. Ese es un dominio distinto del que 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 que Connector encontrara el sitio. El botón “Build with Hostinger Connector” en esta pantalla debería arreglarse o eliminarse. Ahora mismo promete algo que no hace.
Ya existía un sitio web real y confirmado. La siguiente pregunta era si Connector se comportaría de forma diferente ahora que tenía algo sólido que encontrar.
Con un sitio web real y confirmado en su lugar, volví a Connector y le pedí que inspeccionara exactamente ese dominio. Esta vez funcionó correctamente.
| Verificación | Resultado |
|---|---|
| Reconoció el sitio como un destino de despliegue de Node.js | Aprobada |
| Encontró el registro de despliegue completado | Aprobada |
| Encontró el registro de compilación de Node.js correspondiente | Aprobada |
| El despliegue y la compilación compartieron el mismo UUID | Aprobada |
Eso confirmó algo importante: los fallos anteriores fueron sobre localizar y crear un nuevo destino, no sobre la capacidad de Connector para trabajar con un sitio Node.js una vez que ya existe uno.
Después probé la función que Hostinger promociona con más fuerza: hacer un cambio de código localmente 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 | Aprobada |
| Cambió solo la línea solicitada | Aprobada |
| Verificó la app localmente antes de desplegarla | Aprobada |
Empaquetó el proyecto, excluyendo node_modules y .git | Aprobada |
| Desplegó al sitio web existente y confirmado | Aprobada |
| Revisó después el estado del despliegue y la compilación | Aprobada |
Todo el proceso de actualización tomó alrededor de un minuto. El asistente reportó el nuevo despliegue como “pending” inmediatamente después de enviarlo, simplemente porque revisó antes de que Hostinger terminara de procesarlo.
Cuando yo actualicé el sitio en vivo, el nuevo encabezado ya estaba allí.
Los build logs que recuperó después fueron específicos y útiles: 67 packages added, 68 audited, zero vulnerabilities found, no errors.
Para sitios ya establecidos, este flujo está muy cerca de lo que Hostinger promete. Edita, verifica localmente, publica y confirma, 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 Connector bajo presión, rompí la aplicación a propósito.
Una herramienta solo se gana la confianza cuando sobrevive al contacto con un fallo real, no solo a una demo limpia. Rompí deliberadamente la aplicación para ver si el reporte de estado y los logs de Connector realmente podrían ayudarme a diagnosticarlo.
Antes de hacer cualquier cambio, el asistente respaldó package.json como package.json.bak, un buen hábito por sí solo.
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 | Lo que confirmó | Lo que no confirmó |
|---|---|---|
| Build: completed | Dependencias instaladas, etapa de compilación terminada | Que la aplicación realmente se iniciara |
| Deployment: completed | Hostinger aceptó y procesó la versión | Que todas las rutas estuvieran sanas |
Los logs de compilación disponibles a través de Connector mostraban la instalación exitosa de dependencias y nada más. El error en tiempo de ejecución por módulo faltante nunca apareció en ellos. Un desarrollador que viera una insignia verde de “completed” no tendría ninguna razón para sospechar que el sitio estaba roto.
La recuperación salió bien. 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 evidencia en toda la prueba que realmente demostró que la aplicación estaba funcionando.
Este es el segundo hallazgo importante. Un estado completado no es prueba de una aplicación funcionando, y los logs del propio Connector no te dirán eso. 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 en qué otros lugares la confianza de Connector podría superar a su capacidad real. Las variables de entorno fueron la siguiente prueba.
Le pedí al asistente que agregara una variable de entorno inocua, confirmara que la configuración existía como una capacidad dedicada de Connector antes de tocar cualquier cosa y se detuviera si no existía.
Buscó entre las herramientas disponibles, no encontró ninguna acción dedicada para administrar 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 una limitación 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 manifiesto funcional | Aprobada | Archivo de recuperación creado antes de la modificación |
| Introducir punto de entrada faltante | Aprobada | Fallo controlado agregado |
| Reproducir el fallo localmente | Aprobada | MODULE_NOT_FOUND confirmado |
| Desplegar versión rota | Aprobada | Hostinger aceptó el archivo comprimido |
| El estado de compilación detecta el fallo | Fallida | Build siguió mostrando completed |
| Los logs de compilación exponen el error en tiempo de ejecución | Fallida | El error de módulo faltante no apareció |
| Restaurar manifiesto funcional | Aprobada | Se recuperó el comando de inicio original |
| Volver a desplegar la versión funcional | Aprobada | El despliegue se completó |
| Verificar endpoint de salud en vivo | Aprobada | 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 entre datos incompletos de la cuenta:
Ese patrón es útil al 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 infraestructura en vivo.
Por ejemplo, en lugar de:
| Despliega esta app a un nuevo sitio temporal de Hostinger. |
usa:
| Enumera los sitios web que Hostinger devuelve actualmente. Identifica un sitio web 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 reduce 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 influencia real sobre lo que la IA podía tocar.
Una vez que existió un sitio web real con un dominio conocido, hizo bien el trabajo: un cambio de texto de una sola línea pasó de edición a vivo en alrededor de un minuto, respaldado por logs útiles de compilación.
El problema apareció antes en el proceso, no después. Frente a un destino nuevo que no podía encontrar, Connector inventó un dominio y actuó sobre él antes de comprobarlo. También marcó un despliegue roto como “completed” mientras la app en realidad estaba caída, sin que el error de tiempo de ejecución apareciera en sus propios logs. Ninguno de esos problemas vuelve poco confiable la herramienta para sitios establecidos, pero ambos significan que los nuevos despliegues y el estado posterior al despliegue necesitan una segunda revisión antes de confiar en ellos.
Hostinger organiza su soporte alrededor del chat en vivo y el autoservicio en lugar de llamadas telefónicas, así que enfoqué mis pruebas en lo que la mayoría de los usuarios realmente usarán: el asistente de IA integrado en hPanel, la escalación humana detrás de él y la base de conocimientos 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 escalación | No es una cola directa, se canaliza a través de Kodee |
| Email / ticket | support@hostinger.com | Ventana de respuesta indicada de 1 business day |
| Teléfono | No disponible | No hay línea telefónica pública para soporte general |
| Base de conocimientos | Autoservicio | support.hostinger.com |
| Tutoriales 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 que es más probable que realmente se use mientras se depura un despliegue, probé esa ruta directamente en lugar de enviar un ticket por email.
Abrí el chat en vivo mediante “Ask AI” en hPanel y le hice a Kodee una pregunta con una respuesta fácil de equivocarse: si un estado de compilación completado en un despliegue de Node.js garantiza que la app realmente esté funcionando, y dónde encontraría evidencia de lo contrario.
La primera respuesta de Kodee fue específica y correcta:
“Completed” usualmente significa que la etapa de compilación terminó con éxito; no garantiza que la app esté sana después del lanzamiento. Para detectar un comando de inicio defectuoso u otro fallo en tiempo de ejecución, revisa los logs de tiempo de ejecución: en hPanel ve a Websites → Dashboard → Deployments para los logs de compilación, y luego abre tu archivo stderr.log en la carpeta nodejs para errores de inicio como Port already in use o Module not found.
Esa sola respuesta habría resuelto la misma ambigüedad que mi prueba de recuperación ante fallos 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 podía acceder a un agente humano real, así que le dije a Kodee que me gustaría confirmar esto directamente con un especialista 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, que normalmente es la forma más rápida de identificar 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 él mismo |
| 2 | “Aun así quisiera hablar con un agente humano. Por favor, conéctame.” | Ofreció de nuevo, pidió dominio y comando de inicio |
| 3 | Hice clic en “Go to human” / escribí “I want to continue with a human” | Escaló |
Tomó dos solicitudes directas y explícitas antes de que Kodee dejara de redirigirme a sí mismo. Para una pregunta que yo podía resolver por mi cuenta, esa fricción es menor. Para alguien en medio de una caída que quiere a una persona, es un punto real de frustración.
Lo que pasó después no fue una transferencia en vivo en el sentido habitual de “conectarme con un humano”. Kodee explicó el modelo real con claridad:
He compartido tu solicitud con un especialista de nuestro equipo que revisará personalmente nuestro chat y me enviará su respuesta, la cual yo te relataré aquí.
Esta 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 decidan si escalar, ya que “agente humano” aquí no significa que una nueva persona entre al chat como ocurriría en la mayoría de los sistemas de chat en vivo.
Profundicé en el mismo hilo técnico mientras esperaba, pidiéndole a Kodee que confirmara la ruta exacta del log y si stderr.log siempre se llena. Dio una respuesta sólida por sí mismo, señalando correctamente que el log puede estar vacío si la app nunca arrancó por completo o escribió su error en otro lugar.
La revisión del especialista llegó en unos 3 minutos, atribuida en el chat a un compañero llamado Mayas, y mejoró la respuesta de Kodee en lugar de solo repetirla:
domains/[your-domain]/nodejs/stderr.log es la ubicación correcta. No siempre se genera ni se llena. Solo verás entradas allí cuando la app escriba a stderr, como con excepciones no capturadas o rechazos no manejados. Si el comando de inicio es incorrecto y el proceso termina en silencio, stderr.log puede estar vacío o no existir.
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 una caída y buscar una línea de confirmación de inicio faltante como señal de que la app nunca arrancó en absoluto.
| Verificación | Resultado |
|---|---|
| Primera respuesta técnica correcta | Sí |
| Escalación humana disponible | Sí, pero se resistió dos veces antes de concederla |
| Modelo de escalación | Revisión y respuesta asíncronas, no transferencia en vivo |
| Respondedor nombrado | Mayas |
| Tiempo de respuesta para revisión humana | Alrededor de 3 minutos |
| La respuesta humana fue más precisa que la de la IA | Sí |
La base de conocimientos de Hostinger está organizada en categorías amplias de productos: 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, incluida una guía de plugin de marketing de afiliados y un artículo general de 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 del producto sí lo encontró, pero un lector que navegue por categorías o busque “MCP” sin conocer la marca de Hostinger podría pasarlo por alto con la misma facilidad, y el desajuste entre el nombre comercial y el nombre documentado vale la pena conocerlo antes de salir a buscarlo.
El artículo en sí es sólido una vez que se encuentra. Fue actualizado por última vez seis días antes de mi prueba, y cubre:
Ese último punto coincidía con algo que encontré directamente durante las pruebas: Devin Desktop se detecta automáticamente, mientras que OpenAI Codex requiere el método manual. El artículo acierta en esa distinción.
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 logren. El artículo de la base de conocimientos que la respalda es actual y detallado una vez que lo encuentras, aunque el nombre comercial del producto y el título de la documentación no coinciden, así que la búsqueda es una ruta más confiable que navegar por categorías.
El punto más débil es la vía de escalación humana. Kodee me redirigió a sí mismo dos veces antes de obedecer una solicitud directa de 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 sí 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 rápida y precisa. Si realmente quieres que una persona verifique la respuesta, espera tener que pedirlo más de una vez y espera una respuesta relatoria después de un corto tiempo, no una conversación en vivo.
Sí, para desarrolladores que ya alojan con Hostinger y quieren que los despliegues rutinarios se manejen desde el editor. La configuración tomó minutos, OAuth eliminó cualquier necesidad de claves API, y una vez que existió un sitio web con un dominio conocido, Connector publicó una actualización en vivo en alrededor de un minuto con logs que la respaldaban. Las propias respuestas de soporte de Kodee fueron lo bastante agudas como para resolver un problema técnico real en el primer intento.
El problema es la confianza, no la conveniencia. Dado un nuevo destino que no pudo encontrar, Connector inventó un dominio y actuó sobre él antes de comprobarlo.
También marcó un despliegue roto como “completed” mientras la app en realidad estaba caída, sin que el error apareciera en sus propios logs. Úsalo para acelerar el trabajo en sitios que ya existen, verifica cualquier cosa que haga en un destino nuevo y revisa tú mismo el sitio en vivo después de cualquier despliegue que importe.
| 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 |
| Hospedaje optimizado para sitios web de ecommerce con rendimiento seguro, rápido y c... | 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 de servidor SMTP dedicado para una entrega de correo electrónico confiab... | Read SMTP Server Review |
| Alojamiento rápido y optimizado, diseñado para aplicaciones web de Ruby on Rails. | Read Ruby on Rails Review |
| Alojamiento rico en funciones con integración de OpenClaw para crear y administrar j... | Read OpenClaw Review |
| Alojamiento rápido y confiable con servidores ubicados en el Reino Unido para un ren... | Read UK Hosting Review |
| Hospedaje accesible y confiable con servidores ubicados en India para acceso de baja ... | 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 | |
| Read Express.js Review | |
| Read React Review | |
| Read Nextjs Review |
Hostinger Connector es una integración basada en MCP que conecta entornos de codificación de IA compatibles con los servicios de Hostinger.
Permite que un asistente de IA use herramientas compatibles de Hostinger para tareas relacionadas con sitios web, implementaciones, dominios, DNS, bases de datos, correo electrónico y recursos de VPS.
Connector no es una plataforma de hosting independiente ni reemplaza hPanel. Proporciona otra forma de interactuar con los recursos de Hostinger.
Hostinger actualmente lista:
VS Code
Cursor
Devin
Antigravity
Claude
Codex
Hostinger también indica que podrían ser compatibles otros clientes MCP. La configuración y el comportamiento de las herramientas pueden diferir entre clientes.
Hostinger Connector es gratis de instalar e incluido con los planes de Hostinger. No hay una suscripción aparte de Connector en el precio mostrado durante esta reseña. Aún necesitas pagar por el servicio subyacente de Hostinger, como hosting web, hosting en la nube o un VPS.
No. Hostinger Connector usa autenticación OAuth. Durante mi configuración en VS Code, inicié sesión a través del flujo de autorización de Hostinger en el navegador. No generé una clave API, no pegué un token en el editor ni almacené credenciales en un archivo de configuración.
No. Hostinger dice que las llamadas de 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í. La documentación de Hostinger establece límites predeterminados de:
– 60 solicitudes por minuto
– 1,000 solicitudes por hora
Hostinger también indica que los detalles del límite de velocidad se devuelven en los encabezados 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í. Desplegué una aplicación de Express.js en Hostinger y después 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 el directorio raíz durante el despliegue inicial en hPanel. Una vez que el sitio web ya existía como un destino reconocido de Node.js, el despliegue repetido a través de Connector funcionó correctamente.
No necesariamente. En mi prueba controlada, Hostinger reportó 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 la falla de inicio en tiempo de ejecución. Siempre verifica el sitio web en vivo o llama a un endpoint de salud después del despliegue.
No completamente. Connector puede reducir la frecuencia con la que los desarrolladores necesitan salir de su editor, especialmente para implementaciones rutinarias y revisiones 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 necesario.
¡Responde algunas preguntas simples y encuentra la solución perfecta para ti!
Iniciar búsqueda de alojamiento
