Hostinger armó Web Apps Hosting con una propuesta simple: subir tu código desde GitHub, un archivo ZIP o tu agente de código con IA, y tener una app en vivo, lista para producción, funcionando en aproximadamente un minuto, sin que tengas que administrar un servidor. Quería ver cuánto de eso se sostiene de verdad cuando sos vos el que hace clic en deploy, así que esto fue lo que encontré.

Deploy Web Apps Faster with Hostinger

Deploy modern web apps on Hostinger with automated builds, managed infrastructure, global CDN, SSL, security tools, and a 30-day money-back guarantee.

Visita Hostinger

Pros y contras

Desglose de puntaje

Para puntuar Hostinger’s Web Apps Hosting, apliqué la metodología de calificación de HostAdvice, el mismo enfoque estandarizado que se usa en cada review del sitio, así los puntajes se mantienen apoyados en pruebas reales y no en lenguaje de marketing. Así quedó puntuado en cada parámetro.

Host Your Web Apps Without the DevOps Hassle

Deploy modern web applications on fully managed hosting with automated deployments, managed SSL, global CDN, and built-in security.

Visita Hostinger

Planes y precios

Hostinger vende Web Apps Hosting en dos niveles, Business y Cloud Startup, ambos pensados específicamente para desplegar apps modernas de Node.js y JavaScript, en vez de un constructor de sitios tradicional.

Cloud Startup, el nivel que probé, duplica la cantidad de apps permitidas y los núcleos de CPU respecto de Business, y ambos planes incluyen un dominio gratis, un email empresarial gratis y SSL administrado durante el primer año directamente en el checkout.

Hay algunas cosas que conviene saber antes de comprar:

• Garantía de devolución: Web Apps Hosting entra en las condiciones estándar de reembolso de Hostinger, una ventana de 30 días exactos desde la fecha de compra. Esto es bastante más simple que lo que aplica a los planes VPS de Hostinger, que tienen un cooldown adicional de 180 días entre reclamos de reembolso. Acá no aplica ningún cooldown así.
• Prueba gratis: No encontré una prueba gratis dedicada. La garantía de devolución de 30 días es tu ventana para evaluarlo.
• Métodos de pago: El checkout mostró el pago con tarjeta como método por defecto, con logos de Visa, Mastercard, Amex y Discover, además de una opción para agregar otro método de pago durante la compra.
• Qué viene incluido: Un dominio gratis por un año, buzones de correo gratis por un año y SSL administrado vienen incluidos sin costo extra encima del precio del plan, así que el precio de lista se parece bastante al costo real de poner en línea un deploy completo y seguro.
• El único upsell: Hostinger Reach, un complemento de email marketing, aparece en el carrito como su propio recuadro destacado con un precio mensual aparte. Es fácil de saltear y no viene incluido ni preseleccionado por defecto.

Si cancelás un plan de Web Apps Hosting dentro de los 30 días, la política de reembolso de Hostinger confirma que entra dentro de las condiciones estándar en lugar de la lista de exclusiones, así que una cancelación simple dentro de esa ventana debería calificar para reembolso sin las condiciones extra que se aplican a VPS o compras de dominios.

Funciones

• Detección automática del framework y la versión de Node
• Herramientas administradas para creación de bases de datos MySQL
• CDN global activa por defecto
• Protección WAF y DDoS incluida
• Backups diarios y bajo demanda
• Escáner de malware y análisis de vulnerabilidades
• Integración con GitHub y auto-deploy
• Dominio, email y SSL gratis
• Acceso SSH para usuarios avanzados

From Code to Live App with Hostinger

Connect your GitHub repository or upload your project and get it online with managed infrastructure, automatic deployments, and daily backups.

Visita Hostinger

Rendimiento

Como Web Apps Hosting es completamente administrado, nunca tenés acceso a shell sobre un servidor, así que no hay CPU, RAM ni disco para benchmarkear directamente como se haría en una review de VPS.

Lo que sí podés medir es qué tan rápido carga y responde la app desplegada, desde ubicaciones reales alrededor del mundo. Probé eso desde cuatro ángulos distintos: GTmetrix desde dos continentes, una verificación global de más de 50 puntos, y la propia herramienta de velocidad integrada de Hostinger para escritorio y mobile.

La app bajo prueba es el deploy de Next.js cubierto en la sección de Facilidad de uso más abajo, en ivory-llama-856835.hostingersite.com, corriendo sobre el plan Cloud Startup (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage), con la CDN activa por defecto.

1. GTmetrix, probado desde dos continentes

Corrí GTmetrix dos veces desde distintas partes del mundo para ver si el resultado se mantenía consistente o si sólo se veía bien desde un punto de vista afortunado.

Ambas corridas dieron un 100% perfecto tanto en Performance como en Structure, con cero shift de layout y cero blocking time en ambas ubicaciones, lo que significa que nada en la página compitió por la atención del navegador ni saltó de lugar mientras cargaba.

El detalle realmente interesante es que Frankfurt en realidad superó a Chicago en todas las métricas de tiempo, aunque yo había elegido deliberadamente una ubicación de servidor en USA para esta app. Ese resultado sólo tiene sentido a la luz de la CDN.

Una vez que una CDN está activa, como lo estaba acá por defecto, tu visitante no necesariamente llega directo al servidor de origen.

Llega al nodo edge cacheado más cercano, así que un punto de prueba europeo puede terminar siendo más rápido que uno de USA aunque el servidor real esté en USA. Esta es una confirmación real y práctica de que la CDN que Hostinger activa por defecto realmente hace su trabajo y no está ahí como un bullet de marketing.

2. Consistencia global (Check-Host)

Corrí una verificación HTTP contra la URL en vivo desde todos los checkpoints que ofrece Check-Host, 54 ubicaciones en seis continentes. El panorama completo:

Todas las comprobaciones exitosas devolvieron un 200 OK limpio, sin errores, sin fallas parciales, sin redirecciones inesperadas.

Los tiempos de respuesta contaron una historia clara sobre cómo se comporta el cache de una CDN a distancias reales:

Los checkpoints europeos devolvieron consistentemente los tiempos más rápidos, varios por debajo de 50 milisegundos, mientras que los checkpoints físicamente más alejados de cualquier nodo edge, Tokyo, Singapore, Ho Chi Minh City, igual devolvieron respuestas 200 válidas, sólo que más lentas, en el rango de 0.3 a 0.8 segundos.

Ese es el comportamiento esperado para un deploy respaldado por CDN: rápido cerca de los edges, todavía completamente funcional lejos de ellos.

Los cuatro timeouts, Kazakhstan, Romania, y dos de los cuatro checkpoints rusos, no son algo que yo leería como un problema de la infraestructura de Hostinger.

Otros checkpoints en los mismos países sí funcionaron (Saint Petersburg respondió limpio en 0.063s mientras dos checkpoints de Moscow expiraron), lo que apunta a filtrado de red regional del lado del checkpoint y no a algo mal en la app desplegada.

3. La propia herramienta de velocidad de Hostinger, escritorio y mobile

Hostinger ejecuta su propio test de Page Speed dentro del dashboard de la app, así que comparé sus números con los resultados independientes de GTmetrix en lugar de tomar cualquiera de los dos como verdad absoluta.

Ambos tipos de dispositivo lograron un 100 perfecto, y los números de escritorio coinciden bastante con lo que GTmetrix midió de forma independiente, que es justamente el punto de correr ambas pruebas. Dos herramientas distintas, dos metodologías distintas, y coinciden entre sí.

Mobile vino más lento en todas las métricas de tiempo, como era de esperarse en una conexión simulada más lenta y con un procesador más débil, pero igual lo suficientemente rápido como para que un puntaje de 100 refleje un rendimiento mobile realmente fuerte y no sólo una escala de evaluación permisiva.

Una inconsistencia en la herramienta en sí. Aunque el puntaje es un 100 limpio en ambos dispositivos, el panel de Diagnostics debajo igual marca algunos ítems con puntaje literal de 0, dependency tree de red, document request latency y avoiding multiple redirects, además de dos ítems con puntaje 50, unused JavaScript y legacy JavaScript.

Ninguno de esos subpuntajes bajos arrastró el número principal, así que tomalos como oportunidades menores y realmente presentes de optimización, no como algo mal en el deploy.

Por otro lado, los “helpful links” que Hostinger muestra al lado de estos diagnostics están todos escritos para WordPress, “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, pese a que esto es una app Node.js sin WordPress involucrado en ninguna parte del stack. Eso quedó de una plantilla compartida de diagnostics y no de contenido hecho para este producto.

Veredicto general sobre rendimiento

Managed Web App Hosting by Hostinger

Focus on building your app while Hostinger takes care of deployment, infrastructure, security, SSL, backups, and global delivery.

Visita Hostinger

Facilidad de uso

Probé Hostinger’s Web Apps Hosting desde la landing page hasta el checkout, y después desde una cuenta nueva hasta un deploy de Node.js completamente en vivo y funcionando.

Eso incluyó elegir un plan, pagar, decidir cómo construir, conectar GitHub y ver cómo el build terminaba en tiempo real. Así fue realmente ese proceso.

1. Registro

Arranqué en la landing page de Web Apps Hosting, que abre con una sola llamada a la acción: Start deploying.

Hacer clic ahí no abre un formulario de registro. Te scrollea directo a la sección de precios, así que la primera decisión real que tomás es qué plan comprar, no qué datos de cuenta completar.

Había dos planes uno al lado del otro:

Elegí Cloud Startup por el doble de capacidad de apps y más margen de CPU que el nivel de entrada. Un pequeño detalle inconsistente para señalar acá: la página de precios lo llama “Cloud Startup”, pero cuando llega al carrito, el mismo plan aparece como “Startup plan”. No es un problema funcional, sólo un desajuste de nombre entre dos pantallas del mismo flujo de checkout.

El carrito en sí estaba limpio. Mostraba el plazo de 48 meses, el ahorro, un dominio gratis por un año y mailboxes gratis, y después ofrecía un solo upsell, Hostinger Reach email marketing, en su propio recuadro destacado y no preseleccionado.

Lo salteé y apreté Continue sin fricción.

Si sos un cliente nuevo y no uno que ya existe, el checkout inserta un paso de creación de cuenta antes de llegar a la página de facturación y pago.

Después agregás una dirección de facturación, elegís un método de pago, tarjeta, PayPal u otra de las opciones, y enviás el formulario. Recibí un email de confirmación de compra a los pocos momentos de hacer clic en Submit payment, y enseguida caí directamente en hPanel con el plan ya provisionado.

Lo que pensé: El checkout es corto y el upsell se puede rechazar sin tener que buscar un botón oculto para saltearlo. El desajuste de nombres entre la página de precios y el carrito es una pavada, pero es el tipo de detalle que hace que un comprador primerizo frene y vuelva a chequear si eligió el nivel correcto.

2. Dashboard

Una vez que se acredita el pago, llegás a hPanel, el panel de control propio de Hostinger que construyó para administrar todos los productos que vende, no una página hecha específicamente alrededor de tu nuevo Web App.

La página a la que llegás primero es Home, y está armada alrededor de una barra de prompt de IA en la parte superior: “Hi, [your name]! How can I help you today?” con un campo de texto debajo y seis botones de atajo: Get domain, Create website, Get email, Migrate site, Get VPS, y Try email marketing.

Si seguís bajando, vas a encontrar:

• Tiles de promoción de funciones para AI Builder, la herramienta de tienda online, reclamando un email empresarial gratis, AI agents, una automation app y reclamando un dominio gratis
• Una lista de tareas que te empuja a pasos de configuración, terminar la configuración de Reach, reclamar tu email gratis, reclamar tu dominio gratis
• Your business, una lista en curso de cada sitio, app e instancia VPS asociada a tu cuenta, cada una con su propio botón Manage site
• VPS, una tabla aparte más abajo que lista cualquier instancia VPS por dirección IP, estado y fecha de expiración

Un panel Agent también queda fijo en la esquina superior derecha de cada página de hPanel, no sólo en Home. Es el mismo asistente Kodee usado para soporte, pero presentado acá como una herramienta general de acciones con prompts listos como “Deploy my Node.js app” o “Harden VPS updates” que podés usar sin escribir una pregunta completa.

Home es realmente útil una vez que tu app ya existe; todo en Your business enlaza directo hacia ella. Pero no es donde vas para crear un nuevo Web App o para llegar al botón Setup. Para eso, necesitás otro camino dentro de la barra lateral:

1. Hacé clic en Websites en la barra lateral izquierda
2. Se expande un submenú debajo: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Hacé clic en Web Apps

Ese clic te lleva a una pantalla completamente distinta de Home, organizada alrededor de tus planes de hosting reales más que de una barra de prompt.

Acá, cada plan que tenés obtiene su propia tarjeta. En mi cuenta, eso significaba tres tarjetas apiladas verticalmente:

La tarjeta de Business también ya tenía una app en vivo listada debajo de pruebas anteriores, orange-walrus-700988.hostingersite.com, con sus propios botones Tools y Dashboard.

Eso vale la pena notarlo por sí mismo. Una vez que existe un Web App, su tarjeta suma una fila como esta mostrando el sitio en vivo directamente, que es exactamente cómo se va a ver tu tarjeta de Cloud Startup cuando termines el setup.

Como Cloud Startup era el plan que recién había comprado y todavía no había configurado, su tarjeta mostraba un único botón Setup en cambio. Ese es el botón que realmente inicia el asistente de creación del Web App, y sólo aparece acá, en Websites → Web Apps, no desde la pantalla Home que ves por defecto.

Lo que pensé: hPanel es claro una vez que encontrás la pantalla correcta, pero Web Apps Hosting no tiene una puerta de entrada obvia. Caer en Home te muestra un prompt bar y accesos directos, no un camino para crear una app; tenés que saber que hay que hacer clic en Websites, después en Web Apps, antes de que siquiera aparezca Setup. Son un par de clics extra para un producto vendido como “live in a minute”. Una vez que estás ahí, igual, las tarjetas de planes son limpias y honestas respecto del estado, y un plan que ya tiene una app corriendo lo muestra directamente en la tarjeta.

3. Desplegando la app

Hacer clic en Setup en la tarjeta del plan abrió un flujo corto de onboarding: Where would you like to start? con tres opciones, Create a new site, Migrate an existing site, o I hired someone to build my site. Elegí Create a new site.

Eso llevó a How do you want to build your website?, dividido entre dos opciones pensadas para principiantes arriba, Hostinger AI Builder y WordPress + AI, y dos opciones debajo de un encabezado separado de “for advanced users”: Node.js web app y PHP/HTML website. Seleccionar Node.js web app es lo que realmente te pone sobre el producto Web Apps Hosting.

Este es un dato estructural real para cualquiera que compare productos: Web Apps Hosting no tiene su propio flujo de registro dedicado.

Es una rama dentro del mismo asistente general de creación de sitios usado para AI Builder y WordPress.

Hice clic en el círculo al lado de Node.js web app, y después en Next.

A partir de ahí:

• Pantalla de dominio: elegí Use temporary domain en vez de atarme a un dominio real, ya que era un deploy de prueba.

• Pantalla de ubicación del servidor: Hostinger preseleccionó France, la región más cercana a mi país de facturación, y la mostró con 167ms de latencia. Al hacer scroll hasta la opción de United States aparecía 364ms, más del doble.

Elegí United States, Massachusetts igual, y esta es exactamente la lección que enseña el selector de ubicación en cada producto de Hostinger: elegilo según dónde están tus visitantes reales, no según el número más bajo de la lista.

La audiencia prevista para mi app de prueba es de USA, así que un servidor en USA realmente les va a responder más rápido que uno en France, sin importar lo que me mostrara el selector desde mi propia ubicación. El número en pantalla te dice qué tan rápido responde el servidor al test de Hostinger, no qué tan rápido responderá a la gente que realmente use tu sitio.

• Pantalla de método de deploy: dos opciones principales, Import Git repository (marcada Recommended) o Upload your files, más un recuadro abajo para desplegar directamente desde Claude Code, Cursor o VS Code a través de Hostinger Connector. Elegí Import Git repository y hice clic en Connect with GitHub.

Eso abrió una ventana real de inicio de sesión de GitHub si no estabas logueado, y después una pantalla de permisos titulada Install & Authorize Hostinger, pidiéndote que elijas entre:

• Instalar en all repositories que poseés, incluidos los futuros, con acceso de sólo lectura a repos públicos
• Instalar sólo en only select repositories que elijas individualmente, y listando los permisos exactos que se otorgan: acceso de lectura a actions, metadata y repository hooks, y acceso de lectura y escritura a administration, code y pull requests. Una vez que hacés clic en Install & Authorize, GitHub te redirige automáticamente de vuelta a hPanel.

Llegás a Select Git repository to import, una lista desplazable de cada repo asociado a tu cuenta de GitHub, cada uno con su propio botón Deploy al lado. Encontré el repositorio de prueba que había subido antes, hostadvice-webapps-test, y hice clic en Deploy al lado.

Desde que hice clic en ese botón, tardó cerca de 30 segundos sin ningún indicador de progreso en pantalla antes de que cargara la siguiente página, lo bastante como para que te preguntes si el clic se registró o no.

La página que finalmente carga se titula Review build settings, y te dice exactamente dónde va a vivir tu app antes de que confirmes algo: “Deploys to ivory-llama-856835.hostingersite.com.” Debajo, sin tocar un solo campo, ya había detectado automáticamente:

Cada una de esas cinco filas tiene su propio botón Change o Add al lado, así que nada de esto queda bloqueado si la detección se equivoca.

Hice clic en Add al lado de Environment variables y configuré un par clave-valor para confirmar que realmente llegaría a la app en ejecución después, luego hice clic en Finish en ese diálogo, y después en el botón principal Deploy al pie de la página.

Mirando el build

La pantalla cambia a una vista de Deploying… con una barra de progreso etiquetada, “Deployment from GitHub”, que avanza por etapas reales; la vi pasar por 28%, después 51%, en su camino a completarse. Debajo de la barra de progreso hay un panel plegable de Build logs, y al expandirlo muestra salida de terminal real en vivo a medida que ocurre, no un spinner de relleno:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Deploy completado

Cuando termina el build, llegás a una pantalla de Deployment completed! con una vista previa en miniatura en vivo de tu app real renderizada ahí mismo en la tarjeta, junto a un resumen con el nombre del repositorio y la URL en vivo asignada.

Desde esta página podés hacer clic directo en Go to dashboard, que es donde administrás la app a partir de ahí.

Lo que pensé: La autodetección es lo más destacado acá. El framework, la branch y la versión de Node salieron correctos sin que yo completara un solo campo manualmente, y el log de build en vivo hace que la espera se sienta transparente en vez de opaca. El único punto flojo es esa pausa de 30 segundos antes de llegar siquiera a la pantalla de configuración, lo bastante larga como para que parezca que algo se trabó antes de que el proceso empiece a mostrarse.

4. Confirmación del deploy en vivo

Antes de explorar cualquier herramienta de gestión, quise confirmar que la app realmente se había desplegado y estaba funcionando, no sólo marcada como “Completed” en pantalla.

Desde la página de Deployment completed, hice clic directo en la URL en vivo, ivory-llama-856835.hostingersite.com, en vez de confiar sólo en la miniatura del dashboard.

La página en vivo cargó y mostró exactamente lo que la app estaba programada para mostrar:

• Server build time, un timestamp en vivo que confirma que la página se compiló recién, no que se sirve desde un cache viejo
• Environment variable check, mostrando la variable personalizada que había configurado durante la pantalla de deploy, confirmada correctamente en el sitio en vivo real, no sólo en la vista previa del dashboard

Después hice clic en el botón propio de la app, Ping the API route, que llama a un endpoint backend en vivo en vez de sólo renderizar contenido estático. Devolvió una respuesta JSON limpia:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

Esa respuesta importa más de lo que parece. Que una página cargue correctamente sólo prueba que se subieron los archivos estáticos.

Que una llamada API funcione prueba que el servidor Node.js real está corriendo por debajo y respondiendo a pedidos reales, la parte de “Node.js web app” del hosting que es fácil de simular con un archivo estático y difícil de simular con un timestamp de servidor en vivo generado en el momento exacto en que hacés clic en un botón.

Lo que pensé: Esta es la verificación que te recomendaría hacer antes de confiar en cualquier deploy en esta plataforma, o en cualquier otra parecida. Un estado verde de “Completed” y una miniatura te dicen que el build terminó. Hacer clic en la URL en vivo y disparar algo dinámico, una llamada API, una lectura de base de datos, cualquier cosa que no pueda ser fingida por una página estática cacheada, te dice que el servidor realmente está vivo y hace lo que construiste que haga.

5. Gestión del Web App

Con la app en vivo confirmada y funcionando, volví a hPanel y exploré el dashboard de gestión de la app de punta a punta, la capa real de administración del servidor de este producto, separada de la pantalla general Home de hPanel que cubrí antes.

Resumen del dashboard. En el momento en que llegás acá, cuatro badges de estado te muestran cómo está todo de un vistazo:

Los cuatro quedaron verdes por defecto, sin que yo tuviera que activar nada manualmente. Debajo hay una tarjeta de Last deployment que confirma estado, repositorio, autor, commit, hora del deploy, stack detectado y versión de Node, todo lo que querés verificar de un vistazo sin meterte en los logs.

Ya se había ejecutado automáticamente un Page Speed test contra el sitio en vivo y había devuelto un puntaje Desktop de 99/100 sin que yo lo activara, al lado de un panel de Essentials con enlaces rápidos a conexión de base de datos, backups, file manager, runtime logs y cache.

Deployments, variables de entorno y logs. Tres páginas distintas cubren esto:

• Deployments guardó un registro completo del push, autor, branch, hash del commit y estado de finalización, un historial real y no sólo el más reciente
• Environment variables mostró correctamente la que había configurado durante el deploy, confirmando que quedó almacenada y aplicada, no sólo mostrada una vez durante la configuración y después olvidada
• Runtime logs transmitió salida del servidor en vivo a medida que ocurría, líneas de arranque de Next.js, timestamps de ready, y un conteo en curso de issues y errors, que se mantuvo en cero y cero todo el tiempo que estuve mirando

Seguridad. El Malware Scanner devolvió un resultado limpio, “Your website is safe”, con una aclaración dicha de forma clara y no escondida en letra chica: revisa sólo los archivos del sitio, no el contenido de la base de datos, y existe una opción paga de limpieza si querés un análisis más profundo que incluya la base de datos. El análisis de Vulnerabilities también dio limpio.

Bases de datos. Acá es donde el propio marketing del producto deja una brecha real que conviene entender antes de comprar. El plan anuncia MySQL administrado como una función principal, pero nada se provisiona automáticamente para vos.

La sección Databases se abre sobre un formulario manual Create a New MySQL Database And Database User, lo que significa que nombrás y creás la base de datos vos mismo antes de que tu app pueda usar una. Lo confirmé directamente con Kodee, cubierto en la sección de Soporte más abajo, y la respuesta fue directa: administrado significa que Hostinger ejecuta la infraestructura de la base de datos detrás de escena, no que una base de datos se cree para vos en el momento en que tu app sale en vivo.

Acceso avanzado. El acceso SSH existe dentro de Advanced, completo con IP, puerto y usuario, pero aparece Inactive por defecto y necesita un clic manual en Enable antes de que puedas usarlo. File Manager ofrece elegir entre navegar sólo los archivos de esta app o todos los archivos de todo el plan de hosting.

Lo que pensé: El dashboard de uso diario está bien organizado y es completo. Seguridad e historial de deploy, en particular, son fáciles de encontrar y realmente informativos, y el runtime log sin issues junto con un malware scan limpio me dieron confianza real de que la app estaba sana, no sólo online.

El único lugar donde la interfaz promete más de lo que realmente entrega es la sección de base de datos, donde “managed MySQL” suena en la página del plan como algo que ya te espera en el momento en que tu app sale en vivo, y en la práctica significa un formulario para crearla vos mismo, simple de usar, pero un paso que tenés que hacer por tu cuenta.

Veredicto general sobre facilidad de uso

Build, Deploy, and Scale with Hostinger

Host modern web apps with GitHub integration, managed MySQL, global CDN, unlimited bandwidth, and built-in security tools.

Visita Hostinger

Nivel de soporte

Probé el soporte de Hostinger para Web Apps Hosting a través de Kodee, el asistente de IA integrado en hPanel, y después revisé la base de conocimiento para ver cuánto cubre sin necesidad de preguntarle a nadie. Kodee aparece en dos lugares que vale la pena distinguir: como Ask AI en el sitio público de marketing, y como panel Agent disponible desde cualquier página dentro de hPanel, incluso directamente en el dashboard propio del Web App.

1. Soporte con IA (Kodee)

Le hice dos preguntas armadas alrededor de huecos reales que había encontrado durante las pruebas, no búsquedas genéricas que Kodee pudiera contestar pegando documentación.

Pregunta 1 probó el comportamiento ante fallas de deploy y el momento de las variables de entorno, dos preocupaciones reales de producción para cualquiera que despliegue en esta plataforma:

Si el build de mi app falla a mitad de un deployment desde GitHub, ¿la app vuelve automáticamente a la última versión exitosa o queda caída hasta que lo arreglo y redeployo? ¿Y puedo configurar variables de entorno personalizadas antes del primer deploy, o sólo después?

Kodee respondió directo y correctamente en ambos puntos. Un build fallido no reemplaza una app que ya estaba corriendo; si hubo un deploy exitoso previo, la app sigue sirviendo esa última versión funcional. Si es el primer deploy y no hay nada a lo que volver, la app queda caída hasta que el build se arregle y se vuelva a desplegar, una respuesta clara y honesta en vez de una tranquilidad vaga.

Sobre las variables de entorno, confirmó que podés configurarlas antes del primer deploy en los ajustes de deployment, y para una app ya en marcha te explicó los tres pasos exactos: abrir Settings y Redeploy, agregar o editar variables en Environment variables, guardar y volver a desplegar.

Pregunta 2 presionó sobre las dos brechas que yo mismo había encontrado explorando el dashboard, la frase “managed MySQL” frente al formulario manual de creación, y SSH apareciendo inactive por defecto:

Este plan anuncia managed MySQL, pero el dashboard muestra un formulario manual ‘Create a New MySQL Database’ en vez de una base de datos provisionada automáticamente. ¿Se crea una base de datos para cada Web App por defecto, o sólo si yo la creo? Además, el acceso SSH figura como disponible pero aparece Inactive por defecto. Si nunca lo habilito, ¿eso cambia algo en cómo corre realmente mi app, o SSH es sólo un extra opcional para usuarios avanzados?

La respuesta de Kodee confirmó exactamente lo que yo había encontrado en la interfaz, no una versión más suave. No se crea una base de datos automáticamente para cada Web App; “managed” se refiere a que Hostinger administra el servicio e infraestructura de la base de datos, mientras que crear y configurar una base de datos real queda en tus manos, a través de la misma pantalla Create a New MySQL Database que ya había visto, y después agregando vos mismo sus datos de conexión como variables de entorno de tu app.

Sobre SSH, confirmó que dejarlo inactive no cambia nada en cómo corre, se despliega o se conecta a una base de datos la app. Está pensado puramente como una herramienta opcional para comandos CLI, migraciones o debugging directo de archivos, no como algo de lo que la plataforma dependa silenciosamente en segundo plano.

Lo que pensé: Ambas respuestas coincidieron con lo que yo ya había verificado a mano en el dashboard en lugar de contradecirlo o suavizarlo, que es la marca de una herramienta de soporte que realmente revisa el estado real del producto y no recita un guion. Ninguna de las dos preguntas podía responderse pegando una FAQ genérica, y Kodee manejó ambas con respuestas específicas, estructuradas, de dos partes, en alrededor de un minuto cada una.

2. Base de conocimiento

La base de conocimiento de Hostinger se abre en una grilla categorizada, 20 categorías en total, cada una mostrando una cantidad de artículos. Algunas de las más grandes: AI Builder tiene 330 artículos, VPS tiene 276, Email tiene 127 y Website tiene 103.

Web Apps Hosting no tiene su propia categoría dedicada. Su contenido está repartido entre Getting Started, hPanel y Website, lo cual es un hallazgo real para cualquiera que espere una sola base central, como la que tienen VPS o Email.

Buscar “Web Apps” directamente devolvió 71 resultados en 8 páginas. Los primeros resultados eran una mezcla de contenido directamente relevante y otro apenas relacionado:

• How to deploy apps built with Codex on Hostinger, directamente relevante
• Hostinger AI Builder: How to create a web app in agentic mode, relacionado pero de otro producto
• How to add a Node.js Web App in Hostinger, directamente relevante
• How to install Flutter Web on a VPS at Hostinger, un producto distinto por completo
• Varios artículos de pago de Website Builder (PayPal, WeChat Pay, BLIK), no relacionados más allá de compartir las palabras “web” y “app” en algún lado del texto

Abrí uno de los primeros resultados, How to deploy apps built with Codex on Hostinger, para ver su profundidad. Resultó ser un tutorial sólido y bien estructurado, con frameworks soportados listados al principio, pasos con capturas para ambos caminos, GitHub-import y ZIP-upload, una sección sobre configurar build settings con comandos de ejemplo, un desglose de la estructura de archivos después del deploy, un recorrido por el asistente de conexión a base de datos, una sección de monitoreo de vulnerabilidades y un bloque final de FAQ.

Aunque está planteado alrededor de Codex específicamente, la plataforma subyacente es la misma que está detrás del producto general Node.js Web App, así que la mayor parte aplica directamente.

Lo que pensé: La cantidad de artículos que devuelve la búsqueda parece fuerte en papel, 71 resultados para un término, pero una parte importante de ese volumen es ruido de otros productos que comparten palabras parecidas. El artículo que abrí completo sí estuvo a la altura en calidad una vez que entré, pasos claros, capturas reales y una sección de FAQ genuina, pero encontrarlo requirió pasar por resultados que no tenían nada que ver con lo que yo estaba intentando desplegar.

Veredicto general sobre atención al cliente

Simple Hosting for Modern Web Apps

Deploy React, Next.js, Vue, Node.js, and other modern applications without managing servers or complex infrastructure.

Visita Hostinger

¿Recomendamos Hostinger Web Apps Hosting?

Sí. El proceso de deploy es la parte más fuerte de este producto: autodetección correcta de mi stack, branch y versión de Node, un log de build real en streaming en vez de un spinner, y una app en vivo que pasó todos los tests de rendimiento que le tiré, puntajes perfectos de GTmetrix desde dos continentes distintos, una verificación global limpia de 54 puntos, y puntajes 100/100 coincidentes de la propia herramienta de Hostinger tanto en desktop como en mobile. Kodee respaldó todo eso con respuestas precisas y específicas a preguntas técnicas reales, en vez de respuestas genéricas de guion.

Los puntos flojos son chicos pero conviene conocerlos antes de comprar. “Managed MySQL” en la página del plan suena como algo listo en cuanto tu app sale en vivo, y en la práctica significa un formulario de creación manual. El dashboard también deja a Web Apps Hosting sin una entrada dedicada desde la pantalla principal Home; tenés que saber entrar por Websites primero.

Para un desarrollador que quiere un deploy rápido y agnóstico al framework sobre infraestructura que rinde así de bien, esto es una recomendación fácil. Para alguien que espera que cada función anunciada esté activada en cuanto se completa el checkout, conviene reservar unos minutos extra para configurar la base de datos por tu cuenta.

Hostinger

5.0

2,473 user reviews

2.420 $ /mo

Precio inicial

Visita Hostinger

Rating based on expert review

• Fácil de usar
  4.9
• Soporte técnico
  4.9
• Características
  4.8
• Confiabilidad
  4.7
• Tarifas
  4.5