Para desplegar una aplicación web, se compila en archivos estáticos, se colocan en un host que los sirva por HTTPS, se entregan al host los secretos que la app necesita y se apunta un nombre de dominio hacia él. Con un creador de apps con IA puede quedarse en el primer paso: el creador publica la app por usted. Si prefiere otro host, exporte el código a GitHub y conecte el repositorio a Vercel o Netlify, o ejecútelo en su propio servidor.
Esta guía parte de una app con backend en Supabase, que es lo que genera Cadrant, nuestro creador. No citamos los precios de los hosts de terceros: cambian a menudo, así que consulte las páginas de cada proveedor.
Las tres formas de desplegar una app web creada con IA
Hay tres lugares donde alojar la app: el alojamiento propio del creador, un host como Vercel o Netlify, o un servidor que usted administra. Se distinguen sobre todo por cuánto trabajo hace usted mismo.
- El alojamiento del creador. Pulsa Publicar y la app queda en línea en una URL del creador o en su propio dominio. No hay nada que configurar aparte del dominio. Su código permanece dentro del flujo del creador.
- Un host tras exportar a GitHub. Sube el código a un repositorio de GitHub, conecta el repositorio a un host y el host compila y despliega en cada push. Usted controla los ajustes de compilación y las variables de entorno.
- Su propio servidor. Alquila una máquina virtual, instala un servidor web, copia los archivos compilados y se encarga del certificado y de las actualizaciones. Es la opción con más control y más trabajo.
| Opción | Cómo se pone la app en línea | Lo que gestiona usted | Límites |
|---|---|---|---|
| Alojamiento del creador (Cadrant) | Botón Publicar, URL del creador o su dominio | Los registros DNS del dominio, el proyecto de Supabase | Ligado al creador: para irse hay que exportar el código, y en Cadrant eso requiere el plan Pro |
| Vercel o Netlify | Repositorio conectado al host, despliegue en cada push | Repositorio, ajustes de compilación, variables de entorno, DNS, el plan del host | Se aplican los límites del plan del host, y el código se edita en dos sitios salvo que el creador haga el push a GitHub por usted |
| Su propio servidor | Copia los archivos compilados a una máquina que usted administra | Todo: servidor, servidor web, renovación del certificado, actualizaciones de seguridad, copias de seguridad, monitorización | Tiempo. Vale la pena por cumplimiento normativo o requisitos especiales, rara vez para un primer lanzamiento |
Qué implica realmente desplegar
Desplegar son cuatro cosas: una compilación, la configuración que la app necesita al ejecutarse, una base de datos que se queda donde está y un certificado HTTPS. La primera y la última son automáticas en cualquier host moderno.
La compilación
Una app de React se escribe en archivos que un navegador no puede ejecutar directamente. La compilación los convierte en archivos HTML, JavaScript y CSS simples, normalmente en una carpeta llamada dist o build. El host ejecuta el comando de compilación (a menudo npm run build) y sirve esa carpeta.
Variables de entorno y secretos
Hay dos tipos de valores, y confundirlos es el error de lanzamiento más habitual. Los valores públicos, como la URL del proyecto de Supabase y su clave pública (anon), viajan dentro de la app y están pensados para ser visibles. Los valores secretos, como una clave secreta de Stripe o la clave de un proveedor de correo, nunca deben estar en el código de la app ni en una variable que la compilación exponga al navegador. Su lugar es el servidor.
En una app creada con Cadrant, los secretos viven en la pestaña Entorno del panel Base de datos y los leen las funciones edge de Supabase, de modo que nunca forman parte del paquete del frontend. Consulte la documentación de variables de entorno. Si despliega en otro lugar, el host solo le pide volver a introducir los valores públicos; los secretos se quedan en Supabase. Vercel indica que cada uno de sus entornos (vista previa, producción) puede tener sus propias variables, y así se mantienen las claves de prueba lejos de las reales.
La base de datos se queda en Supabase
Mover el frontend a otro host no mueve los datos. La base de datos, las cuentas de usuario y los archivos siguen en el proyecto de Supabase, que está en su propia cuenta de Supabase. Por eso cambiar de host lleva minutos y no pierde nada. Tras cualquier cambio de dirección hay dos cosas que hacer: añadir el nuevo dominio en los ajustes de Auth y probar el inicio de sesión. La documentación de Supabase dice que la Site URL, que por defecto es localhost, debe cambiarse por su URL de producción, y que las URL de redirección forman una lista de permitidas con la que deben coincidir las redirecciones de inicio de sesión. Si no se tocan, los correos de confirmación y de restablecimiento de contraseña apuntan al lugar equivocado. Los detalles están en la guía de URL de redirección de Supabase.
El certificado HTTPS
Los navegadores advierten a los usuarios de que eviten los sitios sin HTTPS, y el inicio de sesión no funciona correctamente sin él. Vercel, Netlify y Cadrant emiten y renuevan el certificado por usted una vez verificado el dominio. En su propio servidor, usted lo instala y lo renueva, normalmente con una herramienta de una autoridad certificadora gratuita, y debe asegurarse de que la renovación siga funcionando.
Cómo conectar un dominio propio
Conectar un dominio significa añadir registros DNS en la empresa donde gestiona el dominio para que el nombre apunte a su host. Cada host le indica los registros exactos; cópielos tal cual en lugar de sacarlos de un tutorial.
- Compre el dominio si no tiene uno. Para elegir nombre y extensión, lea cómo elegir la extensión de un nombre de dominio.
- Añada el dominio en los ajustes del host. El host le mostrará los registros que debe crear.
- Cree esos registros en su proveedor de DNS (su registrador, Cloudflare, etc.).
- Espere a que el host muestre el dominio como verificado, abra el sitio en el dominio y pruebe el inicio de sesión.
Registro A o CNAME
Un registro A apunta un nombre a una dirección IP, y un registro CNAME apunta un nombre a otro nombre. La documentación de Vercel dice que un dominio apex como example.com se configura con un registro A y un subdominio como app.example.com con un registro CNAME, y que cada proyecto tiene su propio valor de CNAME. La documentación de Netlify recomienda, para el dominio apex, un registro ALIAS si su proveedor de DNS lo admite y, si no, un registro A, además de un CNAME para www. Los valores cambian según el host y el proyecto, así que use los que muestra su panel.
Dominio apex o www
El dominio apex (o raíz) es example.com, sin nada delante. Un subdominio es lo que va delante, como www o app. En el DNS estándar un CNAME no puede ir en el apex, por eso las configuraciones de apex usan registros A, ALIAS o ANAME. Netlify recomienda encarecidamente que un subdominio www sea su dominio principal, porque un apex como principal puede perjudicar el rendimiento con algunos proveedores de DNS. La propia documentación de Cadrant da el mismo consejo: prefiera un subdominio como app.misitio.com para evitar los límites de los dominios raíz. Añada ambas versiones y redirija una a la otra, para que los visitantes lleguen a la app de cualquier forma.
Propagación del DNS
Un cambio de DNS puede tardar de unos minutos a un día o más en llegar a todo el mundo. La documentación de Netlify indica que se debe contar con hasta 48 horas. Compruebe el avance con una herramienta como dnschecker.org o con el comando dig, y busque registros antiguos que entren en conflicto en el mismo nombre: un registro A o CNAME antiguo es la causa habitual de un dominio que nunca se valida.
Cómo publica Cadrant
Cadrant publica desde el botón Publicar: usted elige un slug para una URL de Cadrant como su-app.cadrant.app, o selecciona un dominio propio que haya añadido en la sección Dominios. El alojamiento HTTPS y un dominio propio están incluidos en todos los planes de pago, y una app publicada no consume créditos.
Para un dominio propio, Cadrant muestra tres registros DNS que hay que crear en su registrador: un registro TXT que prueba la titularidad, un CNAME que valida el certificado y permite su renovación automática, y un CNAME de enrutamiento. Para un dominio raíz, el registro de enrutamiento necesita un ALIAS o ANAME si su proveedor lo admite. La validación tarda de unos minutos a unas horas; un botón Actualizar refresca el estado. Al pulsar Publicar de nuevo se reemplaza la versión en vivo, y puede despublicar en cualquier momento. Los pasos completos están en la documentación de publicación.
El límite que conviene conocer: este es el alojamiento del creador. Si quiere su propio host, la exportación del código y el push a GitHub están en el plan Pro. Los precios figuran en la página de precios, y el creador se describe en la página del creador de apps con IA.
Pruebe en una copia de pruebas antes de tocar la app en vivo
Una copia de pruebas (staging) es un segundo despliegue de la app, con su propia dirección y sus propios datos de prueba, donde se verifica un cambio antes de que lo vean los usuarios reales. Cuando la gente ya depende de su app, pruebe primero ahí.
En un host, esto viene integrado. Vercel crea un despliegue de vista previa, con su propia URL, para cada rama o pull request, y permite asignar un dominio de staging y variables de entorno separadas. Su documentación indica que los despliegues de vista previa no usan las variables de producción y que una compilación de producción también puede quedar retenida hasta que usted la promueva. Netlify ofrece vistas previas de despliegue similares. El sentido de separar las variables es usar un proyecto de Supabase distinto para staging, de modo que una prueba nunca toque a clientes reales.
En un creador, la copia de pruebas más sencilla es un proyecto duplicado conectado a un segundo proyecto de Supabase y publicado en un segundo subdominio como staging.sudominio.com. Cambie y pruebe ahí, y luego repita el cambio en el proyecto en vivo. Cuesta un hueco de proyecto, y las dos copias pueden divergir, así que mantenga corta la lista de cambios. Aplique primero los cambios de base de datos en staging y revise las políticas como se explica en nuestra guía de seguridad a nivel de fila en Supabase.
Cómo revertir un mal despliegue
Revertir significa devolver la app en vivo a la última versión que funcionaba, y solo es rápido si se conservó la versión anterior. Decida cómo lo haría antes de necesitarlo.
- En Cadrant. Cada prompt crea una versión nueva, que se conserva indefinidamente. Puede previsualizar cualquier versión anterior y volver a ella. Revertir no borra las versiones posteriores, así que puede avanzar de nuevo. Tras revertir, pulse Publicar para poner esa versión en línea. Revertir restaura la app, no los datos que ya se hayan modificado en la base de datos. Consulte la documentación de versiones.
- En un host. Los hosts conservan los despliegues anteriores y pueden reasignar el dominio de producción a uno más antiguo, o bien usted revierte el commit en Git y deja que el host vuelva a desplegar.
- En su propio servidor. Conserve la carpeta de la compilación anterior junto a la actual y vuelva a ella cuando haga falta.
Lista de comprobación antes del lanzamiento
Antes de decir a nadie que la app está en línea, revise estos diez puntos. La mayoría de los problemas de lanzamiento están en esta lista.
Para profundizar en la seguridad, consulte nuestra guía de seguridad en el vibe coding. Para comparar lo que puede hacer la app antes de comprometerse con un creador, parta de la lista de creadores de apps con IA.