Qué le pasó a Lovable

Qué es y por qué importa

En abril de 2026 The Register contó el aviso de un investigador sobre Lovable, y Lovable explicó después el incidente en su blog: entre febrero y abril, por un problema en su backend, los chats y el código de los proyectos públicos podían ser vistos por otros usuarios. Lovable dice que los proyectos privados no se vieron afectados y que el problema está corregido. Si tienes un proyecto allí, lee su post.

No tengo nada contra Lovable. Esta historia solo me recordó lo importante que es saber dónde vive tu proyecto y quién tiene sus claves. Si vive dentro de una plataforma, la seguridad de la plataforma es la tuya. Si vive en una carpeta tuya, con tus claves, los errores son tuyos, y al menos los puedes corregir.

La cuestión es que un proyecto no es solo el código: están los datos, las cuentas de los usuarios, los archivos subidos, las claves, el dominio. Cada pieza sale por una puerta distinta, y si te olvidas de una, te das cuenta cuando un usuario ya no puede entrar.

Aquí abajo está cómo sacarlo todo. Uso los menús de Lovable, pero la lógica vale para cualquier plataforma. Y sirve aunque te quedes: tener una copia tuya es sentido común.

Una regla antes que nada: no borres nada hasta que lo nuevo funcione.

1. El código

En Lovable: Project settings → Git → GitHub. Conectas tu cuenta y haces que cree el repositorio: Lovable lo crea privado y lo mantiene sincronizado en los dos sentidos, lo que cambias en Lovable va a GitHub y viceversa.

La sincronización sigue una sola rama, normalmente main. Mientras esté activa, haz las pruebas en una rama aparte y no tocarás el proyecto dentro de Lovable.

Si tu plan lo tiene, en el mismo menú está también «Download codebase»: el zip de todo el código. Bueno como copia de seguridad, pero no se actualiza.

Luego clonas el repositorio en tu ordenador, desde el botón «Code» de la página del repo en GitHub. A partir de aquí es una carpeta tuya.

2. La base de datos

El código lleva la estructura de la base de datos, no los datos. La estructura está en las migrations: archivos SQL, normalmente en la carpeta supabase/migrations, que vuelven a crear tablas, columnas y reglas de acceso. Los datos, es decir, las filas de verdad, los exportas aparte.

Para el esquema y los datos, con el backend integrado de Lovable (Lovable Cloud) usas la exportación de la base de datos desde la configuración avanzada: More → Cloud → Overview → Advanced settings → Export data. El enlace llega por correo. Es un archivo de copia de seguridad de Postgres, no un archivo SQL para pegar: se restaura con pg_restore. Si en cambio tienes la cadena de conexión de la base de datos, usas pg_dump. En Supabase la cadena la encuentras en el botón «Connect» del panel del proyecto, y su guía usa el comando supabase db dump.

Lo importas en un Postgres o Supabase tuyo, nuevo y vacío.

3. Los usuarios

Las cuentas de inicio de sesión no viajan con las tablas: si solo mueves los datos, los usuarios se quedan atrás.

La exportación completa de Lovable Cloud, en cambio, los incluye, con las contraseñas guardadas en forma cifrada. Si la restauras en un proyecto de Supabase, los usuarios conservan su contraseña. Dos cosas, eso sí, no pasan: las sesiones, así que todos tendrán que volver a iniciar sesión, y la configuración de los métodos de acceso, como «Iniciar sesión con Google», que vuelves a configurar en el nuevo.

Si llegas por otro camino y las contraseñas no se pueden llevar, prepara un correo de «restablece tu contraseña» para enviar el día del cambio.

4. Los archivos subidos

Fotos, documentos, avatares: no están en la base de datos ni en el código. En Lovable Cloud los encuentras en More → Cloud → Storage. Descárgalos y vuelve a subirlos al nuevo almacenamiento, en buckets (las «carpetas» del almacenamiento) con los mismos nombres.

Luego cuenta los archivos antes y después.

5. Las claves

Las variables secretas no salen ni con el código ni con la exportación de la base de datos. Y en Lovable los secretos no se pueden volver a leer, solo sustituir: el valor lo sacas del servicio que te lo dio.

Haz la lista de todas: base de datos, API, pagos, correo. Ponlas en tu .env en el ordenador y en la configuración del nuevo hosting. Las claves privadas nunca van en el código ni en git, y nunca en una variable que empiece por VITE_: esas acaban en el navegador, así que ahí solo valores públicos.

Luego regenéralas: claves nuevas, las viejas revocadas. Una clave que sigue siendo válida en una plataforma que ya no usas es una puerta que se queda abierta.

6. Dominio e inicio de sesión

Apunta el dominio al nuevo hosting, siguiendo las instrucciones de quien te aloja. La dirección lovable.app se queda en Lovable y sigue mostrando la última versión que publicaste allí.

Luego actualiza las URL de redirección del inicio de sesión: la dirección nueva hay que añadirla a las autorizadas por tu sistema de inicio de sesión. Si usas «Iniciar sesión con Google» o similares, actualízala también allí. Si se te olvida, el inicio de sesión se rompe justo en el dominio nuevo.

Con Claude Code, dentro de la carpeta

Abre el terminal en la carpeta del proyecto y arranca Claude Code (cd a la carpeta y luego claude). Lee los archivos solo. Yo le doy estas peticiones, en este orden.

Lee este proyecto y hazme la lista de todo lo que depende de la plataforma de la que viene: variables, servicios, URL, funciones en el servidor.

Este es tu mapa. Las funciones en el servidor son las que se ejecutan fuera del navegador: en los proyectos de Lovable con Supabase suelen estar en supabase/functions y hay que publicarlas aparte en el nuevo backend.

La siguiente la añado yo: te da la lista de claves del punto 5 sin tener que buscarlas a mano.

Hazme la lista de todas las variables de entorno que usa el proyecto: dónde se leen, cuáles acaban en el navegador y cuáles tienen que seguir siendo secretas. No escribas los valores.

Hazlo funcionar en local con mi base de datos nueva y dime qué falta.

Aquí salen las claves olvidadas y las tablas vacías. Claude Code te pide permiso antes de modificar archivos o lanzar comandos, según el modo de permisos que hayas elegido: lee lo que va a hacer antes de decir que sí.

Comprueba que ninguna clave esté escrita en el código ni en el historial de git.

Si encuentra una en el historial, borrar el archivo no basta: se queda en los commits viejos. Esa clave la regeneras, y punto.

7. Publica, prueba y luego apaga el viejo

Cuando en local va todo, publica en un hosting que controles tú. Luego prueba las cosas que se rompen primero:

1. El inicio de sesión: entra con una cuenta que ya existía y crea una nueva.
2. Una subida de archivo, y que se vuelva a abrir.
3. Los pagos, si los tienes, en modo de prueba.

Solo entonces apaga el viejo.

Errores comunes

• Borrar el proyecto viejo en cuanto tienes el repositorio. Mantenlo encendido hasta que en el nuevo funcionen inicio de sesión, archivos y pagos.
• Pensar que el repositorio es todo el proyecto. El código lleva la estructura; datos, usuarios, archivos y secretos salen cada uno por su lado.
• Importar los datos en una base de datos ya usada. Parte de un Postgres nuevo y vacío.
• Copiar las claves viejas en el nuevo y darlo por terminado. Regenéralas y revoca las viejas.
• Olvidar las URL de redirección. Añade el dominio nuevo a los autorizados por el inicio de sesión antes de moverlo.

Lista de comprobación

• Repositorio en GitHub, privado, clonado en el ordenador
• Estructura y datos en la nueva base de datos, vacía antes de importar
• Inicio de sesión probado con una cuenta vieja y una nueva
• Archivos descargados, vueltos a subir y contados
• Claves en la lista, regeneradas, las viejas revocadas
• Dominio y URL de redirección actualizados
• El viejo, apagado lo último

Preguntas frecuentes