Salir de Lovable puede ser mover el hosting, sacar la base de datos de Lovable Cloud o dejar de construir con la herramienta, y las dos primeras se hacen sin la tercera: en Sistema Forja, la infraestructura pasó de unos R$ 2.000 a unos US$ 20 al mes y el cliente siguió editando la app en Lovable. Quien todavía está validando la idea se queda donde está. Reconstruir solo se justifica en una parte, cuando la búsqueda es el producto o cuando el dinero pasa por la app.
Qué quiere decir "salir de Lovable"#
Salir de Lovable puede querer decir tres cosas: mover el hosting de la app, sacar la base de datos de la nube integrada en la herramienta, Lovable Cloud, o dejar de construir conversando con la IA. Las dos primeras se hacen sin la tercera. La propia documentación de Lovable describe este esquema, con el desarrollo en Lovable y la app en producción en otro lugar.
La documentación de Lovable enumera tres esquemas. En el primero, que es el que ellos recomiendan, todo queda en Lovable. En el segundo, Lovable sigue siendo donde se desarrolla y la app en producción funciona en una plataforma como Vercel, Netlify o AWS. En el tercero, toda la infraestructura es de la empresa. En los dos últimos, lo que conecta Lovable con la producción es GitHub: el código se sincroniza en los dos sentidos con un repositorio, y la plataforma de hosting publica desde ahí. Y, según la misma documentación, el código es de quien lo construyó.
Cuándo la app no necesita salir de Lovable#
La app no necesita salir de Lovable mientras todavía está validando la idea, mientras la factura mensual es baja y previsible y mientras ningún pago ni dato sensible depende de una regla que se ejecute en un servidor. En esa etapa, la velocidad que da la herramienta vale más que cualquier ahorro de infraestructura, porque todavía hace falta poder cambiar de idea rápido.
Un producto con algunas decenas de usuarios, que todavía está descubriendo si alguien va a pagar por él, gana poco con un hosting propio y termina con una cuenta más que cuidar. Cuando alguien nos busca en esa etapa pensando que tiene que migrar, nuestra recomendación suele ser quedarse.
Uno de los motivos para querer salir, aparecer en Google, también perdió fuerza en 2026. Según la documentación de Lovable, desde el 13 de mayo de 2026 todo proyecto nuevo nace con renderizado en el servidor, con un framework llamado TanStack Start, y la página llega lista para cualquier visitante o rastreador. Los proyectos anteriores pueden actualizarse a ese formato desde la propia herramienta.
Incluso cuando migrar tiene sentido, rara vez obliga a reescribir la app. En Sistema Forja, una app hecha en Lovable que auditamos cuando ya tenía 1.312 usuarios activos, el diagnóstico consideró la arquitectura adecuada para esa escala, y lo que cambió fue dónde vivían la base de datos y el hosting.
Las señales de que la app tiene que salir, y el camino para cada una#
Las señales de que una app tiene que salir de Lovable son una factura de la nube que crece sin explicación, un producto que se volvió un activo y tiene que estar a nombre de la empresa, un negocio que vive de la búsqueda orgánica y dinero que pasa por la app. Cada señal pide un camino distinto, y solo algunas piden reconstruir una parte de la app.
| Señal | Qué quiere decir | Camino |
|---|---|---|
| Todavía se está validando la idea, con pocos usuarios y nada cobrado por la app | el producto está en etapa de descubrimiento, y la velocidad vale más que la infraestructura | quedarse |
| El proyecto es anterior a mayo de 2026 y sus páginas no aparecen bien en Google | la app arma la página en el navegador del visitante | quedarse y actualizar el proyecto al formato con renderizado en el servidor |
| La factura mensual crece y nadie sabe explicar de dónde sale | la base de datos y el hosting se pagan con los mismos créditos que la construcción | mover solo el hosting y la base de datos |
| El producto necesita copias de seguridad, acceso directo a la base de datos y cuentas a nombre de la empresa | la app se volvió un activo de la empresa | mover solo el hosting y la base de datos |
| Otra persona va a tocar el código, o un cambio ya tumbó la app en producción | falta un camino entre el trabajo en curso y lo que ve el usuario | mover solo el hosting, con GitHub y una rama de trabajo |
| El negocio depende de que lo encuentren en la búsqueda, con una página por cada vacante, producto o empresa | el cliente llega por la búsqueda | reconstruir una parte: el sitio público |
| La app va a cobrar suscripciones, habilitar planes o mover créditos | la regla tiene que ejecutarse en un servidor y verificar cada notificación de la pasarela de pago | reconstruir una parte: la capa que recibe los pagos |
| La app tiene que conectarse con el ERP o con otro sistema de la empresa | la integración necesita un servidor que guarde las credenciales | reconstruir una parte: un servidor propio junto a la app |
Cuando la reconstrucción aparece en la tabla, siempre es de una parte. La interfaz y los flujos que el dueño construyó conversando con la IA casi siempre se quedan, y el motivo está explicado en qué se puede salvar de un código generado por IA.
Cuándo la factura de Lovable Cloud empieza a pesar#
La factura de Lovable Cloud empieza a pesar cuando la app tiene uso real, porque la base de datos, el hosting y las funciones del servidor se pagan con los mismos créditos que pagan la construcción por chat. En Sistema Forja, una app brasileña, la infraestructura costaba unos R$ 2.000 (reales) al mes en la nube de la herramienta y pasó a costar unos US$ 20 al mes en cuentas del propio cliente.
Según la documentación de Lovable, el uso de Cloud sale del mismo saldo de créditos que la construcción. Los planes reciben una asignación mensual de 20 créditos para Cloud, lo que se pasa de eso sale del saldo general, y los planes pagos tienen recarga automática. El dueño ve un solo número y le cuesta separar cuánto fue para construir y cuánto para mantener la app funcionando. Con un Supabase propio, el consumo de la base de datos lo cobra Supabase, en el plan de quien es dueño de la cuenta.
En Sistema Forja, una plataforma de hábitos, metas y finanzas personales construida por sus propios fundadores en Lovable, había un cobro diario que siguió debitando durante días sin que nadie lo notara, y compras de créditos por encima del consumo real. Con la base de datos en un Supabase propio y el sitio en un hosting dedicado, la factura bajó a unos US$ 20 al mes, con copias de seguridad automáticas y sin dejar el producto fuera de servicio.
Este cambio tiene un detalle que sorprende a quien no lo conoce. La documentación de Lovable dice que no existe una migración de un clic de Lovable Cloud a un Supabase propio: hay que exportar los datos, crear un proyecto nuevo conectado a Supabase y rehacer la estructura de la base de datos, y los usuarios y los archivos también se mueven a mano. En Forja, eso significó abrir un proyecto nuevo en Lovable, ya conectado a la base de datos del cliente, y ese fue el proyecto en el que el cliente siguió trabajando.
Cuándo la app tiene que aparecer en Google y en las respuestas de IA#
La app necesita renderizado en el servidor cuando el negocio depende de que lo encuentren en la búsqueda. Una página que solo se arma en el navegador les llega vacía a muchos rastreadores. Según un análisis de Vercel con MERJ publicado en diciembre de 2024, los rastreadores de IA de OpenAI, Anthropic, Meta, ByteDance y Perplexity no ejecutan JavaScript. Los de Google y Apple sí.
Una app de página única, el formato de los proyectos de Lovable hasta mayo de 2026, entrega una página casi vacía y un programa que arma el contenido en el navegador. Un rastreador que solo lee lo que llega del servidor ve todo el sitio como una sola página. Google ejecuta el JavaScript después de una cola de renderizado, y la documentación de Google recomienda renderizar en el servidor, porque no todos los rastreadores pueden ejecutar JavaScript.
Una bolsa de empleo que nos llegó hecha en Lovable se detuvo justo ahí. El dueño había construido un sitio de vacantes con área del candidato, panel de la empresa y administración, y los últimos pedidos que le hizo a la herramienta, en junio, eran todos para que el sitio apareciera en Google. La respuesta de la propia herramienta fue que ese proyecto no hacía renderizado en el servidor, con la recomendación de llevar el sitio a Next.js, fuera de Lovable.
Hoy la documentación de Lovable cuenta otra historia. Los proyectos antiguos reciben una versión prerenderizada de sus páginas, que se entrega solo a rastreadores verificados: Google, Bing, las vistas previas de enlaces y los buscadores con IA de ChatGPT, Perplexity, Claude y Gemini. La documentación describe esta ayuda para la app publicada por el propio Lovable y no dice qué pasa con ella cuando el hosting se va a otro lado. Lo más seguro es asumir que se queda atrás y actualizar el proyecto al formato nuevo antes de migrar.
En la bolsa de empleo, el renderizado era solo la primera pared. Un sitio de vacantes depende de que cada vacante y cada empresa sean una página propia, con título propio, que el rastreador pueda leer. En su app, buena parte de las páginas que anunciaba el mapa del sitio devolvía el contenido de la página de inicio, y las páginas de ciudad llevaban a una dirección que no existía. Mover el hosting no resuelve eso. En el alcance que estamos modelando, el sitio público se construye desde cero con renderizado en el servidor, y lo que él hizo en Lovable se convirtió en la referencia de pantallas y comportamiento de un sistema a medida.
Cuándo el dinero pasa por la app#
Cuando la app cobra suscripciones, habilita planes o mueve créditos, la regla que lo decide tiene que ejecutarse en un servidor y verificar cada notificación que llega de la pasarela de pago. Es la parte de la app donde el código generado por chat falla con más frecuencia, y la que más vale la pena reconstruir, aunque el resto del producto siga en Lovable.
En Sistema Forja, los endpoints de pago aceptaban solicitudes sin autenticación y sin verificación de firma, y quien descubriera la dirección podía simular una compra aprobada. La corrección fue rehacer esa capa, para que una notificación sin el secreto correcto se rechace antes de cualquier procesamiento. La app siguió en Lovable, y el resto del producto no se reescribió.
En la bolsa de empleo, el cobro ni siquiera existía. La única decisión de negocio que el dueño ya había tomado, gratis para el candidato y pagado por la empresa, era justamente lo que la app no hacía: no había pasarela de pago conectada, ninguna empresa estaba asociada a un plan, y la pantalla de pagos del panel mostraba números de ejemplo. La IA dibuja la pantalla de cobro en un solo pedido, pero la notificación de la pasarela, el intento que falla y el plan que baja cuando la tarjeta es rechazada solo existen cuando alguien escribe la regla.
Antes de cobrarle al primer cliente por la app, vale la pena hacer un diagnóstico de la app hecha con IA que empiece por esa capa.
Cómo sacar el hosting de Lovable y seguir editando en él#
Se puede sacar el hosting y la base de datos de Lovable y seguir construyendo con la herramienta. El código pasa a vivir en un repositorio de GitHub en la cuenta de la empresa, el hosting publica desde ahí, y Lovable trabaja en una rama separada de la que está en producción. Así se le devolvió Sistema Forja al cliente, que siguió editando la app en Lovable.
En Forja, el producto se entregó funcionando en las cuentas del propio cliente: el repositorio en su GitHub, el hosting en Vercel conectado a ese repositorio, la base de datos en su Supabase y el dominio apuntando al nuevo esquema. Cada cambio hecho por chat en Lovable se vuelve un commit en una rama de trabajo, que no va a producción. Para publicar, alguien fusiona esa rama con la principal, y el hosting actualiza la app solo. La documentación de Lovable confirma las piezas: la sincronización con GitHub funciona en los dos sentidos y sigue una rama a la vez, que se elige en la configuración del proyecto.
Hay dos cuidados. El primero es la base de datos. En el esquema que entregamos hay una sola base de datos, sin entorno de pruebas, y un cambio de estructura hecho por chat se aplica en el momento, incluso antes de que la rama llegue a producción. Eso se le entregó por escrito al cliente, como un riesgo que quedó en sus manos. El segundo es el formato del proyecto: según la documentación, los proyectos creados a partir del 13 de mayo de 2026 ejecutan código en el servidor y necesitan un hosting que ejecute ese código, y no solo un lugar que sirva archivos.
De qué pasa a encargarse el dueño cuando el hosting sale de Lovable#
Cuando el hosting sale de Lovable, el dueño gana la cuenta a nombre de la empresa, el acceso directo a la base de datos y una factura que se puede leer. A cambio, pasa a responder por lo que Lovable cuidaba solo: monitoreo, certificado del dominio, operación de la base de datos, inicio de sesión y qué hacer cuando la app se cae un sábado a la noche.
La documentación de Lovable es directa sobre esto: la herramienta no puede monitorear ni depurar una infraestructura que no controla, y la lista incluye el despliegue, los certificados, los registros de errores, la operación de la base de datos, la autenticación y el análisis de seguridad. Si nadie en la empresa sabe encargarse de eso, hay que contratar a alguien que lo haga, aunque sea por pocas horas al mes.
Mover el hosting conviene cuando la infraestructura propia va a costar menos que la factura de hoy y hay alguien que la cuide. Mientras no haya quién la cuide, lo mejor es quedarse en Lovable y entender la factura de créditos antes de cambiar nada.
Preguntas frecuentes#
¿Se puede seguir editando en Lovable después de mover el hosting?#
Sí. Con el proyecto sincronizado con un repositorio de GitHub, la plataforma de hosting publica desde ahí y Lovable sigue siendo el lugar donde se construye, un esquema que la propia documentación de Lovable describe. En Sistema Forja, el cliente siguió editando en Lovable sobre una rama de trabajo y publicando al fusionar esa rama con la principal.
¿Una app hecha en Lovable aparece en Google?#
Sí. Según la documentación de Lovable, los proyectos creados desde el 13 de mayo de 2026 tienen renderizado en el servidor, y los más antiguos reciben una versión prerenderizada que se entrega a rastreadores verificados, como Google, Bing y los buscadores con IA. Para posicionar, el sitio igual necesita una página propia, con título propio, para cada cosa que la gente busca.
¿Qué es lo difícil de pasar de Lovable Cloud a un Supabase propio?#
Según la documentación de Lovable, no existe una migración de un clic. La estructura de la base de datos pasa por las migraciones, pero los datos, los usuarios, los archivos y los proveedores de inicio de sesión se mueven a mano, y hay que crear un proyecto nuevo en Lovable conectado a Supabase. En Sistema Forja, el cambio se hizo sin dejar el producto fuera de servicio y sin perder ningún registro.
¿El código hecho en Lovable es mío?#
Según la documentación de Lovable, las apps, el código y el contenido que creas ahí son tuyos, sujetos a derechos de terceros como las licencias de código abierto. El código se sincroniza con GitHub en todos los planes. En la práctica, lo que asegura la propiedad es que el repositorio, el hosting y la base de datos estén en cuentas a nombre de la empresa.
¿Tengo que reescribir la app en otra tecnología para que crezca?#
Casi nunca la app entera. Lo que suele rehacerse es una parte: la capa que recibe los pagos, la integración con otro sistema o el sitio público, cuando la búsqueda es el producto. En Sistema Forja, el diagnóstico consideró la arquitectura adecuada para la escala de ese momento, y el cliente siguió evolucionando la app en Lovable.
Fuentes#
- Lovable, opciones de despliegue, hosting y propiedad (los tres esquemas, la propiedad del código y los destinos de la base de datos): https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership
- Lovable, desplegar y alojar fuera de Lovable (lo que se migra a mano, el hosting para proyectos con servidor y lo que pasa a ser responsabilidad de quien aloja): https://docs.lovable.dev/tips-tricks/external-deployment-hosting
- Lovable, Lovable Cloud (sin migración de un clic a Supabase): https://docs.lovable.dev/features/cloud
- Lovable, conectar con Supabase (quién cobra el consumo de la base de datos): https://docs.lovable.dev/integrations/supabase
- Lovable, créditos y uso (la asignación mensual de Cloud y la recarga automática): https://docs.lovable.dev/introduction/credits-and-usage
- Lovable, sincronizar el proyecto con GitHub (sincronización en los dos sentidos, una rama a la vez): https://docs.lovable.dev/integrations/github
- Lovable, SEO y búsqueda con IA (renderizado en el servidor desde el 13 de mayo de 2026 y prerenderizado para rastreadores verificados): https://docs.lovable.dev/features/seo-aeo
- Lovable, actualizar un proyecto a TanStack Start: https://docs.lovable.dev/features/upgrade-to-tanstack-start
- Vercel y MERJ, "The rise of the AI crawler", 17 de diciembre de 2024: https://vercel.com/blog/the-rise-of-the-ai-crawler
- Google Search Central, conceptos básicos de SEO para JavaScript: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
Próximo paso#
Si tu app se hizo en Lovable y dudas entre quedarte, mover el hosting y la base de datos o reconstruir una parte, es la pregunta que respondemos en el diagnóstico de vibe coding. Revisamos el código, la base de datos y la factura, y te decimos qué se queda, qué cambia de lugar y qué hay que rehacer, como hicimos en Sistema Forja.