Cómo migrar de Lovable Cloud a su propio proyecto de Supabase

Para migrar de Lovable Cloud a un Supabase propio, cree el proyecto de destino, aplique las migraciones del repositorio y restaure con pg_restore el .backup que exporta Lovable. Después copie los archivos, recree secretos, Edge Functions y tareas programadas, y cambie las variables de la app. Los usuarios conservan la contraseña. Las sesiones abiertas se cierran.

Recomendación de Heartscale: haga al menos un restore completo en un proyecto de Supabase de prueba y mida el tiempo antes de fijar el cambio final. Si la app ya tiene usuarios reales, inicio de sesión social o pagos, pida una revisión del plan antes de pausar las escrituras.

Esta guía cubre solo la base de datos y el backend. Para el código, el build, el servidor y el dominio, vea cómo salir de Lovable.

Lovable Cloud y Supabase: qué cambia

Lovable Cloud es el backend integrado de Lovable y está construido sobre Supabase (Lovable Cloud). Reúne base de datos, inicio de sesión, storage, Edge Functions, secretos, tareas y logs, y cobra todo del mismo saldo de créditos.

En un proyecto de Supabase propio, cada pieza pasa a ser suya: la cuenta, la facturación, el panel y el mantenimiento. Tres reglas de la documentación de Lovable:

• Los destinos soportados son Supabase gestionado y Supabase autoalojado. PostgreSQL puro u otro proveedor exigen recrear a mano el inicio de sesión, el storage y las funciones.
• Mover solo el PostgreSQL no mueve el inicio de sesión, el storage, el realtime ni las Edge Functions.
• No hay camino de vuelta: migrar de Supabase a Lovable Cloud no está soportado por ahora (Lovable Cloud).

Si elige autoalojar Supabase, la vía recomendada es Docker. La propia documentación de Supabase indica que backups, seguridad y mantenimiento de Postgres quedan a su cargo, y que el soporte viene de la comunidad.

Qué incluye la exportación y qué no

Según la página de Database backups:

Incluye	No incluye
Estructura y datos de la base	Archivos del storage
Cuentas de usuario	Código de las Edge Functions (está en el repositorio)
Hashes de contraseña	Secretos
	Configuración de los proveedores de inicio de sesión
	Claves de API del proyecto

Límites: bases de hasta 15 GB, archivo de hasta 5 GB y una exportación cada 24 horas. La base debe estar activa. Si el proyecto se pausó por falta de créditos, reactívelo antes de exportar.

El límite de 24 horas define el cronograma. Usted necesitará al menos dos exportaciones: una para la prueba y otra para el cambio final.

Paso 1: cree el proyecto de destino

En Supabase, haga clic en New project. Elija una contraseña fuerte para la base y una región cercana a los usuarios. Anote el Project ID, la URL (https://<id>.supabase.co) y la clave publicable.

Antes de restaurar, active en el proyecto nuevo las extensiones que usaba la base anterior y los Database Webhooks, si los había. La guía de backup y restauración de Supabase lo pide antes de cargar los datos.

Paso 2: aplique el esquema con las migraciones

El esquema viene de las migraciones guardadas en el repositorio. Según la documentación de Lovable:

• Carpeta supabase/migrations/: ejecute los archivos SQL en orden por el prefijo de fecha, del más antiguo al más nuevo.
• Carpeta drizzle/migrations/: siga el orden de meta/_journal.json. La CLI de Supabase no aplica ese formato.

Con la CLI, en el caso de Supabase:

npx supabase login
npx supabase link --project-ref <id-del-proyecto-nuevo>
npx supabase db push

Para revisar diferencias entre el repositorio y la base, ejecute npx supabase db diff --linked, con Docker abierto.

Las migraciones también crean los buckets y sus políticas de acceso. Revise que las políticas de RLS hayan llegado completas: vea cómo configurar RLS en Supabase.

Paso 3: exporte y restaure los datos

En Lovable, vaya a More → Database → Manage → Settings → Export project data → Export data. En la tarjeta Database, haga clic en Export y en Start export. Lovable avisa por correo. Descargue el archivo en More → Storage y guarde una copia fuera de Lovable.

El archivo es un .backup en formato custom de PostgreSQL, con compresión zstd. Si llega dentro de un .zip, extráigalo antes. pg_dump incorporó la compresión zstd en la versión 16 (notas de la versión 16), así que use un pg_restore 16 o más nuevo, compilado con zstd.

Como el esquema ya se aplicó en el paso 2, restaure solo los datos. El procedimiento, con las opciones descritas en la documentación de pg_restore:

# 1. lista el contenido del archivo
pg_restore --list export.backup > export.list

# 2. edite export.list: comente con ";" lo que no quiera restaurar

# 3. restaura solo los datos, en el orden de la lista, todo o nada
PGOPTIONS="-c session_replication_role=replica" \
pg_restore --data-only --no-owner --single-transaction \
  --use-list=export.list \
  --dbname "<cadena de conexión del Session pooler>" \
  export.backup

Qué hace cada parte:

• --data-only restaura los datos de las tablas y los valores de las secuencias, sin recrear el esquema.
• --single-transaction aplica todo o nada. Si algo falla, la base queda como estaba.
• session_replication_role = replica impide que los triggers se ejecuten durante la carga. Supabase usa la misma configuración en su guía de restauración. Sin ella, un trigger que crea un perfil por cada usuario nuevo crearía perfiles duplicados o haría fallar la carga. También desactiva la verificación de claves foráneas, así que compare la cantidad de filas después (PostgreSQL).
• La cadena de conexión del Session pooler funciona en redes solo IPv4. La conexión directa exige IPv6 o el complemento de IPv4.

En la lista, mantenga los datos de public, auth.users y auth.identities. Deje fuera las sesiones y los tokens de auth, que no sirven en el proyecto nuevo. Deje fuera también las tablas del esquema storage: los registros de los archivos se crean al subir los archivos en el paso 5.

Haga esto primero en un proyecto de prueba. Lovable advierte dos puntos: los registros que las migraciones ya insertaron pueden chocar con los del archivo, y los valores de las secuencias deben venir junto. No use --clean sin leer lo que hace: elimina los objetos antes de restaurarlos.

En nuestras revisiones, después del restore de prueba, comparamos la cantidad de filas de cada tabla de public y de auth.users en las dos bases. Solo entonces iniciamos sesión con una cuenta migrada y liberamos el cambio final.

Paso 4: inicio de sesión, con contraseñas y sin sesiones

Los hashes de contraseña vienen en el archivo, así que los usuarios entran con la misma contraseña. La guía de migración de usuarios de Supabase explica por qué se cierran las sesiones: cada proyecto firma los tokens con su propio secreto, y el token anterior deja de valer. Avise a los usuarios que deberán iniciar sesión de nuevo.

En el proyecto nuevo:

1. En Authentication → Sign In / Providers, active cada proveedor que usaba la app.
2. En la consola de cada proveedor (Google, GitHub y otros), cambie la URL de retorno por la del proyecto de Supabase nuevo.
3. En la página URL Configuration, complete el Site URL con la dirección de producción y liste en Redirect URLs las direcciones a las que puede volver el inicio de sesión (Redirect URLs). El Site URL se usa en los correos de confirmación y de cambio de contraseña.

Si alguna cuenta no vuelve, ofrezca un flujo de restablecimiento de contraseña.

Paso 5: archivos del storage

En Lovable, abra More → Storage y descargue los archivos de cada bucket. En Supabase, abra Storage y súbalos a buckets con los mismos nombres, manteniendo las carpetas. Si la base guarda la ruta de los archivos, depende de esos nombres. Si guarda la URL completa, apunta a la dirección del proyecto anterior y hay que actualizarla.

Antes de borrar nada, compare la cantidad de archivos de cada bucket en ambos lados.

Paso 6: secretos y Edge Functions

Los secretos no están en la exportación ni en el repositorio. Recree cada uno en la página Edge Function Secrets de Supabase o con la CLI (Secrets):

supabase secrets set --env-file .env.produccion
supabase secrets list

Los nombres que empiezan con SUPABASE_ están reservados. SUPABASE_URL y las claves del proyecto llegan a las funciones sin configuración.

El código de las funciones está en supabase/functions/. Publíquelo con:

npx supabase functions deploy

Paso 7: tareas programadas

Liste las tareas en el área de jobs de Lovable y compárelas con lo que existe en la base nueva después del restore. Recree las que faltan con cron.schedule en SQL. Las tareas que llaman a la app desde fuera necesitan un programador externo.

Revise la dirección y la credencial de cada tarea. Active las tareas del lado nuevo solo en el cambio final, para que la misma tarea no corra en las dos bases.

Paso 8: prueba y cambio final con la escritura pausada

Deje el proyecto de Lovable como está. En una copia separada de la app, configure VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY y VITE_SUPABASE_PROJECT_ID y vuelva a compilar: estas variables entran en el código al momento del build. En TanStack Start, configure también SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY y SUPABASE_PROJECT_ID.

Pruebe que la app abre, que graba y lee registros, que una cuenta migrada inicia sesión, que la subida y descarga de archivos funcionan y que las funciones responden. Mida cuánto tardaron la exportación y el restore.

En el cambio final, según la documentación de Lovable:

1. Reemplace en el código lo que todavía pasa por Lovable: conectores, funciones de IA y la dirección del backend integrado.
2. Pause las escrituras de usuarios, tareas, webhooks e integraciones.
3. Pida la exportación final y restáurela en el proyecto nuevo.
4. Copie los archivos que cambiaron desde la última copia.
5. En el .env, cambie las variables de Supabase. En supabase/config.toml, cambie el project_id.
6. Active las tareas programadas del lado nuevo y reabra la app.

El tiempo medido en la prueba es el tiempo que la app queda sin escribir.

Antes de eliminar Lovable Cloud

Eliminar la base en More → Database → Manage → Settings → Remove database borra la base, los backups, las cuentas y los archivos. Eso incluye las exportaciones guardadas en el storage del proyecto, y no tiene vuelta atrás (Lovable Cloud). Descargue y revise todo antes.

El .backup contiene hashes de contraseña y datos personales. Guárdelo en un lugar seguro y borre las copias sueltas. La suscripción y el uso de Lovable Cloud continúan hasta que usted cambie el plan.

¿Hacerlo usted mismo o contratar?

Esta guía basta para muchos proyectos. Lo que cambia la decisión es el costo de un cambio final que salga mal.

Situación	Camino
App en pruebas, sin usuarios reales, y alguien del equipo usa la terminal y SQL	Hágalo usted mismo con esta guía, primero en un proyecto de prueba
Usuarios reales que inician sesión con Google u otro proveedor	Conviene llamar a un equipo: sesiones, URLs de retorno y restablecimiento de contraseña deben cerrar en la misma ventana
Pagos, webhooks o tareas programadas que escriben en la base	Conviene llamar a un equipo como el nuestro: la pausa de escritura debe cubrir todas las entradas
Datos personales en la base, plazo corto o nadie técnico en el equipo	Solicite el diagnóstico de Heartscale antes de exportar: recibe el plan y el tiempo estimado de pausa antes de tocar la base

Solicite un diagnóstico de Heartscale

Nuestro equipo mide la base y el storage, lista las tareas, los secretos y las funciones de su proyecto y hace el restore en un Supabase de prueba antes del cambio. Usted recibe el plan de migración de plataforma, con el tiempo estimado de pausa y un precio cerrado.

El diagnóstico, a precio de lanzamiento, cuesta US$ 19 (antes US$ 79) y se descuenta si contrata la migración. Solo trabajamos en apps de quien demuestra ser su dueño.

Solicitar el diagnóstico