Cómo llevar una app de Base44 a vuestro servidor propio (on-premise)

¿Se puede instalar Base44 en vuestros servidores?

No. Base44 es un servicio en la nube: el editor, la base de datos, el inicio de sesión y las funciones de servidor corren en su infraestructura, en Estados Unidos salvo que se contrate otra región. No existe instalador, imagen de Docker ni licencia on-premise, y la documentación oficial no menciona ninguna.

Es una petición frecuente en empresas que evalúan la plataforma: en su comunidad hay equipos preguntando cómo garantizar que los datos se queden dentro de la red corporativa, y en el tablero de sugerencias de Base44 las peticiones de alojarlo uno mismo (“self host” y “Full Self-Hosting”) sumaban 11 y 5 votos a 2 de octubre de 2026, sin respuesta oficial.

Así que la pregunta útil es otra: qué hace falta para que vuestra app funcione sin Base44 dentro de vuestra red.

Por qué descargar la app no basta

Es el error más habitual al empezar, y fue el primero que se cometió en la migración real en la que se basa esta guía: exportar el código, copiarlo al servidor y dar el trabajo por hecho. Las pantallas cargan, pero cada vez que alguien guarda o consulta un registro, la petición sigue yendo a los servidores de Base44. Lo que se ha movido es la fachada, no la app.

El motivo es que el código exportado usa la librería de Base44 para todo lo que no es pantalla, y esa librería llama a su API.

¿Y las herramientas para desarrolladores de Base44?

Base44 tiene una herramienta de línea de comandos con dos órdenes que parecen resolver esto y no lo hacen:

• base44 eject descarga el proyecto, pero crea otra app dentro de Base44, con la base de datos vacía. Sigue dependiendo de su nube.
• base44 dev ejecuta el backend en tu ordenador, pero guarda los datos en memoria y los borra al pararlo, y reenvía a Base44 el inicio de sesión con Google o Microsoft, el correo y la IA. Sirve para desarrollar, no para producción.

Qué hay que reconstruir, pieza por pieza

Para que la app funcione en vuestro servidor, cada pieza que hoy pone Base44 necesita un sustituto. Estos son los habituales en las dos infraestructuras más comunes en empresa:

En la migración real, las tablas se recrearon en SQL Server dentro de una máquina virtual de la empresa, la app se sirvió con IIS y el acceso se resolvió con un login propio con usuario, contraseña y roles. El inicio de sesión con las cuentas de la empresa (SSO) quedó sin resolver: es la pieza que más depende de cómo esté montada vuestra red, y conviene hablarla con IT antes de empezar.

Las tres formas de tenerla en vuestra infraestructura

En la migración real se eligió la primera sin saberlo: tras migrar, Base44 quedó de lado y cada cambio pasó a hacerse directamente en el código del servidor. Funciona, pero quien creó la app deja de poder mejorarla con la herramienta que conocía, y cada petición pequeña se convierte en trabajo de programación.

Criterio de Keep44: si la app ya está estable y casi no cambia, la salida única es la opción más simple. Si el equipo sigue pidiendo cambios cada semana, la salida única sale cara a los pocos meses y el modelo híbrido compensa.

Cómo funciona el modelo híbrido

Base44 puede sincronizar la app con un repositorio de GitHub en los dos sentidos (plan Builder o superior): cada cambio que se hace en el editor se sube solo al repositorio. Ese repositorio es la fuente de cambios del modelo híbrido.

1. Quien creó la app sigue trabajando en Base44, con datos de prueba.
2. Cada cambio llega al repositorio. Un proceso en vuestro servidor compara esa versión con la que está en producción y detecta qué ha cambiado: un campo nuevo, una tabla, una pantalla.
3. Antes de aplicar nada, hace copia de seguridad de la base de datos y del código. Si IT lo exige, el cambio espera su aprobación.
4. Aplica el cambio en la base de datos y en la app. Si algo falla, vuelve a la versión anterior.

Un detalle que IT debe conocer: según la documentación de Base44, al conectar GitHub ya no se puede volver desde su historial a versiones anteriores a la conexión. Conviene conectarlo con la app en un estado estable.

¿Y la residencia de datos en la UE de Base44?

En el plan Enterprise, Base44 permite guardar los datos en la UE o el Reino Unido y no los usa para entrenar IA (en el resto de planes, sí pueden usarse). Si eso es todo lo que pide la empresa, puede bastar. Tiene límites: solo vale para apps creadas después del 16 de abril de 2026, decide dónde se guardan los datos pero no dónde se procesan, y los archivos subidos siguen en Estados Unidos (documentación de Base44 a 4 de octubre de 2026).

No resuelve el caso si los datos no pueden salir de vuestra red, si la app tiene que hablar con sistemas internos sin abrir el firewall o si aprobar un proveedor nuevo va a tardar meses. En la migración real, esa aprobación llevó más de medio año.

¿Puede funcionar dentro de la red y sin internet?

Sí. Una vez migrada, la app de producción no necesita a Base44 para funcionar: puede servirse solo en la red interna, con una dirección que no se ve desde internet. La app de la migración real funciona así, dentro de la red de la empresa.

Las excepciones son las funciones que dependen de un servicio externo (por ejemplo, la IA integrada o un correo externo). En el modelo híbrido, el servidor solo necesita salir al repositorio cuando hay cambios; no hace falta abrir ningún puerto de entrada. Si la red no tiene salida a internet, los cambios pueden llevarse como un paquete revisado.

Fuentes

• Base44: Privacy and security (residencia de datos, entrenamiento de IA, certificaciones). Consultado el 4/10/2026.
• Base44: GitHub Integration (sincronización en los dos sentidos, plan Builder). Consultado el 4/10/2026.
• Base44: eject y Local development. Consultados el 4/10/2026.
• Tablero de sugerencias de Base44. Consultado el 4/10/2026.