Cómo exportar y alojar tú mismo una app creada con IA

Para alojar por tu cuenta una app creada con IA, saca el código (una descarga o una sincronización con un repositorio de GitHub que sea tuyo), vuelve a crear sus secretos como variables de entorno, mueve o recrea su base de datos y despliégala en un hosting que encaje con lo que es la app: un hosting estático para un frontend sencillo, o una plataforma que ejecute servidores o contenedores para todo lo que tenga backend. El código suele ser la parte fácil. Los datos, los secretos y los servicios que el constructor ejecutaba discretamente por ti son donde está el trabajo.

Por qué exportar

Hay buenas razones para llevarte tu código, y algunas menos buenas.

Buenas razones:

• Propiedad y seguro. Una copia del código en tu propio repositorio te protege si el constructor cambia sus precios, funciones o condiciones.
• Entrega a desarrolladores. Un equipo de ingeniería querrá el código en Git, con sus herramientas habituales y su proceso de revisión.
• Requisitos específicos. Residencia de datos, un proveedor de nube concreto, políticas de seguridad de la empresa o infraestructura que el constructor no ofrece.
• Escala o coste, a un tamaño en el que ejecutar tu propia infraestructura sí compense de verdad.

Razones menos buenas: mover una app pequeña con unos pocos usuarios para ahorrar una pequeña cantidad al mes. Alojar por tu cuenta traslada trabajo a tus manos: actualizaciones, copias de seguridad, monitorización, parches de seguridad. Puede ser la decisión correcta; solo tómala con conocimiento de causa.

Un término medio sensato: sigue construyendo y alojando donde estás, pero sincroniza con tu propio repositorio de GitHub desde el principio. Así tienes la garantía sin el trabajo operativo. Si Git te resulta nuevo, lee qué es GitHub.

Qué incluye y qué no incluye una exportación

Antes de depender de una exportación, ábrela y compruébala. Normalmente:

Los secretos se dejan fuera a propósito: un archivo que podrías enviar por correo o subir a un repositorio nunca debe contener claves reales. Las dependencias se dejan fuera porque se reconstruyen a partir del archivo de bloqueo.

Paso 1: saca el código

Hay dos rutas habituales:

• Descargar un archivo del proyecto. Es rápido y sirve para una mudanza puntual o una copia de seguridad.
• Sincronizar con GitHub. Mejor para cualquier cosa continua: historial completo, fácil de clonar en cualquier sitio y la mayoría de los hostings despliegan directamente desde un repositorio de GitHub en cada envío.

En cualquiera de los dos casos, clona o descomprime el proyecto en un ordenador (o en un entorno de desarrollo en la nube) y busca un README. Si no existe, pide a la IA del constructor que lo escriba antes de irte:

Escribe un README para ejecutar este proyecto fuera de esta plataforma: la pila tecnológica, las versiones de runtime necesarias, los comandos de instalación y compilación, el comando de inicio y el puerto, cada variable de entorno que lee el código (nombres y para qué sirven, sin valores) y cómo se ejecutan las migraciones de la base de datos.

Este único prompt te ahorra horas, porque obliga a poner por escrito las partes implícitas de la configuración.

Paso 2: ejecútalo primero en local

Antes de desplegar en cualquier sitio, demuestra que la app funciona por sí sola:

1. Instala el runtime que indica el README: Node.js, Python, Java, .NET, en una versión compatible.
2. Instala las dependencias (npm install, pnpm install, pip install -r requirements.txt o el equivalente).
3. Crea un archivo .env local con las variables de entorno, usando claves de prueba siempre que sea posible. Mantenlo fuera de Git. Qué son las variables de entorno y los secretos explica la idea.
4. Conéctalo a una base de datos: un Postgres local o una base de datos de desarrollo gratuita de un proveedor gestionado.
5. Ejecuta las migraciones, arranca la app y recorre los flujos principales.

Lo que falle aquí fallará también en cualquier hosting, y es mucho más fácil depurarlo en tu propia máquina. Sorpresas habituales: una URL fija de la vista previa del constructor, una variable de entorno que el constructor inyectaba automáticamente y que falta, o un servicio (almacenamiento de archivos, redimensionado de imágenes) que solo existía en la plataforma.

Paso 3: mueve los datos

Si la app tiene usuarios reales, los datos importan más que el código.

• Exporta la base de datos. En Postgres, pg_dump genera un archivo que puedes restaurar con pg_restore o psql en la nueva base de datos. Pide a la IA del constructor que lo ejecute si no tienes acceso directo, y que te explique qué ha generado.
• Mueve los archivos subidos. Si los usuarios subieron imágenes o documentos, están en un almacenamiento de objetos separado de la base de datos. Cópialos a tu nuevo almacenamiento (por ejemplo, un bucket compatible con S3) y actualiza las URL guardadas si incluyen el host antiguo.
• Planifica el cambio. Para una app en producción, lo más sencillo es una ventana corta de mantenimiento: detener las escrituras, hacer una exportación final, restaurarla en el nuevo hosting, cambiar el DNS y reabrir. Escribe cada paso antes de empezar.
• Prueba una restauración en una base de datos de pruebas antes de la mudanza real.

Si Postgres te resulta desconocido, qué es Postgres explica lo básico.

Paso 4: elige dónde alojarla

Ajusta el hosting a lo que es la app. Los nombres siguientes son ejemplos de proveedores conocidos en cada categoría a septiembre de 2026, no un ranking; revisa las funciones y precios actuales en sus webs.

También necesitarás:

• Una base de datos gestionada. Muchos hostings de apps ofrecen Postgres, y servicios especializados como Neon o Supabase lo proporcionan por separado. Merece la pena lo gestionado: las copias de seguridad y las actualizaciones son trabajo de otro.
• Almacenamiento de objetos para subidas, si la app las tiene.
• Envío de correo, pagos y proveedores de IA: normalmente basta con configurar en el nuevo hosting las mismas claves de API.

Siendo justos con las ventajas y desventajas: los hostings de plataforma (las cuatro primeras filas) son más rápidos de configurar y mantener, pero tienes menos control y los costes pueden subir con el tráfico. Un servidor virtual suele ser más barato con carga constante y está totalmente bajo tu control, pero tú te encargas de parches, TLS, copias de seguridad, monitorización y recuperación. Si nadie del equipo quiere ese trabajo, elige una plataforma. Para los conceptos básicos de qué implica el hosting, consulta qué es el alojamiento web.

Paso 5: despliega y cambia

1. Conecta el repositorio al hosting, o sube una imagen de contenedor.
2. Configura las variables de entorno en el panel del hosting: todas las que aparecen en tu README, con valores reales.
3. Configura los comandos de compilación e inicio y el puerto. Muchos hostings pasan el puerto en una variable de entorno PORT; la app debe escuchar en ese puerto y en todas las interfaces (0.0.0.0), no solo en localhost.
4. Ejecuta las migraciones contra la nueva base de datos.
5. Prueba en la URL temporal del hosting antes de tocar el DNS.
6. Actualiza los servicios externos que apuntan a tu URL antigua: webhooks de pagos, URL de redirección de OAuth para el inicio de sesión, enlaces en correos, orígenes permitidos.
7. Mueve el dominio actualizando los registros DNS hacia el nuevo hosting. Cómo conectar un dominio propio explica los registros.
8. Mantén el despliegue antiguo un tiempo breve hasta estar seguro, y después apágalo.

El paso 6 es el que más se olvida: los inicios de sesión y los pagos que fallan en silencio tras una mudanza suelen deberse a una URL de callback que sigue apuntando al host antiguo.

Paso 6: asume la operación

Cuando alojas por tu cuenta, lo que hacía el constructor pasa a ser responsabilidad tuya. Como mínimo: copias de seguridad automáticas de la base de datos con una restauración probada, seguimiento de errores, alertas de disponibilidad, actualización de dependencias y una nota de quién tiene acceso a cada cuenta. Cómo llevar un prototipo de IA a producción repasa esta lista con más detalle.

Lista de comprobación de la exportación

• Código en un repositorio tuyo, con un README que explique cómo ejecutar, compilar y las variables de entorno
• La app se ejecuta en local desde un clon limpio
• Base de datos exportada y restauración probada; archivos subidos copiados
• Hosting elegido según la forma de la app, más base de datos y almacenamiento gestionados
• Todas las variables de entorno configuradas con valores reales en el nuevo hosting
• Webhooks, redirecciones de OAuth y enlaces de correo actualizados
• DNS cambiado, despliegue antiguo mantenido brevemente y después eliminado
• Copias de seguridad, monitorización y lista de accesos en marcha

Exportar desde Mythex

En Mythex eres dueño del código que construyes. En el plan Pro puedes descargar el proyecto como archivo desde Ajustes del proyecto → Exportar, o conectar GitHub y enviar y obtener cambios de tu propio repositorio; los planes gratuitos pueden ver el código en modo solo lectura, pero no exportarlo ni sincronizarlo. Los secretos y node_modules se dejan fuera de las exportaciones, así que vuelve a crear tus secretos en el nuevo hosting. La documentación explica los pasos en exportar y ejecutar en otro sitio y en GitHub, exportación e importación. También puedes seguir alojando en Mythex y usar la sincronización con GitHub simplemente como tu copia propia y vía de traspaso; si decides mudarte, despublica la app de Mythex cuando el nuevo hosting esté activo.

Preguntas