Cómo exportar el código de Base44 y alojar la app en otro lugar

Base44 permite exportar el código desde el plan Builder, en un archivo ZIP o con la sincronización con GitHub. Lo que sale es un proyecto React con Vite, con el front-end, las funciones de backend y la estructura de las tablas. La base de datos, el inicio de sesión y las integraciones siguen en Base44, así que alojar todo fuera exige reemplazar ese backend.

Recomendación de Heartscale: antes de exportar, liste las llamadas al SDK de Base44 en el código y decida si basta con sacar el front-end o si todo el backend tiene que salir. Si la app tiene inicio de sesión y datos personales, planifique el restablecimiento de contraseñas y pida una revisión de los permisos antes del cambio.

Qué plan habilita la exportación

Según la página de herramientas para desarrolladores de Base44:

• Free: usted ve el código de la app, pero no lo edita.
• Planes pagos: habilitan la edición del código.
• Builder o superior: habilitan la exportación en ZIP y la conexión con GitHub.

En la página de precios, en octubre de 2026, Builder cuesta US$ 40 al mes con pago anual. Es el plan más barato que incluye la integración con GitHub.

Qué viene con el código y qué se queda en Base44

La documentación describe el ZIP como un proyecto React estándar hecho con Vite. La tabla resume qué sale y qué no:

Elemento	¿Viene en el ZIP o en GitHub?	Dónde queda después
Front-end (React + Vite)	Sí	Donde usted lo aloje
Funciones de backend	El código, sí	Siguen corriendo en Base44
Estructura de las tablas (campos y permisos)	Sí	Los datos siguen en Base44
Datos de las tablas	No	Exporte en CSV desde Data
Usuarios de la app	No	Exporte en CSV desde App Users
Secretos	No	Quedan en Base44
Historial de versiones	No (el ZIP trae solo la versión guardada)	Queda en Base44

El punto central está en la misma página: el código exportado usa el SDK de Base44. Por eso, datos, inicio de sesión, funciones e integraciones siguen en Base44 y usan los datos de la app publicada. La documentación indica que alojar el backend por cuenta propia no está soportado. Correr todo fuera exige reemplazar base de datos, inicio de sesión e integraciones, y reescribir el código que llama a cada uno.

Conviene saber qué hace ese backend, según la visión general del backend de Base44:

• Entidades: base NoSQL compatible con MongoDB, sin esquema obligatorio.
• Inicio de sesión: correo y contraseña, Google, Microsoft, Facebook, Apple y SSO.
• Funciones: TypeScript sobre Deno, sin servidor que usted deba mantener.
• Integraciones incorporadas: SendEmail, UploadFile, invokeLLM, GenerateImage y otras. Corren en la infraestructura de Base44 y consumen créditos de integración (Built-in integrations).
• Hosting: solo aplicaciones de una página, con dominio propio y HTTPS. No hay renderizado en el servidor.

Paso 1: exporte el código en ZIP

Según la documentación:

1. Abra la app en el editor de Base44, en una computadora. La exportación no existe en el editor del celular.
2. Haga clic en el ícono More actions, arriba a la derecha.
3. Elija Export project as ZIP.
4. Haga clic en Download ZIP.

Necesita permiso de edición en la app. El ZIP es una foto del código en ese momento.

Paso 2: o conecte GitHub

GitHub conviene si la app va a seguir cambiando. La integración con GitHub funciona así:

1. En el editor, haga clic en Dashboard.
2. Haga clic en el ícono de GitHub, arriba a la derecha, y luego en Connect to GitHub.
3. Haga clic en Connect GitHub y autorice Base44 Builder.
4. Elija la cuenta u organización y los repositorios habilitados. Haga clic en Install.
5. Dé nombre al repositorio y haga clic en Create Repository.

Reglas que confunden a muchos:

• Solo el dueño de la app conecta, reconecta o vincula un repositorio.
• La sincronización es automática en ambos sentidos. No hay push manual.
• La rama por defecto debe llamarse main. Otro nombre, como master, no se acepta.
• Los cambios en main llegan a Base44, pero solo se publican después de hacer clic en Publish.
• No se puede pausar la sincronización: está conectada o no lo está.
• Después de desconectar, la reconexión exige otro nombre de repositorio.
• Version History no vuelve a versiones anteriores a la integración. Solo restaura lo que está en el repositorio.

No lo confunda con el conector GitHub API, que sirve para que la app lea issues y pull requests. No sincroniza código (Connecting GitHub to your app).

Paso 3: exporte los datos y los usuarios

El código no lleva ningún registro. Según la página de datos de la app:

1. En el editor, haga clic en Dashboard y luego en Data.
2. Elija la tabla.
3. Haga clic en More actions y en Export. Con un filtro activo, la opción pasa a Export filtered records y descarga solo lo que aparece.
4. Repita con cada tabla.

La pantalla muestra hasta 5.000 elementos por tabla. El CSV los trae todos.

Para la lista de usuarios, la página sobre datos de usuarios indica Dashboard → App Users → More actions → Export to CSV. Los dos archivos traen todas las filas, con datos personales de todos los usuarios. Guárdelos en un lugar seguro.

La documentación no dice qué columnas trae el CSV de usuarios ni menciona contraseñas. Si va a reemplazar el inicio de sesión, planifique un restablecimiento de contraseña para todos.

Paso 4: elija dónde alojar

Hay dos caminos, con volúmenes de trabajo muy distintos.

Camino A: solo el front-end fuera, backend en Base44

Es el camino que la documentación soporta. Usted aloja el front-end donde quiera y este sigue llamando al backend de Base44. En la práctica:

1. Tome el código de GitHub o del ZIP.
2. Revise el script build en el package.json y genere los archivos estáticos.
3. Publíquelos en un hosting de sitios estáticos o en un VPS. Configure el servidor para enviar toda ruta a index.html, como en cualquier aplicación de una página.
4. Apunte su dominio.

Qué cambia: la dirección y el servidor del front-end. Qué no cambia: base de datos, inicio de sesión, funciones, créditos de integración y la suscripción de Base44. También existe la opción inversa: compilar fuera y publicar los archivos en el hosting de Base44, con dominio propio y HTTPS automático.

Este camino sirve si usted quiere controlar el front-end, tener dominio propio o un pipeline de deploy propio. No sirve si quiere dejar de pagar Base44 o sacar los datos de allí.

Camino B: salir de Base44 por completo

Aquí usted reemplaza cada pieza del backend por una propia. La lista mínima:

1. Base de datos. Las entidades son NoSQL y no tienen esquema obligatorio. En una base relacional, como el PostgreSQL de Supabase, usted define tablas, tipos y claves, e importa los CSV.
2. Permisos. Las reglas de acceso por fila y por campo de Base44 no vienen. Recree cada una. En Supabase, eso es RLS: vea cómo configurar RLS en Supabase.
3. Inicio de sesión. Configure de nuevo los proveedores (Google, Microsoft, Apple) con credenciales propias e importe los usuarios. Sin las contraseñas, pida a todos que las restablezcan.
4. Funciones. Reescriba las funciones de backend para el nuevo entorno. Reemplace las llamadas al SDK de Base44.
5. Integraciones. Cada SendEmail, UploadFile o invokeLLM necesita un servicio propio, con su propia clave de API.
6. Conectores. Las conexiones OAuth gestionadas por Base44 necesitan una app OAuth propia en cada servicio.

Busque en el código todas las llamadas al SDK de Base44. Esa lista es el tamaño real de la migración. En nuestras revisiones, armamos esa lista archivo por archivo y anotamos, junto a cada llamada, la pieza del backend nuevo que la va a reemplazar.

Paso 5: pruebe y cambie sin perder datos

1. Suba la app nueva en una dirección de prueba, con una copia de los datos.
2. Pruebe inicio de sesión, registro, lectura, escritura, carga de archivos y cada integración.
3. En el cambio, pause el uso de la app, exporte los CSV de nuevo e importe la versión final.
4. Apunte el dominio al servidor nuevo.
5. Desactive la app en Base44 solo después de revisar los datos en el destino.

Antes de compartir cualquier CSV con alguien del equipo, la propia documentación recomienda eliminar los datos de otras personas.

Si su app está en Lovable y no en Base44, el camino es otro: vea cómo salir de Lovable.

¿Hacerlo usted mismo o contratar?

Esta guía basta para el camino A; la tabla muestra cuándo conviene tener un equipo al lado.

Situación	Camino
Solo el front-end fuera, backend en Base44, y alguien en el equipo que hace el build	Hágalo usted mismo con esta guía (camino A)
Salida completa de Base44, con datos de usuarios reales	Llame a un equipo para modelar la base relacional y recrear los permisos
Inicio de sesión con Google, Microsoft o Apple, o datos personales en la app	Solicite el diagnóstico de Heartscale: lista cada llamada al SDK y lo que cambia en el inicio de sesión
Plazo corto o nadie técnico en el equipo	Contrate la migración con precio cerrado

Solicite un diagnóstico de Heartscale

Nuestro equipo identifica cada llamada al SDK de Base44 en su código, mide el volumen de datos y define si conviene el camino A o el B. Usted recibe el plan de migración de plataforma con lo que cambia en la base de datos, el inicio de sesión y las integraciones, 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