Administrar el hosting suele interrumpir el desarrollo. Escribís código en un editor, abrís un panel de hosting para crear un sitio web, cambiás a una terminal para empaquetar o subir el proyecto, volvés al panel para inspeccionar un despliegue y abrís más herramientas cuando hay que atender DNS, logs o recursos del servidor.
Hostinger Connector reduce ese cambio de contexto. Conecta los servicios de Hostinger con 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: ¿Se puede 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 contra una cuenta real de Hostinger. Usé una pequeña aplicación Express.js llamada PulseWatch y seguí el flujo desde la instalación hasta el despliegue en vivo. También probé despliegues repetidos, registros de build, logs y la recuperación después de romper deliberadamente el comando de inicio de la aplicación.
Así es como puntuó Hostinger Connector en las áreas que más importan para un desarrollador que decide si usarlo: costo, variedad de funciones, usabilidad diaria, qué tan bien ejecuta tareas reales y el soporte que lo respalda cuando algo sale mal. Cada puntuación refleja lo que realmente encontré durante las pruebas, no la página de marketing.
| Parámetro | Puntuación | Por qué esta puntuación |
|---|---|---|
| Precios | 9.7/10 | Connector no cobra ninguna suscripción separada y viene incluido gratis con cada plan. El único costo es el del 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 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 fáciles. La configuración inicial del sitio web Node.js requirió hPanel después de que la IA no lograra identificar un target válido, la única falla real en una puesta en marcha 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 target 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 incluso más fino. Escalar tomó dos pedidos directos, 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 extra, cubre una amplia variedad de funciones, y tanto la configuración como el soporte rindieron bien en las pruebas. La precisión de ejecución en targets de despliegue nuevos es el área a vigilar. |
Hostinger Connector no se vende como un producto independiente. Hostinger dice que Connector está incluido gratis con cada plan, lo que significa que no hay ningún cargo mensual separado de Connector que agregar a tu factura de hosting.
Sin embargo, “gratis” necesita contexto. Connector administra recursos de Hostinger; no los reemplaza. Igual necesitás un servicio elegible de hosting, cloud, VPS, dominio, email u otro servicio de Hostinger para las tareas que querés que realice.
Al momento de esta reseña, la landing page 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/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 revisá el total actual al momento del checkout en vez de juzgar el plan solo por la cifra mensual publicitada.
Dato sobre precios: No compres un plan más alto solo para acceder a Connector. Elegí el plan según la cantidad de sitios web y web apps que necesitás, los recursos que requieren y el nivel de soporte que querés. Connector es una capa de administración incluida, no el producto principal que se está cobrando.
Hostinger publicita una garantía de devolución del dinero de 30 días para compras de hosting elegibles. No hay una política de reembolso separada de Connector para evaluar porque Connector no tiene un cargo 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 las preguntas frecuentes de Connector, el cupo predeterminado es de 60 solicitudes por minuto y 1,000 solicitudes por hora, con información de 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 igual deberían evitar llamadas duplicadas innecesarias.
Antes de poder juzgar si Hostinger Connector despliega y administra bien el hosting, necesitaba saber qué hace falta para ponerlo en marcha.
Una herramienta pensada 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. 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 editor 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 editor | 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 calificaciones |
Esa última fila merece una aclaración. Cinco estrellas suena fuerte, pero una muestra de dos reseñas no me dice casi nada sobre la experiencia típica de los usuarios. No usaría ese número como base del texto de la reseña.
Me sorprendió un requisito previo: Hostinger Connector aporta 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. 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 si detrás hay un agente de IA en el editor.
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 verdadero detalle es una dependencia que Hostinger no destaca de entrada: 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, volví a VS Code y vi “Connected via OAuth”.
| Chequeo | Resultado |
|---|---|
| Conexión con un clic | Aprobada |
| El navegador se abrió automáticamente | Aprobado |
| Se detectó la sesión existente de Hostinger | Aprobado |
| Se requirió token API manual | No |
| Se mostró la pantalla de autorización | Sí |
| Se explicaron los permisos | Sí, pero de forma amplia |
| Volvió 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.
Esa es una lista de categorías, no un desglose de permisos uno por uno. Me habría gustado más granularidad acá, ya que “administrar suscripciones” y “administrar sitios web” cubren niveles de riesgo muy distintos.
Lo que sí me dio algo de ese control fue un panel separado dentro de la extensión que listaba todas las categorías de herramientas y me permitía habilitar o deshabilitar cada una por separado:
| Categoría de herramientas | Herramientas disponibles | Estado predeterminado |
|---|---|---|
| Websites | 80 | Habilitadas |
| Domains | 26 | Habilitadas |
| Subscriptions and Payments | 7 | Habilitadas |
| Email Marketing | 12 | Habilitadas |
| Ecommerce | 12 | Deshabilitadas |
| VPS | 62 | Deshabilitadas |
Eso da 199 herramientas en total, con 125 habilitadas por defecto. Dejé Ecommerce y VPS desactivadas hasta que estuviera listo para probarlas 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 esté decidiendo cuánto acceso darle a un asistente de IA. Yo lo llamaría una fortaleza real.
La desconexión de la cuenta está disponible desde el mismo panel, sin necesidad de cambiar la contraseña de Hostinger ni de 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 más que granular. Los controles por categoría de herramientas dentro de la extensión hacen más para limitar el riesgo real que la pantalla OAuth.
Hostinger enumera compatibilidad con los siguientes clientes, reunidos desde la pantalla de onboarding de la propia 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 mostró que Connector es fácil de alcanzar. 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 aboqué 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 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 target de despliegue, desplegar el proyecto, actualizarlo, inspeccionar los resultados y recuperarse de una falla que introduje a propósito.
| Prueba | Qué quería aprender |
|---|---|
| Leer datos de la cuenta | ¿Puede entender con precisión la cuenta de hosting? |
| Encontrar un target 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 desde el editor al hosting en vivo? |
| Publicar una actualización de contenido | ¿Es útil para el trabajo de desarrollo rutinario? |
| Inspeccionar builds 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 de forma segura una versión conocida como buena? |
PulseWatch era deliberadamente simple: un servidor Express, una página principal, 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 un build completado incluso cuando la aplicación falla al iniciar. 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 tocara cambios en vivo. Si no podía describir con precisión mi cuenta, 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 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 separado, al preguntarle por mis planes de hosting activos, el asistente me dijo que tenía “one active hosting plan”. hPanel mostraba tres: Premium, Growth y Business.
| Chequeo | Resultado |
|---|---|
| Enumeró los sitios web conocidos | Aprobado |
| Enumeró todos los planes de hosting | Fallado |
| Detectó el plan Business sin usar | Fallado |
| Hizo algún cambio en la cuenta | No |
Para ser justos con Connector, cuando le marqué la discrepancia, se corrigió, separó claramente lo que había verificado de lo que había asumido y no repitió el dato incorrecto.
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 debería 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, y eso importa, pero no debería haber tenido que cuestionarlo.
Esa brecha en la visibilidad de la cuenta terminó siendo un adelanto 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.
Acá fue donde la prueba reveló lo más importante. Le pedí al asistente que identificara un sitio web Node.js recién creado sin nombrarle el dominio, y sin tocar ningún sitio existente.
Seleccionar el target es un requisito básico de seguridad para una herramienta que puede actuar sobre una cuenta real, así que quise ver cómo manejaba la incertidumbre en vez de una respuesta limpia.
Esto fue lo que pasó, en orden:
| Paso | Qué hizo el 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 en 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 órdenes 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 órdenes de hosting. Nunca confirmó la diferencia antes de llamar a una herramienta viva de creación de sitios web con ellos.
Cuando le pedí que se explicara, el asistente terminó dando un relato preciso: tenía disponible todo el tiempo una herramienta funcional de listado de sitios web, pero nunca la volvió a llamar después de que yo creé un sitio nuevo a través de hPanel, así que rellenó el hueco con un dominio no verificado en lugar de actualizar sus datos.
Cuando le pedí directamente que volviera a ejecutar esa herramienta de listado y buscara un nuevo registro, llamó en cambio a tres herramientas de búsqueda de despliegues no relacionadas e informó “no apareció un sitio web nuevo”, una conclusión que las llamadas a herramientas que realmente hizo no podían haber respaldado.
Nada de esto creó un sitio web suelto en mi cuenta. Las llamadas fallidas no dejaron nada detrás. Pero el patrón vale la pena nombrarlo claramente. Frente a 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. El Connector va a adivinar un target y actuar sobre esa suposición en lugar de detenerse y preguntar. Acá falló de forma segura, pero el hábito de tomar una señal débil como prueba es lo que hay que vigilar en tu propia cuenta.
Con el Connector incapaz de localizar el target por su cuenta, me quedaba una sola opción: crear el target yo mismo y ver si eso cambiaba algo.
Como el Connector no pudo localizar de forma confiable el nuevo target por su cuenta, terminé la configuración inicial manualmente a través de hPanel para ver qué prepara Hostinger antes de que el despliegue mediante Connector sea posible.
El recorrido fue: Crear un nuevo sitio → app 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 advertencia por sí sola. Hostinger ofrece “Build with Hostinger Connector” como método de despliegue junto a GitHub import y subida manual de archivos. Elegí eso 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 falla real de onboarding. La opción presentada como una ruta nativa de Connector en realidad no aprovisionó nada.
Volví y elegí manual file upload 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 principal como /api/health y confirmé que ambas funcionaban.
La ruta manual funcionó sin fricción una vez que dejé de esperar que Connector lo encontrara. El botón “Build with Hostinger Connector” en esta pantalla debería corregirse o eliminarse. Ahora mismo promete algo que no hace.
Ahora existía un sitio web real y confirmado. La siguiente pregunta era si el Connector se comportaría distinto ahora que tenía algo sólido para encontrar.
Con un sitio web real y confirmado en su lugar, volví al Connector y le pedí que inspeccionara exactamente ese dominio. Esta vez funcionó sin problemas.
| Chequeo | Resultado |
|---|---|
| Reconoció el sitio como un target de despliegue Node.js | Aprobado |
| Encontró el registro de despliegue completado | Aprobado |
| Encontró el registro de build Node.js correspondiente | Aprobado |
| El despliegue y el build compartieron el mismo UUID | Aprobado |
Eso confirmó algo importante: los fallos anteriores tenían que ver con localizar y crear un target nuevo, no con la capacidad del Connector para trabajar con un sitio Node.js una vez que existe uno.
Después 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 principal, 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 sitio web confirmado existente | Aprobado |
| Revisó el estado del despliegue y del build después | Aprobado |
Todo el update llevó aproximadamente un minuto. El asistente informó que el nuevo despliegue estaba “pending” inmediatamente después de enviarlo, simplemente porque revisó antes de que Hostinger terminara de procesarlo.
Cuando refresqué el sitio en vivo yo mismo, el nuevo encabezado ya estaba ahí.
Los logs de build que recuperó después fueron específicos y útiles: 67 paquetes agregados, 68 auditados, cero vulnerabilidades encontradas, sin errores.
Para sitios ya establecidos, esto se acerca bastante al flujo de trabajo que Hostinger promete. Editá, verificá localmente, publicá y confirmá, todo sin salir del editor, en aproximadamente un minuto. Este es el mejor resultado de toda la prueba.
Un despliegue limpio solo me dice que el camino feliz funciona. Para saber 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 una falla real, no solo con una demo limpia. Rompí deliberadamente la aplicación para ver si el estado y los logs del Connector realmente podían ayudarme 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 de por sí.
Después 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 igual, a propósito, para ver qué reportaría Hostinger.
| Estado mostrado | Qué confirmó | Qué no confirmó |
|---|---|---|
| Build: completed | Dependencias instaladas, etapa de build finalizada | Que la aplicación realmente iniciara |
| Deployment: completed | Hostinger aceptó y procesó la release | Que cada ruta estuviera sana |
Los logs de build disponibles a través del Connector mostraban la instalación exitosa de dependencias y nada más. El error de runtime por módulo faltante nunca apareció ahí. Un desarrollador que mirara de reojo 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 copia de seguridad, verificó la app localmente, redeployó 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 de completed no es prueba de una aplicación que funcione, y los propios logs del Connector no te van a decir eso. La recuperación en sí funcionó bien una vez que supe que había un problema por recuperar.
Después de una falla que una insignia de estado no pudo revelar, quise saber en qué otros lugares la confianza del Connector podría adelantarse 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 del Connector antes de tocar nada y se detuviera si no era así.
Buscó en 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 el resto de esta prueba. Frente a 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 de ese tipo durante esta prueba.
| Prueba | Resultado | Hallazgo clave |
|---|---|---|
| Respaldar el manifiesto funcional | Aprobado | Archivo de recuperación creado antes de la modificación |
| Introducir un punto de entrada faltante | Aprobado | Se agregó una falla controlada |
| Reproducir la falla localmente | Aprobado | MODULE_NOT_FOUND confirmado |
| Desplegar la versión rota | Aprobado | Hostinger aceptó el archivo comprimido |
| El estado del build detecta la falla | Fallado | El build siguió mostrando completed |
| Los logs del build exponen el error en runtime | Fallado | El error de módulo faltante no apareció |
| Restaurar el manifiesto funcional | Aprobado | Se recuperó el comando original de inicio |
| Redeployar la versión funcional | Aprobado | El despliegue se completó |
| Verificar el endpoint de salud en vivo | Aprobado | La API devolvió estado operativo |
Hostinger Connector se desempeñó bien en tareas rutinarias y determinísticas:
Fue más débil cuando la tarea requería interpretación sobre datos incompletos de la cuenta:
Este patrón es útil a la hora de decidir cuánta autonomía darle al asistente.
Usá prompts más amplios para inspecciones de bajo riesgo. Usá prompts precisos y requisitos explícitos de confirmación para acciones que cambian infraestructura en vivo.
Por ejemplo, en lugar de:
| Desplegá esta app a un nuevo sitio temporal de Hostinger. |
usá:
| Listá los sitios web que devuelve actualmente Hostinger. Identificá un sitio web Node.js solo si aparece en ese resultado. Mostrame 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 en marcha Hostinger Connector fue fácil, sin la fricción típica de la 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 existía un sitio web real con un dominio conocido, hizo bien el trabajo: un cambio de una línea pasó de edición a vivo en aproximadamente un minuto, respaldado por logs útiles.
El problema apareció antes en el proceso, no después. Frente a un target nuevo que no podía encontrar, el 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 runtime apareciera en sus propios logs. Eso no hace que la herramienta sea poco confiable para sitios ya existentes, pero sí significa que los despliegues nuevos y el estado post-despliegue necesitan una segunda revisión antes de confiar en ellos.
Hostinger estructura su soporte alrededor del chat en vivo y el autoservicio, en lugar de llamadas telefónicas, así que me enfoqué en lo que la mayoría de los usuarios realmente va a usar: el asistente de IA integrado en hPanel, la escalada 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 |
|---|---|---|
| Live chat (Kodee, IA) | 24/7 | Accedido mediante “Ask AI” en hPanel |
| Live chat (humano) | Solo por escalada | No es una cola directa, se deriva a través de Kodee |
| Email / ticket | support@hostinger.com | Ventana de respuesta declarada de 1 business day |
| Teléfono | No ofrecido | Sin 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 apunta a los desarrolladores para cualquier cosa urgente, y el más probable de usar mientras se depura un despliegue, probé esa ruta directamente en lugar de abrir un ticket por email.
Abrí el live chat a través de “Ask AI” en hPanel y le hice a Kodee una pregunta con una respuesta real para equivocarse: si un estado de build completed 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” 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.
Esa única respuesta habría resuelto la misma ambigüedad con la que mi prueba de recuperación ante fallas se encontró antes en esta reseña. Kodee nombró un archivo de log real, la carpeta correcta y trazó la línea correcta entre el éxito del build y la salud en runtime.
Sin embargo, también quería ver si podía obtener acceso 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 línea fue más difícil de lo que esperaba. Pedí directamente un agente en vivo y me redirigió de nuevo a Kodee dos veces, cada vez enmarcado como más rápido que esperar:
Entiendo por qué querrías eso. Puedo ayudarte a verificar el build, el comando de inicio y los logs de runtime acá mismo, que suele ser la forma más rápida de encontrar el problema.
Antes de derivarte a un especialista. Puedo resolver el problema y ahorrarte la espera.
| Intento | Mi pedido | Respuesta de Kodee |
|---|---|---|
| 1 | “¿Podés conectarme con un agente en vivo?” | Ofreció resolverlo él mismo |
| 2 | “Igual me gustaría hablar con un agente humano. Por favor conectame.” | Ofreció de nuevo, pidió dominio y comando de inicio |
| 3 | Hice clic en “Go to human” / escribí “Quiero continuar con un humano” | Escaló |
Fueron necesarios dos pedidos directos y explícitos antes de que Kodee dejara de redirigirme hacia 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 un traspaso en vivo en el sentido habitual de “conectame con un humano”. Kodee explicó el modelo real de forma clara:
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 un traspaso 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” acá no significa que se sume una nueva persona a la ventana de chat como pasaría en la mayoría de los sistemas de live chat.
Empujé el mismo hilo técnico un poco más mientras esperaba, pidiéndole a Kodee que confirmara la ruta exacta del log y si stderr.log siempre está poblado. Dio una buena respuesta por sí mismo, notando correctamente que el log puede estar vacío si la app nunca llegó a iniciar por completo o escribió su error en otro lado.
La revisión del especialista llegó en unos 3 minutos, acreditada dentro del chat a una compañera llamada Mayas, y mejoró la respuesta de Kodee en vez de repetirla:
domains/[your-domain]/nodejs/stderr.log es la ubicación correcta. No siempre se genera ni se llena. Solo verás entradas ahí cuando la app escriba en stderr, como con excepciones no capturadas o rechazos no manejados. Si el comando de inicio está mal y el proceso se cierra silenciosamente, stderr.log puede estar vacío o faltar.
Mayas también agregó dos comprobaciones de respaldo que Kodee no había mencionado: revisar stdout.log para ver la última salida antes de un crash, y buscar una línea de confirmación de inicio faltante como señal de que la app nunca arrancó del todo.
| Chequeo | Resultado |
|---|---|
| Primera respuesta técnica precisa | Sí |
| Escalada humana disponible | Sí, pero resistida dos veces antes de concederse |
| Modelo de escalada | Revisión y reenvío asíncronos, no traspaso en vivo |
| Respuesta con nombre | 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 conocimientos 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 apenas relacionados, incluido un artículo sobre un plugin de affiliate marketing y un artículo general sobre hosting Node.js.
El artículo que realmente documenta la configuración de Connector se llama “How to Set Up Web Hosting MCP on Local IDEs”, archivado bajo Features → General Information.
Buscar el nombre de marketing real del producto me llevó hasta ahí, pero un lector que navegue por categorías o busque “MCP” sin conocer la marca de Hostinger podría perderlo igual de fácil, y la diferencia entre el nombre comercial y el nombre documentado vale la pena conocerla antes de empezar a buscar.
El artículo en sí es sólido una vez que lo encontrás. Se actualizó por última vez seis días antes de mi prueba, y cubre:
Ese último punto coincidió con algo 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, que no es algo que todos los asistentes de soporte con IA logren. El artículo de base de conocimientos que la respalda está actualizado y es detallado una vez que lo encontrás, aunque el nombre de marketing del producto y el título de su 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 ruta de escalada humana. Kodee me redirigió a sí mismo dos veces antes de respetar un pedido directo de una persona, y aun así, “agente humano” significa una revisión asincrónica retransmitida a través del mismo chat en lugar de un traspaso 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 solo ya te va a dar una respuesta precisa y rápida. Si realmente querés que una persona verifique la respuesta, esperá tener que pedirlo más de una vez y esperar una respuesta reenviada 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 llevó minutos, OAuth eliminó cualquier necesidad de claves API, y una vez que existía un sitio web con un dominio conocido, el Connector publicó una actualización en vivo en aproximadamente un minuto con logs para respaldarlo. Las respuestas de soporte de Kodee fueron lo bastante agudas como para resolver un problema técnico real en el primer intento.
La trampa es la confianza, no la conveniencia. Cuando se encontró con un target nuevo que no podía localizar, el 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, con ningún error de runtime en sus propios logs. Usalo para agilizar el trabajo en sitios que ya existen, verificá todo lo que haga sobre un target nuevo y revisá el sitio en vivo vos 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 |
| Hosting optimizado para sitios de ecommerce con rendimiento seguro, rápido y confiab... | 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 emails confiable y segura. | Read SMTP Server Review |
| Hosting rápido y optimizado, diseñado para aplicaciones web de Ruby on Rails. | Read Ruby on Rails Review |
| Alojamiento con muchas funciones e integración con OpenClaw para crear y administrar... | Read OpenClaw Review |
| Hosting rápido y confiable con servidores ubicados en el Reino Unido para un rendimi... | 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 | |
| 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 utilice 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 separada ni reemplaza hPanel. Ofrece otra forma de interactuar con los recursos de Hostinger.
Hostinger actualmente incluye:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger también indica que otros clientes compatibles con MCP podrían ser compatibles. La configuración inicial y el comportamiento de las herramientas pueden diferir según el cliente.
Hostinger Connector es gratis para instalar y está incluido con los planes de Hostinger. No hay una suscripción aparte de Connector en los precios que se muestran durante esta reseña. Igual tenés que pagar por el servicio de Hostinger subyacente, 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 mediante el flujo de autorización basado en el 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 real. Usá un sitio web, dominio o VPS de prueba dedicado cuando aprendas el flujo de trabajo. No asumas que un prompt está simulado simplemente 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 rate limit se devuelven en los encabezados de respuesta.
Estos límites deberían ser suficientes para un uso interactivo normal. Evitá 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 directorio raíz durante el despliegue inicial en hPanel. Una vez que el sitio web existió como un destino de Node.js reconocido, el despliegue repetido a través de Connector funcionó correctamente.
No necesariamente. En mi prueba controlada, Hostinger informó una compilación completada después de que cambié el script de inicio para que apunte 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 verificá el sitio web en vivo o llamá 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 despliegues de rutina y consultas de cuenta. hPanel sigue siendo útil para la administració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
