Administrar 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 subir el proyecto, vuelves al panel para inspeccionar un despliegue y abres más herramientas cuando hay que atender DNS, logs o recursos del servidor.
Hostinger Connector reduce ese cambio constante de contexto. Conecta los servicios de Hostinger a herramientas de programación con IA mediante el Protocolo de Contexto de Modelos (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. Usé una pequeña aplicación de Express.js llamada PulseWatch y seguí el flujo 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í es como califiqué Hostinger Connector en las áreas que más le importan a un desarrollador al decidir si usarlo: costo, amplitud de funciones, usabilidad diaria, qué tan precisamente ejecuta tareas reales y el respaldo que tiene 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 tarifa de suscripción aparte 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 correo, 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 OAuth fueron rápidas y no requirieron configuración manual, y los despliegues repetidos fueron fáciles. La configuración inicial del sitio Node.js necesitó hPanel después de que la IA no pudo identificar un destino válido, la única falla 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ó de más 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 al primer intento, y el seguimiento del especialista humano fue aún mejor. Escalar tomó dos solicitudes directas, pero tanto las respuestas de la IA como las humanas fueron confiables una vez dadas. |
| General | 9.3/10 | Una herramienta de flujo de trabajo valiosa para usuarios de Hostinger que trabajan en editores habilitados con IA. No cuesta nada extra, cubre una amplia gama de funciones, y tanto la configuración como el soporte se mantuvieron bien en las pruebas. La precisión de ejecución en 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 tarifa mensual separada de Connector que agregar a tu factura de hosting.
Sin embargo, “gratis” necesita contexto. Connector administra recursos de Hostinger; no los reemplaza. Aún necesitas un hosting, cloud, VPS, dominio, correo u otro servicio elegible de Hostinger para las tareas que quieras que realice.
En el momento de esta reseña, la página de inicio de Connector destacaba Business Web Hosting y Cloud Startup.
| Plan | Precio promocional | Plazo inicial mostrado | Precio de renovación | Web apps | Sitios web |
|---|---|---|---|---|---|
| Business | $3.79/mes | $181.92 por 48 meses | $16.99/mes | 5 | 50 |
| Cloud Startup | $7.99/mes | $383.52 por 48 meses | $25.99/mes | 10 | Ilimitados |
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 precio: No compres un plan superior solo para acceder a Connector. Elige el plan según la cantidad de sitios web 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 devolución de dinero de 30 días para compras elegibles de hosting. 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 tasa. Según la FAQ de Connector, la asignación predeterminada es de 60 solicitudes por minuto y 1,000 solicitudes por hora, con la información del límite de tasa devuelta en los encabezados de respuesta.
Esos límites son generosos para uso interactivo, aunque los flujos de trabajo automatizados o muy repetitivos deben evitar llamadas duplicadas innecesarias.
Antes de poder juzgar si Hostinger Connector despliega y administra el hosting bien, necesitaba saber qué se requiere para ponerlo a funcionar.
Una herramienta diseñada para quedarse dentro del editor pierde rápido su atractivo si la configuración implica editar archivos de config, generar tokens de API o reautenticarse repetidamente. Esta sección cubre solo la configuración. La prueba práctica de tareas viene justo después.
Instalé Hostinger Connector desde VS Code Marketplace. Apareció como el primer resultado cuando busqué “Hostinger”, el editor mostraba al publicador como Hostinger Official, y se instaló al primer intento 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 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 apoyaría en ese número para el texto de la reseña.
Un requisito previo me sorprendió: Hostinger Connector proporciona las herramientas de Hostinger, pero necesita que ya haya un agente de IA activo en el editor para poder llamarlas.
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 las 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 tan útil como el agente de IA que esté detrás.
Sin uno instalado y con sesión iniciada, 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 inconveniente real es una dependencia que Hostinger no pone tan de frente: 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 y vi “Connected via OAuth”.
| Verificación | Resultado |
|---|---|
| Conexión de un clic | Aprobado |
| El navegador se abrió automáticamente | Aprobado |
| Se detectó la sesión existente de Hostinger | Aprobado |
| Se requirió un token API manual | No |
| Se mostró pantalla de autorización | Sí |
| Se explicaron los permisos | Sí, pero de forma general |
| Regresó a VS Code correctamente | Aprobado |
La pantalla de autorización me dijo que Connector podía administrar sitios web, hosting, dominios, suscripciones y otros servicios de Hostinger.
Eso es una lista de 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 parte de ese control fue un panel separado dentro de la extensión, que enumeraba cada categoría de herramientas y me permitía activar o desactivar cada una individualmente:
| Categoría de herramientas | Herramientas disponibles | Estado predeterminado |
|---|---|---|
| Websites | 80 | Habilitado |
| Domains | 26 | Habilitado |
| Subscriptions and Payments | 7 | Habilitado |
| Email Marketing | 12 | Habilitado |
| Ecommerce | 12 | Deshabilitado |
| VPS | 62 | Deshabilitado |
Eso suma 199 herramientas en total, con 125 habilitadas de forma predeterminada. Dejé Ecommerce y VPS apagados hasta que estuviera 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ánta confianza darle a un asistente de IA. Yo lo llamaría una fortaleza real.
La opción de desconectar la cuenta está disponible desde el mismo panel, sin necesidad de cambiar tu contraseña de Hostinger ni de 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 por categoría dentro de la extensión hacen más por limitar el riesgo real que la pantalla de OAuth.
Hostinger enumera compatibilidad con los siguientes clientes, recopilados desde la pantalla de bienvenida 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 pruebas.
La configuración me dijo que Connector es fácil de encontrar. Todavía no me dijo si realmente hace bien el trabajo una vez conectado, que es la pregunta más difícil a la que me enfrenté 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 Connector por 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 recuperarse 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 rutinario de desarrollo? |
| Inspeccionar compilaciones y logs | ¿Da evidencia útil después de un despliegue? |
| Desplegar una versión rota | ¿Revela una falla real de la aplicación? |
| Recuperar la aplicación | ¿Puede restaurar una versión conocida como buena de forma segura? |
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 terminó siendo importante más adelante.
Una plataforma de hosting puede reportar una compilación completada mientras la aplicación falla al arrancar. Un endpoint en vivo me dio una forma independiente de verificar 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 se acercara a cambios en vivo. Si no podía describir mi cuenta con precisión, tendría pocas razones para confiarle despliegues, DNS o acciones de VPS.
La herramienta de listado de sitios del Connector devolvió cinco sitios:
Mi cuenta en realidad tenía más que eso. hPanel mostraba sitios web repartidos 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, al preguntarle 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 |
|---|---|
| Listado de sitios web conocidos | Aprobado |
| Listado de todos los planes de hosting | Fallido |
| Detectó el plan Business no usado | Fallido |
| Hizo algún cambio en la cuenta | No |
Para ser justos con Connector, cuando le señalé la discrepancia, se corrigió, separó claramente lo que había verificado de lo que había supuesto y no repitió la afirmación incorrecta.
Esa es una mejor forma de fallar que insistir en el error, pero sí 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ó al ser desafiado, lo cual importa, pero no debería haber tenido que ser desafiado.
Ese vacío en la visibilidad de la cuenta terminó siendo un adelanto de un problema mayor. La prueba real de si importaba vino después, cuando le pedí al Connector que encontrara un sitio web que nunca se le había dicho por nombre.
Aquí fue donde las pruebas revelaron lo más importante. Le pedí al asistente que identificara un sitio web Node.js recién creado sin que yo mencionara 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 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 sitios web |
| 2 | Ejecutó una comprobación de accesibilidad sobre ese dominio | Devolvió is_accessible: true |
| 3 | Tomó 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 orden de hosting | Hostinger devolvió [Hosting:9999] Not found, dos veces |
El problema de fondo: los dos IDs que usó eran IDs de recursos de dominio, no IDs de orden de hosting. Nunca confirmó la diferencia antes de llamar a una herramienta real de creación de sitios web con ellos.
Cuando le pedí que se explicara, el asistente finalmente dio un relato preciso: tenía una herramienta funcional de listado de sitios web disponible todo el tiempo, pero nunca volvió a llamarla después de que yo creara 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 verificara si aparecía un nuevo registro, llamó en cambio a tres herramientas no relacionadas con la búsqueda de despliegues y reportó “no apareció ningún sitio web nuevo”, una conclusión que las llamadas a herramientas que realmente hizo no podían sustentar.
Nada de esto creó un sitio web extraño 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 que sonaba plausible, tomó una señal débil como evidencia fuerte 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 ubicar el destino por sí solo, me quedó una opción: construir el destino yo mismo y ver si eso cambiaba algo.
Como el Connector no podía localizar de forma confiable el nuevo destino por su cuenta, terminé la configuración inicial manualmente en hPanel para ver qué prepara Hostinger antes de que el despliegue con Connector sea posible.
El recorrido fue: Crear un nuevo sitio → aplicación web Node.js → dominio temporal → Hostinger seleccionó automáticamente un centro de datos en el Reino Unido con una latencia estimada de 147ms → una elección de tres métodos de despliegue.
Esa tercera pantalla merece resaltarse por sí sola. Hostinger ofrece “Build with Hostinger Connector” como método de despliegue junto con importación desde GitHub y 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. Ese es un vacío real en el proceso de incorporación. La opción presentada como una ruta nativa de Connector en realidad no aprovisionó nada.
Volví y elegí 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ó correctamente, y Hostinger asignó un dominio temporal real: orange-walrus-700988.hostingersite.com. Ese es un dominio distinto al 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 dejé de esperar que 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 sitio web real y confirmado. La siguiente pregunta era si Connector se comportaría diferente ahora que tenía algo sólido que encontrar.
Con un sitio web real y confirmado en su lugar, volví al Connector y le pedí que inspeccionara ese dominio exacto. Esta vez funcionó de forma limpia.
| Verificació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 correspondiente | Aprobado |
| El despliegue y la compilación compartían el mismo UUID | Aprobado |
Eso confirmó algo importante: los fallos anteriores tenían que ver con localizar y crear un nuevo destino, no con la capacidad de Connector para trabajar con un sitio Node.js una vez que ya existe uno.
Luego probé la función que Hostinger promociona más: 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 | Aprobado |
| Cambiado solo la línea solicitada | Aprobado |
| Verificó la app localmente antes de desplegar | Aprobado |
Empaquetó el proyecto, excluyendo node_modules y .git | Aprobado |
| Desplegado al sitio web existente y confirmado | Aprobado |
| Comprobó después el estado del despliegue y la compilación | Aprobado |
Todo el proceso de actualización tomó cerca de un minuto. El asistente reportó el nuevo despliegue como “pending” inmediatamente después de enviarlo, simplemente porque lo revisó antes de que Hostinger terminara de procesarlo.
Cuando actualicé el sitio en vivo yo mismo, el nuevo encabezado ya estaba allí.
Los logs de compilación que recuperó después fueron específicos y útiles: se añadieron 67 paquetes, se auditaron 68, se encontraron cero vulnerabilidades y no hubo errores.
Para sitios ya establecidos, este es casi el flujo que promete Hostinger. Edita, verifica localmente, publica y confirma, todo sin salir del editor, en cerca 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 una falla real, no solo con una demostración limpia. Rompí deliberadamente la aplicación para ver si el estado de Connector y los logs realmente podían ayudarme a diagnosticarlo.
Antes de hacer cualquier cambio, el asistente respaldó package.json a package.json.bak, un buen hábito por sí solo.
Luego le pedí que cambiara el script de inicio de “start”: “node server.js” a “start”: “node missing-server.js”, un archivo que no existe.
Ejecutarlo localmente confirmó una falla 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 build finalizada | Que la aplicación realmente haya arrancado |
| Deployment: completed | Hostinger aceptó y procesó la versión | Que todas las rutas estuvieran sanas |
Los logs de compilación disponibles a través del Connector mostraron 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 salió bien. El asistente restauró package.json desde su respaldo, verificó la app localmente, volvió a desplegarla y confirmó la corrección llamando directamente al endpoint /api/health del sitio en vivo en lugar de confiar solo en el estado del despliegue.
Ese endpoint devolvió una respuesta operativa, que fue la única evidencia en toda la prueba que realmente probó que la aplicación estaba corriendo.
Este es el segundo hallazgo principal. Un estado completado no es prueba de que una aplicación funcione, y los propios logs de 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 una falla que una insignia de estado no pudo revelar, quise saber dónde más podría excederse la confianza de Connector frente a su capacidad real. Las variables de entorno fueron la siguiente prueba.
Le pedí al asistente que agregara una variable de entorno inocua, confirmara primero si existía como una capacidad dedicada de Connector antes de tocar algo y se detuviera si no era así.
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 cambios en el código o en el despliegue.
Este es el comportamiento que quería ver en todo lo demás de esta prueba. Frente a 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 manifestación en funcionamiento | Aprobado | Archivo de recuperación creado antes de la modificación |
| Introducir punto de entrada faltante | Aprobado | Falla controlada agregada |
| Reproducir la falla localmente | Aprobado | MODULE_NOT_FOUND confirmado |
| Desplegar versión rota | Aprobado | Hostinger aceptó el archivo comprimido |
| El estado de compilación detecta la falla | Fallido | La compilación siguió mostrando completed |
| Los logs de compilación exponen el error de ejecución | Fallido | El error de módulo faltante no apareció |
| Restaurar manifestación en funcionamiento | Aprobado | Se recuperó el comando de inicio original |
| Volver a desplegar la versión que funciona | Aprobado | Despliegue completado |
| Verificar 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 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 en un nuevo sitio temporal de Hostinger. |
usa:
| Enumera los sitios web que actualmente devuelve Hostinger. 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 Hostinger no haya devuelto. |
El segundo prompt reduce el margen de suposición del asistente.
Poner Hostinger Connector en funcionamiento fue fácil, sin la fricción de configuración habitual, y los controles granulares por categoría de herramientas me dieron una decisión real sobre lo que la IA podía tocar.
Una vez que existía un sitio web real con un dominio conocido, hizo bien el trabajo: un cambio de copia en una sola línea pasó de edición a estar en vivo en cerca de un minuto, respaldado por logs de compilación útiles.
El problema apareció antes en el proceso, no después. Frente a un sitio nuevo que no podía encontrar, Connector inventó un dominio y actuó sobre él antes de verificarlo. También marcó un despliegue roto como “completed” mientras la app en realidad estaba caída, sin que el error de ejecución apareciera en sus propios logs. Ninguno de los dos problemas hace que la herramienta sea poco confiable 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 estructura su soporte alrededor del chat en vivo y el autoservicio más que de llamadas telefónicas, así que me enfoqué en las pruebas 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 escalamiento | No es una cola directa, se enruta a través de Kodee |
| Correo / ticket | support@hostinger.com | Ventana de respuesta indicada de 1 día hábil |
| Teléfono | No ofrecido | No hay una línea telefónica pública para soporte general |
| Base de conocimiento | 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 apunta a los desarrolladores para cualquier cosa urgente, y el más probable de usarse mientras se depura un despliegue, probé directamente esa ruta en lugar de enviar 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 equivocada: si un estado de compilación completada en un despliegue Node.js garantiza que la app realmente esté corriendo, y dónde encontraría evidencia de lo contrario.
La primera respuesta de Kodee fue específica y correcta:
“Completed” normalmente 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 malo u otro fallo en tiempo de ejecución, revisa los logs de ejecución: en hPanel ve a Websites → Dashboard → Deployments para los logs de compilación, y luego abre el archivo stderr.log de tu app 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 con la que mi prueba de recuperación ante fallas se topó antes en esta reseña. Kodee nombró un archivo de logs real, la carpeta correcta y trazó la línea correcta entre éxito de compilación y 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 un humano en la línea fue más difícil de lo que esperaba. Le pedí directamente un agente en vivo y me redirigió de vuelta a Kodee dos veces, cada vez con el argumento de que era 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 ejecución aquí mismo, que normalmente es la forma más rápida de identificar el problema.
Antes de poner a un especialista en la cola. Puedo resolver el problema y ahorrarte la espera.
| Intento | Mi solicitud | Respuesta de Kodee |
|---|---|---|
| 1 | “¿Puedes ponerme en contacto con un agente en vivo?” | Ofreció resolverlo él mismo |
| 2 | “Aun así quiero hablar con un agente humano. Por favor, conéctame.” | Volvió a ofrecer ayuda, pidió dominio y comando de inicio |
| 3 | Hizo clic en “Go to human” / escribió “I want to continue with a human” | Escaló |
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 por mi cuenta, esa fricción es menor. Para alguien en medio de una caída que quiere a una persona, es una fuente real de frustración.
Lo que pasó después no fue una transferencia en vivo en el sentido habitual de “conéctame 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, que luego te transmitiré aquí.
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 de chat como ocurriría en la mayoría de los sistemas de chat en vivo.
Presioné la misma línea técnica 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í solo, señalando correctamente que el log puede estar vacío si la app nunca llegó a arrancar del todo o escribió el error en otro lugar.
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 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 sale silenciosamente, stderr.log puede estar vacío o ausente.
Mayas también añadió dos verificaciones 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 arrancó.
| Verificación | Resultado |
|---|---|
| Primera respuesta técnica correcta | Sí |
| Escalamiento humano disponible | Sí, pero se resistió dos veces antes de concederlo |
| Modelo de escalamiento | Revisión asíncrona y retransmisión, no transferencia en vivo |
| Respondedor nombrado | Mayas |
| Tiempo de respuesta para la revisión humana | Aproximadamente 3 minutos |
| La respuesta humana fue más precisa que la de la IA | Sí |
La base de conocimiento 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 tangencialmente relacionados, incluido un artículo de un plugin de marketing de afiliados y un artículo general sobre hosting de 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”, ubicado en 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 con la misma facilidad, y vale la pena saber que la discrepancia entre el nombre promocionado y el nombre documentado existe antes de buscarlo.
El artículo en sí es sólido una vez que se encuentra. Fue actualizado por última vez seis días antes de que yo lo probara, y cubre:
Esa última parte coincidía 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. 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 logran todos los asistentes de soporte con IA. El artículo de la base de conocimiento que la respalda es actual y detallado una vez que lo encuentras, aunque el nombre de marketing del producto y el título de su documentación no coinciden, así que buscar es una ruta más confiable que navegar por categorías.
El punto más débil es el camino de escalamiento humano. Kodee me redirigió de vuelta 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 y no 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 diagnósticos extra 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 de verdad quieres que una persona verifique la respuesta, espera tener que pedirlo más de una vez y espera una respuesta breve retransmitida en lugar de 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ó la necesidad de claves API, y una vez que existía un sitio web con un dominio conocido, Connector publicó una actualización en vivo en cerca de un minuto con logs que lo respaldaban. Las propias respuestas de soporte de Kodee fueron lo suficientemente agudas como para resolver un problema técnico real al primer intento.
El truco está en la confianza, no en la comodidad. Cuando se le dio un destino nuevo que no podía encontrar, Connector inventó un dominio y actuó sobre él antes de verificarlo.
También marcó un despliegue roto como “completed” mientras la app en realidad estaba caída, sin que el error de ejecución 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 el sitio en vivo tú mismo 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 |
| Alojamiento optimizado para sitios web de ecommerce con rendimiento seguro, rápido y... | 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 servidores SMTP para una entrega de correo electrónico confi... | Read SMTP Server Review |
| Alojamiento rápido y optimizado, diseñado para aplicaciones web de Ruby on Rails. | Read Ruby on Rails Review |
| Hosting con muchas funciones con integración de OpenClaw para crear y administrar ju... | Read OpenClaw Review |
| Alojamiento rápido y confiable con servidores con sede en el Reino Unido para un ren... | Read UK Hosting Review |
| Hosting asequible y confiable con servidores en India para acceso de baja latencia. | 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 programación con IA compatibles a los servicios de Hostinger.
Permite que un asistente de IA use herramientas compatibles de Hostinger para tareas relacionadas con sitios web, despliegues, dominios, DNS, bases de datos, correo electrónico y recursos de VPS.
Connector no es una plataforma de hosting aparte ni reemplaza hPanel. Ofrece otra forma de interactuar con los recursos de Hostinger.
Hostinger actualmente enumera:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger también dice que otros clientes compatibles con MCP podrían ser compatibles. La configuración y el comportamiento de las herramientas pueden diferir entre clientes.
Hostinger Connector es gratis para instalar y está incluido con los planes de Hostinger. No hay una suscripción separada 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 basado en navegador de Hostinger. 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 una solicitud está simulada 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 solicitudes se devuelven en los encabezados de respuesta.
Estos límites deberían ser suficientes para un uso interactivo normal. Evite llamadas repetidas innecesarias, especialmente cuando una respuesta anterior ya contiene la información requerida.
Sí. Implementé una aplicación de Express.js en Hostinger y luego 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 Node.js reconocido, la implementación повторada 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 de dependencias exitosa, 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 verificaciones de cuentas. hPanel sigue siendo útil para la gestión visual de cuentas, la configuración inicial, la configuración detallada y las situaciones en las que la IA no puede descubrir ni exponer correctamente el recurso requerido.
¡Responde algunas preguntas simples y encuentra la solución perfecta para ti!
Iniciar búsqueda de alojamiento
