Cómo salir de Lovable: código, base de datos y dominio, paso a paso

Salir de Lovable no es apretar un botón. Son tres cambios: el código, la base de datos y la dirección. Esta guía sigue la documentación oficial de Lovable (Deploying and hosting outside Lovable) y explica cada paso en español.

Antes de empezar: qué sale y qué se queda

Lovable indica que usted es dueño del código y de los datos que crea, y que ambos se pueden exportar (Deployment, hosting and ownership). Pero no todo sale junto:

• Sale: el código (front-end y funciones), la base de datos con los datos, las cuentas de los usuarios con sus contraseñas y los archivos subidos.
• Se queda: el editor y el agente de IA de Lovable, que no corren fuera de la plataforma.
• Necesita reemplazo: los conectores de apps y los recursos de IA que corren a través de Lovable. No se exportan.

Otro punto de la documentación: cada parte que usted saca pasa a ser suya para mantener, proteger y actualizar. Si el motivo de la salida es el costo, sume el tiempo de mantenimiento a la cuenta.

Decida también si va a sacar solo el sitio (el front-end) o también el backend. Es posible migrar solo el front-end y mantener la base en Lovable Cloud por un tiempo.

Paso 1: obtenga el código

Hay dos caminos (GitHub y Deploying outside Lovable):

• Git sync, en todos los planes. En Project settings → Git, conecte GitHub. Lovable crea un repositorio nuevo, privado por defecto, y sincroniza en los dos sentidos. No se conecta a un repositorio existente y sincroniza solo una rama a la vez, en general main.
• Download codebase, en los planes pagos. Descarga un .zip con el código de ese momento.

Prefiera Git sync. Mantiene el historial y permite que el servidor nuevo haga deploy en cada push.

Ninguno de los dos incluye los datos de la base ni los archivos subidos por los usuarios. Eso queda para el paso 6.

Paso 2: identifique su stack

Abra el package.json del repositorio.

• ¿Tiene @tanstack/react-start? Es TanStack Start, el modelo de los proyectos creados a partir del 13/05/2026. Necesita un servidor en ejecución, no solo archivos estáticos.
• ¿No lo tiene? Es el modelo antiguo, React + Vite. El build genera archivos estáticos en la carpeta dist/, y cualquier hosting de sitios estáticos sirve.

Esa diferencia lo cambia todo de aquí en adelante. Muchas guías en internet se escribieron antes de TanStack Start y solo cubren el caso estático.

Paso 3: haga el build

Comandos de la documentación de Lovable:

React + Vite

npm ci
npm run build
# salida en dist/

TanStack Start, para servidor propio o contenedor

npm ci
NITRO_PRESET=node-server npm run build
node .output/server/index.mjs
# escucha en el puerto 3000; PORT y HOST lo cambian

Si el repositorio solo tiene bun.lock, use Bun o genere y versione un package-lock.json antes de ejecutar npm ci. Use Node 22.

Paso 4: configure las variables de entorno

Los valores están en el archivo .env del proyecto. Las variables que empiezan con VITE_ entran en el código en el momento del build: si cambia una, debe volver a hacer el build.

• En el navegador: VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY y VITE_SUPABASE_PROJECT_ID.
• En el servidor (TanStack Start): SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_PROJECT_ID y los secretos de las funciones. Los secretos no están en el repositorio. Tendrá que recrearlos.

Paso 5: súbalo al servidor

Sitio estático (React + Vite) en un VPS: copie dist/ al servidor y configure Nginx para enviar toda ruta a index.html:

location / {
  try_files $uri $uri/ /index.html;
}

Después, active HTTPS, por ejemplo con Certbot.

TanStack Start: ejecute el servidor Node del paso 3 detrás de un proxy inverso que se encargue del HTTPS. Aquí try_files no aplica: las rutas las maneja el servidor.

Docker: Lovable sugiere un build en dos etapas, con node:22-alpine para el build y nginx:alpine para servir dist/.

Si prefiere un panel en lugar de configurarlo todo a mano, Coolify se instala en un VPS Linux, hace el deploy desde GitHub y se encarga del HTTPS.

Paso 6: migre la base de datos de Lovable Cloud

Si la app usa Lovable Cloud, el destino compatible es un proyecto de Supabase, administrado o instalado por usted (Deployment, hosting and ownership). El orden que sugiere la documentación:

1. Cree un proyecto nuevo en Supabase y anote la URL, el ID y la clave publicable.
2. Aplique las migraciones en orden: supabase/migrations/ (por la fecha en el nombre) o drizzle/migrations/ (por el _journal.json).
3. Exporte los datos: More → Database → Manage → Settings → Export data. El archivo es un .backup de PostgreSQL, no un SQL. Restáurelo con pg_restore primero en un proyecto de prueba. No use --clean sin leer lo que hace: borra objetos.
4. Vuelva a configurar los proveedores de login y las URL de retorno.
5. Copie los archivos de More → Storage a buckets con los mismos nombres.
6. Recree los secretos y publique las Edge Functions con npx supabase functions deploy.
7. Recree las tareas programadas. No deje la misma tarea corriendo en las dos bases.
8. Apunte una copia de prueba de la app a la base nueva y revísela.
9. En el cambio definitivo, actualice el .env y el project_id de supabase/config.toml.

Qué incluye la exportación y qué no (Database backups):

• Incluye: estructura y datos de la base, cuentas de usuario y hashes de contraseña. Los usuarios conservan su contraseña. Quien tenga la sesión abierta al momento del cambio debe volver a entrar.
• No incluye: archivos del storage, código de las Edge Functions, secretos, configuración de los proveedores de login ni claves de API.
• Límites: base de hasta 15 GB, archivo de hasta 5 GB y una exportación cada 24 horas. Una base más grande requiere hablar con el soporte.

El .backup contiene hashes de contraseña y datos personales. Guárdelo en un lugar seguro y borre las copias sueltas después.

Paso 7: pruebe antes de cambiar el tráfico

La documentación indica cuatro pruebas:

• Abra una ruta interna directamente por su dirección y recargue. Un error 404 indica que falta el fallback a index.html o que falta el servidor.
• Entre y salga de la app. Un error de redirección suele ser la URL nueva que falta en la lista de retornos del login.
• Lea, grabe y suba un archivo.
• En TanStack Start, abra una página renderizada en el servidor y llame a una función de servidor.

Paso 8: cambie el dominio

Apunte el dominio al servidor nuevo, siguiendo el paso a paso de DNS y certificado de su proveedor. La dirección lovable.app sigue sirviendo la última versión publicada, y el botón Publish sigue publicando solo en Lovable.

Paso 9: reemplace lo que deja de funcionar

Fuera de Lovable dejan de funcionar (Deploying outside Lovable):

• los conectores de apps y los recursos de IA que corren a través de Lovable;
• los conectores de chat (servidores MCP), que solo existen en el chat del proyecto;
• el OAuth administrado y la renovación automática de tokens, que dependen del backend de Lovable.

Busque en el código las llamadas a esos recursos y reemplácelas por integraciones propias. Lovable tampoco monitorea ni depura un servidor que es suyo.

Paso 10: cierre la migración

1. Planifique la copia final de los datos. Pause las escrituras de usuarios, tareas, webhooks e integraciones. Haga la última exportación, copie los archivos modificados, restaure y solo entonces haga el cambio.
2. Mida en la prueba el tiempo de exportar y restaurar, para saber cuánto tiempo queda detenida la app.
3. Despublique la app en Lovable cuando ya no quiera lovable.app en línea.
4. Antes de eliminar la base de Lovable Cloud, descargue y revise las exportaciones y los archivos. La eliminación borra la base, los backups, las cuentas y los archivos, y no tiene vuelta atrás (Lovable Cloud).
5. Recuerde que exportar el código no cancela nada. La suscripción y el uso de Lovable Cloud continúan hasta que usted cambie el plan.

Cuánto tiempo lleva

Depende del tamaño de la base, del número de integraciones y de cuántos recursos de Lovable usa la app. Un sitio estático sin base de datos es el caso más simple: pasos 1 a 5, 7 y 8. Una app con login, archivos, funciones y pagos requiere una prueba completa antes del cambio. Empiece por el paso 2: el stack dice casi todo sobre el tamaño del trabajo.

Pida el diagnóstico de Heartscale

Ya migramos clientes de Lovable, Wix y Tray. En Heartscale, el diagnóstico mapea qué usa su app de Lovable, el tamaño de la base, las integraciones que necesitan reemplazo y los riesgos de seguridad que se trasladan con la migración. Usted recibe un informe con el plan de migración y un precio cerrado.

El diagnóstico cuesta US$ 79 y se descuenta si contrata la migración. Solo trabajamos en apps de quien demuestra ser su dueño.

Pedir el diagnóstico de mi app