Dónde alojar una web creada con IA

Has creado una web con ChatGPT, Claude, Cursor, Bolt o Lovable y funciona en tu ordenador. Para publicarla, la pregunta decisiva es qué necesita ejecutar el proyecto cuando lo visita alguien. El nombre de la herramienta que escribió el código no determina el alojamiento.

Mejor alojamiento para proyectos creados con IA: comparativa 2026

No existe un ganador universal: el código generado puede ser una web estática, una app con renderizado de servidor o un conjunto de frontend, API y base de datos. Esta comparativa editorial se revisó el 9 de octubre de 2026 con las páginas públicas de producto y precios enlazadas abajo. Compara flujos y límites; no es una prueba independiente de velocidad, disponibilidad ni soporte.

Para un frontend estático desde Git, compara Projects con Netlify y Vercel según framework, flujo y facturación. Para Next.js con SSR, valida el runtime exacto; una exportación estática cambia los requisitos. Para Docker o tareas en segundo plano, compara contenedores gestionados con VPS e incluye el tiempo de administración. Una base de datos externa, autenticación o almacenamiento no se trasladan al cambiar el frontend. Hostbrid opera infraestructura en España; consulta precios y límites de Sites, Projects y VPS. Vercel, Netlify y Hostinger pueden variar por país, moneda, impuestos y uso: revisa las condiciones Hobby de Vercel, los precios de Vercel y los precios y créditos de Netlify. Para hosting gestionado y coste total, consulta también hosting con mejor relación calidad-precio.

Elige alojamiento según lo que necesita ejecutar tu proyecto

• HTML, CSS o frontend estático generado desde Git: Projects construye y publica el repositorio. Comprueba el framework, el comando de build y la carpeta de salida; el nombre de la herramienta de IA no garantiza compatibilidad.
• WordPress, PHP o una web gestionada desde un panel: compara Sites y sus aplicaciones compatibles. Si es Node.js, consulta primero el flujo de Node Apps en Sites: requiere una app asociada a un dominio y tiene su propia configuración.
• Si gestionas webs de varios clientes: consulta la guía de alojamiento para agencias, que compara Sites Agency con las funciones propias de un servicio revendedor.
• API o proceso Node/Docker junto al frontend: considera servicios de Projects solo después de revisar el runtime, el plan, las cuotas, el puerto y el almacenamiento que necesita. Para Node.js, compara ese flujo con Sites y VPS.
• Docker Compose, paquetes del sistema o control root: un VPS permite administrar el entorno; tendrás que configurar y mantener el sistema y los servicios.

Si el proyecto expone herramientas mediante MCP y debe permanecer disponible por HTTP, consulta la guía para alojar tu propio servidor MCP en un VPS. Es distinto de conectar un asistente al MCP de Hostbrid para gestionar recursos de tu cuenta.

Si está hecho con Nuxt, comprueba si genera HTML estático o necesita Nitro en ejecución; la guía de Nuxt SSR en Projects separa ambos modos y muestra qué revisar en el build Node.

Para SvelteKit, el adaptador determina qué debe ejecutar el hosting. Consulta la guía de adapter-node en Projects si la app necesita servidor; si se puede prerenderizar, revisa la salida estática antes de contratar un runtime.

Si estás pensando en salir de Netlify, comprueba primero si la web usa formularios, funciones o vistas previas que dependan de esa plataforma. La guía para migrar un sitio estático de Netlify a Projects repasa esas dependencias antes de cambiar DNS.

Si hay base de datos, autenticación o archivos, identifica dónde vivirá cada pieza antes de contratar: publicar el frontend no migra esos datos ni crea por sí solo un backend. Si conservas Supabase al mover un frontend Vite, sigue la guía de URL, RLS y redirecciones para revisar la conexión.

Guías para continuar según tu caso

Si la has creado con Cursor, separa el editor del servicio que publica la web: los Cloud Agents de Cursor pueden desplegar mediante Vercel si conectas una cuenta de Vercel. Si quieres llevar el código a otro proveedor, súbelo a Git y revisa antes qué framework, servidor y servicios externos necesita; la guía de Cursor sobre Git describe cómo clonar, enviar y sincronizar repositorios. Después puedes seguir la guía para publicar una web creada con Cursor en Projects.

Cuando el proyecto ya esté publicado, puedes conectar un dominio propio a Projects sin cambiar toda tu zona DNS ni interrumpir el correo. Si estás decidiendo entre publicar sin cuota mensual o pasar a un plan de pago, consulta alojamiento web gratis o de pago para comparar el subdominio y los límites de Dev con los servicios que necesita tu proyecto.

Si has creado el proyecto con Figma Make y quieres publicarlo desde su repositorio de GitHub, sigue la guía de Figma Make a Projects. Distingue ese flujo de Figma Sites, que tiene su propia opción de publicación. Si has creado con Claude Code, identifica primero si tu repositorio produce archivos estáticos o requiere un servidor; nuestra guía de Git y despliegue para Claude Code separa el agente del alojamiento.

Si has creado con Base44 y quieres mover el código fuera de su plataforma, consulta la guía de exportación a GitHub y hosting; cambiar el hosting del frontend no migra el backend ni los datos. Si has usado Google AI Studio, revisa qué parte de la app es estática y cuál necesita servidor antes de pasarla a GitHub y Projects; sus claves y servicios externos no se migran por sí solos.

Para proyectos concretos, consulta la guía de localhost a una URL pública, React y Vite desde Git, Astro y Markdown desde Git o Next.js como archivos estáticos. Cada recorrido comprueba un caso distinto; no implica que todas las funciones de esos proyectos sean compatibles con el mismo producto.

Una web estática: archivos que el navegador puede cargar

Una landing con HTML, CSS e imágenes puede servirse como archivos. Un proyecto React con Vite también puede producir archivos estáticos después de construirlo. Eso no significa que todas las aplicaciones React sean estáticas: revisa si hay código de servidor o servicios externos.

Mira package.json y el comando de construcción. En un proyecto Vite configurado para despliegue estático, npm run build genera normalmente dist; la carpeta puede cambiar en la configuración. No publiques node_modules ni confundas el servidor de desarrollo con el resultado de producción. Vite documenta este procedimiento.

Hostbrid Projects importa repositorios de GitHub, GitLab o Bitbucket, construye el proyecto y publica con HTTPS. Revisa el comando y la carpeta de salida que corresponden a tu repositorio. Este recorrido utiliza Git: descargar un ZIP de una herramienta no implica que exista una subida ZIP directa al panel.

Si tienes HTML y CSS sin backend, sigue la guía para publicar una web HTML creada con IA, con repositorio reutilizable, configuración y demo pública.

Si la web incluye un formulario, comprueba por separado la validación del navegador, el backend y la entrega del mensaje con nuestra guía de diagnóstico de formularios. Un éxito visual no demuestra correo recibido; el ejemplo original solo valida datos sintéticos localmente, sin enviar correo.

Una aplicación con servidor: un proceso que debe seguir funcionando

Si el proyecto ejecuta una API Node, genera páginas en cada petición o trae un servicio en Docker, necesita un entorno que ejecute ese proceso. Copiar únicamente los archivos del frontend dejaría fuera esa parte.

Projects también ofrece backends y contenedores mediante un plan de pago. Antes de elegirlo, identifica el comando de inicio, el puerto, las variables de entorno y cualquier almacenamiento persistente. Una carpeta llamada dist no demuestra por sí sola que la aplicación sea estática.

Si necesitas un proceso servidor, comprueba puerto, salud, rutas y memoria con nuestro ejemplo original de Node y Docker. La prueba de contenedor no demuestra un servicio público HTTPS.

Si tu aplicación usa Prisma y PostgreSQL, revisa cómo aplicar las migraciones en producción y comprobar los datos antes de mover el backend. Publicar el código no copia los registros de tu base local.

Un frontend con backend externo: conserva las dependencias

Una web estática puede usar un servicio externo para iniciar sesión, almacenar archivos o consultar datos. Al mover el frontend, esos servicios siguen siendo necesarios. Revisa las URLs autorizadas de autenticación, los dominios permitidos y las variables del nuevo despliegue.

Si el login falla al cambiar de dominio

Actualiza la URL del sitio y la lista de destinos permitidos en el proveedor de autenticación. Si usas OAuth, comprueba también que la URL de callback exacta del proveedor esté autorizada en la consola del proveedor social: la URL de retorno de tu aplicación y la callback del proveedor cumplen funciones distintas. Por ejemplo, Supabase recomienda usar la ruta exacta de producción y Auth0 compara las callback con su lista permitida. Con Firebase, revisa el dominio autorizado y el dominio authDomain que usa el flujo de redirección (documentación de Firebase).

Mantén separados el dominio de producción y las URLs de preview; limita las reglas comodín a los entornos que realmente controles. Después prueba desde una ventana privada el registro, el callback de OAuth, el cierre de sesión, la recuperación de contraseña y los enlaces de confirmación que utilice tu app. Abre también una ruta protegida directamente y recárgala. Si vuelve a localhost, muestra un error de callback o pierde la sesión, revisa la URL que envía el navegador y la configuración del proveedor; no publiques secretos para depurarlo.

En Lovable, comprueba la arquitectura concreta de tu proyecto antes de exportarlo: no todos tienen el mismo recorrido. Su documentación de alojamiento y propiedad describe las opciones. Una base PostgreSQL por sí sola no sustituye autenticación, almacenamiento y funciones de Supabase. Si has creado la app con Bolt o Replit, consulta también nuestras guías para mover Bolt Cloud a otro hosting y publicar un proyecto de Replit fuera de su plataforma.

Qué comprobar antes de contratar

1. Enumera las piezas: frontend, servidor, datos, login, archivos y servicios de terceros.
2. Confirma que cada pieza tendrá un destino compatible y calcula su coste total.
3. Revisa el plan y sus límites. Dev requiere tarjeta para activarlo; conectar un dominio y mantener servicios permanentes tiene condiciones distintas del despliegue estático gratuito. Registro y renovación del dominio se pagan aparte.
4. Mantén las claves privadas fuera del código que recibe el navegador y del repositorio.
5. Al publicar, prueba desde otro dispositivo: abre una ruta interna directamente y comprueba login, formularios y archivos cuando existan.

Si tu proyecto encaja en el recorrido Git, consulta Projects. Para WordPress y aplicaciones de alojamiento web, consulta Sites. Si no sabes qué arquitectura tienes, contacta con Hostbrid describiendo framework, backend y dependencias, sin enviar contraseñas ni claves privadas.

Si dudas entre un panel gestionado y tener acceso al sistema, compara hosting compartido y VPS según el runtime, el control y el mantenimiento que necesitas.

Si tu proyecto es WordPress, los archivos estáticos no sustituyen su base de datos ni sus medios. Revisa el diagnóstico de migración WordPress para comprobar SQL, uploads y URLs antes de valorar el destino.