Las alternativas a Lovable se dividen en dos categorías. Responden preguntas diferentes. Cuando estás iniciando un producto, seleccionas un flujo de trabajo y decides quién opera el backend después de que la primera versión funcione. Cuando ya ejecutas una aplicación Lovable funcional, tu primer trabajo es un inventario: la propia documentación de Lovable establece que la fuente de la aplicación te pertenece y que moverla es un cambio de implementación en lugar de una reescritura. El trabajo difícil está en otra parte. Los datos y servicios demandan el trabajo real. A continuación hay cinco partes, en orden: una tabla de nueva construcción, los hechos actuales de portabilidad, una verificación de marco, una tabla de aplicación existente y una lista de verificación de aceptación de producción.
Dos lectores, dos decisiones diferentes
Cuando comienzas desde cero, compara cómo se ajusta cada herramienta a tu flujo de trabajo y qué tendrás que mantener una vez que la demostración funcione. La demostración es la parte fácil. El constructor importa menos que quién opera la base de datos, la canalización de implementación y el sistema de inicio de sesión seis meses después.
Para una aplicación ya funcionando, detente antes de reconstruirla en otra herramienta. Comienza con el inventario. Identifica de qué depende: dónde vive el código, dónde se ejecuta el frontend, cuál backend almacena los datos, y qué características de IA y conectores se enrutan a través de Lovable en tiempo de ejecución.
Y aquí está la parte que la gente se salta. Permanecer en Lovable es una opción perfectamente válida. La guía de propiedad de Lovable etiqueta su configuración administrada como la recomendación para la mayoría de las aplicaciones y dice que muevas componentes solo cuando encuentres una restricción real, como un mandato de residencia de datos, redes no compatibles o una política que requiera alojamiento autogestionado. Si ninguno de esos se aplica y nadie en tu equipo quiere asumir operaciones adicionales, el cambio es un costo sin beneficio.
Nueva construcción: la tabla de decisión
Esta tabla representa mi criterio. La he extraído de la documentación propia de cada proveedor donde está disponible. No es un ranking y no afirma cuál herramienta produce aplicaciones mejores.
| Opción | Flujo de trabajo que se adapta | Modelo de código y repositorio | Responsabilidad de backend e implementación | Tarea de prueba de ajuste |
|---|---|---|---|---|
| Lovable | Construcciones impulsadas por chat donde una plataforma maneja edición, alojamiento y backend | Código gestionado en Lovable; sincronización de Git a GitHub, GitLab o Bitbucket en todos los planes | Lovable puede ejecutar alojamiento y el backend integrado; asumes operaciones solo para partes que muevas | Construye el flujo, sincroniza a Git, luego clona y ejecútalo localmente |
| v0 | Trabajo de solicitud a aplicación que termina en revisión e implementación | Código real; v0 documenta implementación o abre una solicitud de extracción para revisión | Implementación de un clic en infraestructura impulsada por Vercel; backend se conecta a través de integraciones | Implementa el flujo, luego cámbialo a través de una solicitud de extracción |
| Bolt | Construcción basada en navegador donde tienes tu propio historial de Git | Bolt documenta una integración con Git; confirma el viaje completo en un repositorio de prueba | Bolt Cloud incluye alojamiento, una base de datos integrada, autenticación, almacenamiento y funciones de servidor | Construye el flujo con datos persistentes e inicio de sesión, publícalo y verifica el flujo de trabajo de Git |
| Replit | Construcción y alojamiento dentro de un único espacio de trabajo en la nube | El proyecto vive en el espacio de trabajo de Replit; verifica sus opciones actuales de Git | Replit documenta la publicación a través de Deployments; confirma qué tipo ejecuta código de servidor | Publica el flujo, redespliega y verifica que los datos persistan |
| Repositorio de tu propiedad con herramientas lideradas por desarrolladores | Equipos con ingenieros, revisión de código y una canalización existente | Tu propio repositorio, cualquier editor o agente de codificación | Ejecutas CI/CD, alojamiento, base de datos y autenticación | Crea un inicio, construye el flujo, envíalo a través de tu canalización |
La última fila describe un flujo de trabajo, no un producto listo para usar. Ensamblas las partes tú mismo. Eliges un stack, un host y un agente o editor, luego asumes todo el trabajo operativo que se detalla más adelante. Si estás evaluando frameworks para esa ruta, Astro vs Next.js y la página Next.js y Supabase cubren los puntos de partida estándar.
La tarea de prueba tiene la misma forma para cada candidato. Mantenla pequeña, pero hazla real. Construye un flujo de usuario realista con datos persistentes, autenticación e implementación en vivo. Una captura de pantalla generada no prueba nada. Registrarse en una cuenta, persistir un registro, cerrar sesión, volver a iniciar sesión y ver ese registro nuevamente prueba mucho.
Lo que Lovable realmente te permite llevarte
Los hechos de portabilidad actuales provienen de la guía de implementación y la guía de propiedad de Lovable:
- La sincronización con Git está disponible en todos los planes (GitHub, GitLab, Bitbucket). Descargar base de código, una captura .zip única, está disponible en planes pagos.
- Ambas rutas te dan el código fuente de la aplicación, incluida la configuración y los archivos de migración de la base de datos. Ninguna incluye los registros en tu base de datos ni los archivos en almacenamiento.
- Las filas de la base de datos y los archivos de almacenamiento necesitan exportaciones separadas, y los verificas en el destino antes de retirar el original.
- Puedes mantener Lovable como la herramienta de desarrollo mientras otro host sirve producción. Conecta el repositorio a través de sincronización con Git y deja que el otro host lo despliegue.
La integración con GitHub tiene restricciones que vale la pena señalar. Algunas son operacionalmente incómodas. Lovable edita y sincroniza solo una rama a la vez. La sincronización con Git siempre aprovisiona un repositorio nuevo y no puede adjuntar un proyecto a uno existente, y reconectar después de una desconexión crea otro repositorio nuevo. El repositorio es privado de forma predeterminada. Eliminarlo detiene la sincronización.
El código no está bloqueado, entonces. Eso es útil, pero no es la migración completa. Almacenar el código fuente en tu repositorio no elimina las dependencias en tiempo de ejecución de Lovable. Ten esa distinción en mente para la tabla de aplicación existente.
Verifica el framework antes de elegir un host
La documentación de Lovable indica que las nuevas apps creadas después del 13 de mayo de 2026 usan TanStack Start, que ejecuta código en el servidor. Las apps antiguas son diferentes. Dependen de React más Vite y generan archivos estáticos. La documentación de integración de Supabase menciona el 22 de junio de 2026 para planes Enterprise en una capacidad relacionada, pagos integrados con tu propio proyecto de Supabase, así que evita aplicar una regla de fecha de creación uniforme a todas las cuentas.
Inspecciona tu proyecto real en su lugar. Abre package.json en la pestaña Code. Un proyecto de TanStack Start lista @tanstack/react-start bajo sus dependencias. Un proyecto antiguo de React y Vite no lo hace.
Las consecuencias de alojamiento son diferentes:
- TanStack Start: el host debe ejecutar la parte del servidor: renderizado en el servidor, funciones del servidor y rutas API. Un host que recibe solo archivos estáticos no ejecuta esas características. El almacenamiento de objetos o una CDN por sí solos no son suficientes. Lovable señala una plataforma que Nitro detecta, un contenedor o tu propio servidor. También verifica que
package.jsonlistenitro, porque sin él la compilación no empaqueta la app para un host fuera de Lovable. - React y Vite antiguos: despliega la salida estática en
dist/en un host estático, CDN o servidor web como Nginx, con una alternativa aindex.htmlpara que funcionen las rutas del lado del cliente.
Otra trampa: las variables prefijadas con VITE_ se incrustan en el momento de la compilación, no se leen en tiempo de ejecución. Esto atrapa a los equipos. Al usar el backend integrado, Lovable te indica que configures VITE_SUPABASE_URL y VITE_SUPABASE_PUBLISHABLE_KEY antes de ejecutar npm run build.
He omitido deliberadamente recetas de implementación por proveedor aquí. Ese es un control de alcance deliberado. La guía de Lovable detalla los pasos actuales, y para un proyecto renderizado en el servidor prescribe verificaciones como cargar una página renderizada en el servidor y ejecutar una función del servidor antes de cambiar el tráfico.
App existente: cuatro caminos, comparados
| Camino | Qué se mantiene | Qué se traslada | Aún facturado u operado por Lovable | Trabajo a verificar | Propietario operativo |
|---|---|---|---|---|---|
| Mantener la configuración completamente administrada | Todo | Nada | Alojamiento, backend integrado, características de IA y conectores; el uso de Cloud se basa en créditos del espacio de trabajo | Que cumpla con tus necesidades de cumplimiento y lanzamiento | Lovable ejecuta la infraestructura; tú posees el producto |
| Trasladar solo el alojamiento del frontend | Backend integrado, características de IA, conectores; Lovable puede seguir siendo la herramienta de edición | Compilación e implementación del frontend | El backend, IA y conectores siguen funcionando a través de Lovable | Variables de entorno del host, secretos del servidor, URLs de redirección de inicio de sesión, valores VITE_ en tiempo de compilación, características del servidor en TanStack Start | Tú para la canalización frontend y logs; Lovable para el backend |
| Mover el backend integrado a un proyecto Supabase propio | Código sincronizado en Git; el frontend puede quedarse o moverse | Base de datos, autenticación, almacenamiento y funciones a Supabase administrado o autohospedado | Las características de IA y conectores aún pueden ejecutarse a través de Lovable | Restauración de datos, autenticación, almacenamiento, políticas de acceso, funciones perimetrales, secretos | Tú, en el panel de Supabase y bajo tu facturación de Supabase |
| Abandonar Lovable completamente | Código fuente | Frontend, backend, datos, más reemplazos para llamadas de IA y conectores | Nada, una vez que los reemplazos estén en su lugar y aceptados | La lista de verificación completa a continuación | Tú, para todo |
Dos cosas en esa tabla es fácil equivocarse.
Primero, migrar un backend no es un interruptor de palanca. Lovable indica que no puede transferir un proyecto del backend integrado a Supabase en un solo paso, ni revertir el proceso. La ruta documentada es más manual. Requiere recrear el esquema y mover datos a mano: exportar desde el backend activo, conectar el nuevo y indicar a Lovable que reconstruya el esquema.
Segundo, los destinos soportados son Supabase administrado y Supabase autohospedado. Mover solo la base de datos PostgreSQL deja demasiado atrás: autenticación, almacenamiento, características en tiempo real y funciones perimetrales. Cambiar a PostgreSQL simple u otro proveedor requiere construir esos equivalentes tú mismo, una ruta que Lovable no soporta. Ese es trabajo de ingeniería genuino, no una migración directa. Si tomas ese camino, la descripción general de bases de datos sin servidor es un lugar sensato para comparar destinos.
Abandonar el backend integrado también elimina las herramientas nativas. Pierdes las vistas de Base de datos, Usuarios, Almacenamiento, Secretos, Trabajos y Logs en el editor, copias de seguridad diarias con restauración con un clic, y autenticación configurada por Lovable como inicio de sesión con Google administrado. Ejecutar tu propio proyecto Supabase requiere tu propia suscripción a Supabase y gestión directa de la infraestructura.
Y nada en las fuentes dice que otro constructor importe un backend de Lovable completo. Asume que no lo hará.
Lista de verificación de aceptación de producción
Comienza con un inventario. Para el proyecto real, enumera:
- Datos y esquema (los archivos de migración se encuentran bajo
supabase/migrations/) - Usuarios y proveedores de autenticación
- Archivos de almacenamiento y políticas de acceso
- Suscripciones en tiempo real
- Funciones Edge o funciones de servidor
- Secretos
- Trabajos programados y webhooks
- Acceso a IA y conectores de aplicaciones
Luego trabajа en esto en orden:
- Clona el repositorio y ejecuta el código actual localmente. Eso muestra qué instala, de qué depende y qué lee del entorno.
- Identifica el framework y el runtime (consulta la verificación de
package.jsonarriba). - Restaura la exportación de datos en un proyecto staging, no en producción.
- Descarga archivos de almacenamiento desde Más → Almacenamiento y cárgalos en el almacenamiento staging.
- Prueba el registro, inicio de sesión y redirecciones de OAuth, y verifica la continuidad de la cuenta. La documentación de exportación de base de datos de Lovable dice que restaurar en un proyecto Supabase mantiene las contraseñas de los usuarios, y que cualquiera que haya iniciado sesión en el cambio debe volver a iniciar sesión. No lo asumas; valídalo y sigue la orientación actual de migración de usuarios de Supabase. Consulta también la página de autenticación.
- Prueba el acceso a archivos y permisos con cuentas reales de diferentes roles.
- Verifica Row Level Security. Cada tabla necesita políticas que restrinjan quién puede leer y escribir cada fila, y Lovable dice que las verifiques tú mismo en el panel de Supabase.
- Ejecuta un flujo crítico pagado o que cambie estado en modo de prueba, nunca cobrando a clientes reales.
- Compara recuentos de registros y abre archivos representativos del almacenamiento.
- Verifica registros, copias de seguridad, recuperación y una ruta de reversión.
- Reemplaza cualquier cosa que funcionara a través de Lovable: acceso a IA, conectores, trabajos programados.
- Solo entonces elimina los servicios originales.
El paso 12 amerita una advertencia. Tómalo en serio. Eliminar la base de datos de Lovable borra tu exportación junto con tus archivos, así que descárgalos e inspecciónalos antes. Nunca pegues credenciales en tickets, chats o el repositorio mientras manejas esto.
Otra trampa: si dos proyectos de Lovable comparten un único proyecto Supabase, se sobrescriben los secretos entre sí, incluyendo LOVABLE_API_KEY, lo que rompe cualquier función que dependa de ello.
Quédate, ve híbrido, o vete
La mayoría de decisiones reales quedan en el medio.
- Un requisito para un pipeline de deploy diferente puede solo necesitar un movimiento del frontend.
- Una necesidad de una base de datos en tu cuenta puede necesitar la migración del backend, y nada más.
- Insatisfacción con la experiencia de autoría puede solo significar trabajar en el repositorio exportado con tu propio editor, mientras Lovable se mantiene conectado a través de Git sync.
Asigna un propietario de mantenimiento y mapea cada dependencia de runtime restante antes de cancelar cualquier servicio. Mantén el documento conciso. Necesita decir quién realiza el deploy, quién restaura una copia de seguridad, quién rota los secretos y qué características aún llaman a Lovable. Si no puedes nombrar a un propietario, quédate donde estás por ahora.
Si necesitas una segunda opinión sobre esa transferencia, envía el repositorio, un mapa de despliegue y el flujo de usuario que requiere supervisión de ingeniería a el equipo de ingeniería agencial para una evaluación de límites de responsabilidad y trabajo pendiente. Sé preciso sobre lo que solicitas. Se trata de una evaluación, no un rescate garantizado con un botón.
FAQ
¿Puedo auto-alojar el editor y agente de Lovable?
No. Lovable establece que el editor y el agente de IA operan como un servicio administrado y no pueden auto-alojarse ni desplegarse dentro de una VPC del cliente. Las aplicaciones que construyas con ellos, sin embargo, pueden alojarse en cualquier lugar.
¿Cambiar a otro constructor me lleva mi backend consigo?
Nada en las fuentes indica que lo haga. Planifica trabajo separado. Exporta tus datos y archivos, transfiere la base de código mediante Git o una descarga, y configura autenticación, secretos y servicios de apoyo de nuevo en el destino.
¿Es suficiente la descarga .zip si estoy en un plan gratuito?
La descarga .zip directa de la base de código de Lovable está disponible en planes pagos. La sincronización con Git es diferente. Dado que la sincronización con Git está disponible en todos los niveles, prueba esa ruta primero.
La salvedad principal es clara: el código exportado te pertenece, pero los registros de base de datos, archivos de almacenamiento, configuración de autenticación, así como el agente de IA y conectores administrados por Lovable requieren migraciones separadas, ninguna de las cuales ocurre automáticamente. Haz el inventario antes de cambiar. Revisa tu package.json, inventaría cada dependencia, y prueba la migración en staging antes de cancelar cualquier cosa.