Cómo sacar tu app de Replit: migrar a tu propio hosting

Sacar una app de Replit son cuatro trabajos: listar todo lo que solo funciona dentro de Replit, llevar el código a un repositorio de GitHub, copiar la base de datos y los archivos guardados a servicios que controlas tú, y cambiar el dominio cuando la copia nueva ya esté probada. El código casi siempre se mueve sin problema. El trabajo está en las piezas propias de Replit, sobre todo el login, el almacenamiento de archivos y la base de datos, y en hacer el cambio sin perder lo que se escriba durante la mudanza.

En esta guía te damos el orden para hacerlo, las revisiones que detectan las sorpresas de siempre y un plan de cambio que mantiene la app vieja funcionando hasta que la nueva haya demostrado que está lista.

¿De verdad conviene mudarse?

Mudarse cuesta tiempo, y el hosting de Replit funciona bien para muchas apps. Hay buenas razones para irse: necesitar la infraestructura que ya usa tu equipo o que piden tus inversionistas, querer un entorno de pruebas con sus propios datos, chocar con los límites de los tipos de despliegue o querer todo (código, datos, dominio, facturación) en las cuentas de tu empresa. Si el problema real es que la app tarda en despertar o que no se publica, arregla eso primero: lo cubrimos en las guías sobre apps de Replit que se duermen y errores al desplegar.

Paso 1: ¿Qué partes de mi app solo funcionan en Replit?

Antes de tocar nada, haz un inventario. Busca esto en el código y anota cada cosa que encuentres:

• Replit Auth. Si tus usuarios inician sesión con el login integrado de Replit, sus cuentas viven en Replit. Suele ser la pieza más grande de la mudanza.
• Los servicios de almacenamiento de Replit. Busca paquetes que empiecen con @replit/ en package.json (o replit en los requisitos de Python), como el cliente de almacenamiento de objetos o la base clave-valor.
• La base de datos PostgreSQL. Se lee a través de DATABASE_URL.
• Los Secrets. Cada valor de la herramienta Secrets y, aparte, los Secrets de producción del panel Publishing.
• Variables de entorno que Replit define por ti. Busca REPLIT_ en el código; todo lo que las lea va a necesitar otro valor.
• La configuración de ejecución. El archivo .replit guarda los comandos de build y de ejecución y los puertos. En el hosting nuevo los configuras en sus propios ajustes.
• Despliegues Scheduled. Cualquier tarea con horario necesita un lugar nuevo, como el cron del hosting nuevo.

Ese inventario es también el inicio de tu documento de traspaso. En la guía para documentar tu app antes de entregarla te contamos qué más conviene registrar.

Paso 2: ¿Cómo saco el código?

Con Git, no con una descarga suelta. En tu app de Replit agrega la herramienta Git, conéctala a GitHub y sube el código a un repositorio privado nuevo en tu cuenta u organización. Desde ese momento, el repositorio es la fuente de verdad. Para repositorios privados, la documentación de Replit recomienda usar un token de acceso personal en lugar de la contraseña.

Después comprueba que el código corre fuera de Replit:

1. Clona el repositorio en una computadora o en un entorno limpio en la nube.
2. Instala las dependencias desde el lock file (npm ci en Node).
3. Crea un archivo .env con valores de prueba para cada variable de tu inventario.
4. Ejecuta los comandos de build y de inicio que están en .replit y abre la app.

Lo que falle aquí habría fallado igual en el hosting nuevo.

Paso 3: ¿Dónde debería correr la app?

Elige el hosting según lo que es la app, no según lo que está de moda:

Recrea tres cosas de .replit: el comando de build, el de inicio y el puerto. La mayoría de los hostings le indican a la app qué puerto usar con la variable de entorno PORT, y el servidor debe escuchar ahí, en 0.0.0.0.

Paso 4: ¿Cómo muevo la base de datos?

Las bases de Replit usan PostgreSQL 16, así que sirven las herramientas estándar de Postgres. Crea la base nueva en la misma versión o una más reciente, y luego exporta y restaura. En los ajustes de tu base de producción revisa los datos de conexión y si tu configuración permite conectarse desde fuera de la app.

pg_dump --format=custom --no-owner --dbname "$OLD_DATABASE_URL" -f prod.dump
pg_restore --no-owner --dbname "$NEW_DATABASE_URL" prod.dump

Haz primero un ensayo. Restaura en la base nueva, conecta una copia de prueba de la app y compara la cantidad de filas de tus tablas principales con la original. Usa la base de producción, no la de desarrollo: en Replit son distintas, y la de desarrollo tiene datos de prueba.

Guarda la exportación en un lugar privado: contiene los datos de todos tus usuarios.

Paso 5: ¿Qué pasa con los archivos subidos y los logins?

Archivos. Todo lo que esté en el almacenamiento de objetos de Replit hay que copiarlo al servicio nuevo, y actualizar las rutas guardadas en la base para que apunten ahí. Recuerda que los archivos que una app publicada en Replit escribe directo en disco no sobreviven a una nueva publicación; si hoy tus usuarios reportan archivos perdidos, puede que esos datos ya no estén.

Logins. Si la app usa Replit Auth, elige primero el nuevo proveedor de autenticación (por ejemplo, el que trae tu nueva plataforma de base de datos o un servicio de autenticación dedicado). Después decide cómo pasan los usuarios actuales. Lo habitual es emparejarlos por correo: crear las cuentas en el sistema nuevo, conservar los mismos IDs internos para que sus datos sigan vinculados y pedir a todos que definan una contraseña o usen un enlace mágico en su primer ingreso. Avísales antes del cambio.

Paso 6: ¿Cómo hago el cambio sin caídas?

1. Unos días antes: baja el TTL de los registros DNS de tu dominio para que el cambio se propague rápido. En la guía de registros DNS explicamos qué es el TTL.
2. Despliega la app nueva con la configuración de producción en una dirección temporal y prueba el flujo completo: registro, login, pago, subida de archivos.
3. Anuncia una ventana de mantenimiento corta y detén las escrituras en la app de Replit (una página de mantenimiento o modo solo lectura).
4. Haz la exportación final de la base, restáurala y vuelve a comparar la cantidad de filas.
5. Cambia el DNS para apuntar al hosting nuevo y actualiza las URL de webhooks (Stripe, proveedores de correo) y las URL de redirección del login.
6. No toques la app de Replit ni su base durante al menos una semana, por si necesitas comparar algo.
7. Recién entonces elimina el despliegue de Replit, después de sacar un último respaldo.

Respuestas rápidas

¿Puedo exportar mi código de Replit? Sí. Conecta la herramienta Git a GitHub y sube el código a un repositorio tuyo. Es la forma más limpia y conserva el historial.

¿Puedo llevarme mi base de datos de Replit? Es PostgreSQL, así que puedes exportarla con pg_dump y restaurarla en otra base Postgres, siempre que puedas conectarte a ella.

¿Qué es lo más difícil de dejar Replit? Normalmente Replit Auth y los archivos guardados, porque las cuentas y las subidas viven en servicios de Replit y no en tu código.

¿Mis usuarios van a notar la mudanza? No, si pruebas en una dirección temporal, mantienes corta la ventana de mantenimiento y manejas los logins con cuidado.

¿Quieres ayuda para planear la mudanza?

Una migración es buen momento para arreglar lo frágil en vez de copiarlo a otro lugar. Nuestro servicio para arreglar apps de Replit puede revisar el código y planear la mudanza, y el equipo de desarrollo de software a medida puede encargarse de reconstruir las partes que lo necesiten. Antes de mudarte también puedes leer quién es dueño del código hecho con IA, o escribirnos con tu inventario del paso 1.