Cómo exportar y alojar por tu cuenta 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), recrea 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 front end sencillo, o una plataforma que ejecute servidores o contenedores para cualquier cosa con back end. El código suele ser la parte fácil. El trabajo está en los datos, los secretos y los servicios que el creador ejecutaba discretamente por ti.

Por qué exportar

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

Buenas razones:

• Propiedad y seguro. Una copia del código en tu propio repositorio te protege si el creador 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 creador no ofrece.
• Escala o coste a un tamaño en el que ejecutar tu propia infraestructura realmente compensa.

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. Obtienes la protección sin el trabajo operativo. Si Git te resulta nuevo, lee qué es GitHub.

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

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

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

Paso 1: saca el código

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 todo lo que sea continuo: historial completo, fácil de clonar en cualquier sitio, y la mayoría de hostings despliegan directamente desde un repositorio de GitHub en cada envío.

En cualquiera de los dos casos, clónalo o descomprímelo en un ordenador (o en un entorno de desarrollo en la nube) y busca un README. Si no hay ninguno, pide a la IA del creador que escriba uno 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, todas las variables de entorno que lee el código (nombres y finalidad, sin valores) y cómo se ejecutan las migraciones de la base de datos.

Este único prompt 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. Apúntala a una base de datos: un Postgres local o una base de datos de desarrollo gratuita de un proveedor gestionado.
5. Ejecuta las migraciones, luego arranca la app y recorre los flujos principales.

Cualquier cosa que falle aquí fallará también en un hosting, y es mucho más fácil depurarla en tu propia máquina. Sorpresas habituales: una URL fija de la vista previa del creador, una variable de entorno que faltaba porque el creador la inyectaba automáticamente, 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 creador que lo ejecute si no tienes acceso directo, y que explique lo que ha generado.
• Mueve los archivos subidos. Si los usuarios subieron imágenes o documentos, están en 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 URLs guardadas si incluyen el host antiguo.
• Planifica el cambio. En una app en producción, el enfoque sencillo es una ventana de mantenimiento corta: detener las escrituras, hacer una última exportación, restaurarla en el nuevo hosting, cambiar el DNS y volver a abrir. Escribe cada paso antes.
• 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; consulta las funciones y precios actuales en sus sitios.

También necesitarás:

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

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á completamente bajo tu control, pero tú asumes los parches, el TLS, las copias de seguridad, la monitorización y la recuperación. Si nadie del equipo quiere esa tarea, elige una plataforma. Para los fundamentos de lo que implica el hosting, consulta qué es el alojamiento web.

Paso 5: despliega y cambia

1. Conecta el repositorio con el hosting, o sube una imagen de contenedor.
2. Configura las variables de entorno en el panel del hosting: todas las del 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 sobre 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, URLs de redirección OAuth para el inicio de sesión, enlaces de correo, orígenes permitidos.
7. Mueve el dominio actualizando los registros DNS hacia el nuevo hosting. Cómo conectar un dominio personalizado explica los registros.
8. Mantén el despliegue antiguo en marcha un tiempo hasta estar seguro, y luego 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 las operaciones

Una vez que alojas la app por tu cuenta, lo que gestionaba el creador pasa a ser tuyo. Como mínimo: copias de seguridad automáticas de la base de datos con una restauración probada, seguimiento de errores, alertas de disponibilidad, actualizaciones de dependencias y un registro de quién tiene acceso a cada cuenta. Cómo llevar un prototipo de IA a producción recorre esta lista con más detalle.

Lista de comprobación para la exportación

• Código en un repositorio que sea tuyo, con un README que cubra ejecución, compilación y 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 el tipo de app, más base de datos y almacenamiento gestionados
• Todas las variables de entorno configuradas con valores reales en el nuevo hosting
• Webhooks, redirecciones OAuth y enlaces de correo actualizados
• DNS cambiado, despliegue antiguo mantenido un tiempo y luego 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 traer cambios desde tu propio repositorio; los planes gratuitos pueden ver el código en modo de solo lectura, pero no exportarlo ni sincronizarlo. Los secretos y node_modules quedan fuera de las exportaciones, así que recrea tus secretos en el nuevo hosting. La documentación cubre 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 entrega; si decides mudarte, despublica la app de Mythex cuando el nuevo hosting esté activo.

Preguntas