Cómo exportar mi app de Replit y alojarla fuera
Para sacar la app de Replit, descargue el código con Download as zip o con Git, exporte la base de producción con pg_dump, recree los Secrets y corra la app en un servidor suyo con los comandos del archivo .replit. Después, mueva el dominio. El código sale fácil; base, login y archivos piden cuidado.
Recomendación de Heartscale: haga el pg_dump de la base de producción con la app fuera de línea y restáurela primero en una base vacía, para revisar los datos antes del cambio. Si la app usa Replit Auth, App Storage o Connectors, resuelva cada uno antes de mover el dominio; con usuarios reales, pida una revisión del plan antes de empezar.
Antes de empezar: qué sale y qué queda
Replit describe la copia manual de una app en Manually copy a project to another workspace. Esa guía apunta a otra cuenta de Replit, pero muestra lo que no viaja con el código. Fuera de Replit, la lista es la misma y crece un poco:
| Parte | Dónde está en Replit | Cómo sale |
|---|---|---|
| Código | Archivos del proyecto | Download as zip o Git |
| Base de datos | PostgreSQL de desarrollo y de producción | pg_dump y pg_restore |
| Secrets | Secrets del editor y del deploy, separados | Se recrean a mano |
| Archivos subidos | App Storage (Google Cloud Storage) | Descarga de los objetos |
| Login | Replit Auth o Clerk | Cambio planificado |
| Integraciones | Tools → Connectors | Se reemplazan por integraciones suyas |
| Dominio | Publishing → Domains | Cambio de DNS o transferencia |
Si la app está en un workspace de equipo, consulte antes con el administrador. Con la opción Ban source code export activa, la descarga del zip queda bloqueada.
Paso 1: obtenga el código
Download as zip (Projects and files): abra el menú de tres puntos arriba del árbol de archivos y elija Download as zip. Si falla, abra el Shell y ejecute:
zip -r project.zip .
Los proyectos de más de 200 MB piden un archivo más pequeño. La documentación sugiere excluir carpetas que se regeneran:
zip -r project.zip . -x ".cache/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*"
No incluya la carpeta .cache en un zip manual. Según la documentación, guarda valores de Secrets en caché.
Git: vincule su cuenta de GitHub en los servicios conectados de su cuenta, abra la herramienta Git en el proyecto y conecte el repositorio. El auto-sync del panel Git sincroniza en los dos sentidos, y un token de acceso personal fine-grained da una conexión más estable. Recuerde que GitHub recibe solo los archivos con commit: los archivos ignorados y los cambios sin commit se quedan atrás.
Prefiera Git. Guarda el historial y permite hacer deploy con cada push en el servidor nuevo.
Paso 2: averigüe cómo corre la app
El archivo .replit controla el comportamiento de la app y está oculto por defecto (Replit App Configuration). Usa formato TOML. Busque tres cosas:
run: el comando del botón Run.- La sección
[deployment]:buildcorre antes del deploy yruninicia la app publicada. Son los comandos que usará el servidor nuevo. [[ports]]:localPortes el puerto donde escucha la app.
El replit.nix lista los paquetes del sistema que usa el proyecto, en el arreglo deps. Instale los equivalentes en el servidor nuevo.
El tipo de deploy también dice mucho (Publishing). Static aloja un sitio que no cambia según el usuario. Autoscale y Reserved VM corren un servidor. Scheduled corre la app en horarios fijos y pasa a ser una tarea programada en el servidor nuevo.
Paso 3: exporte la base de producción
Replit separa la base de desarrollo de la base de producción, que atiende la app publicada (Development and production databases). Los datos reales están en producción. El $DATABASE_URL del Shell apunta a desarrollo.
Para obtener la cadena de producción (Connection details): en el panel Tools, abra Database, seleccione Production Database y abra la pestaña Settings. La base de producción acepta conexiones desde cualquier cliente compatible con PostgreSQL. La de desarrollo no acepta conexiones externas.
Saque la app de línea antes de la copia final: lo que se grabe después de iniciar pg_dump no entra en el archivo. El comando de la documentación:
pg_dump -Fc "CADENA_DE_PRODUCCION" --no-owner --no-privileges -f backup.dump
En el destino, un PostgreSQL suyo, administrado o en un VPS, la documentación restaura así:
pg_restore --clean --if-exists --single-transaction --no-owner --no-privileges --exit-on-error -d "CADENA_DE_LA_BASE_NUEVA" backup.dump
--clean borra en el destino los objetos con el mismo nombre antes de cargar. Ejecútelo en una base nueva y vacía. Si no hay salida en pantalla, la restauración funcionó. En nuestras revisiones, comparamos la cantidad de filas de cada tabla entre la base de Replit y la nueva antes de liberar el cambio.
El backup.dump contiene los datos de sus usuarios. Nunca lo suba a un repositorio. Guárdelo en un lugar seguro y borre las copias sueltas después.
Paso 4: recree los Secrets
Los Secrets están en + en la barra de pestañas del editor → Secrets (Add secrets). Replit guarda los de desarrollo y los de deploy por separado (Deployment and publishing). Revise ambos, porque la app publicada puede usar otros valores.
Los valores no viajan con la copia. Liste el nombre de cada Secret, incluidos los Account Secrets vinculados al proyecto, y recréelos como variables de entorno en el servidor nuevo. La cadena de la base nueva reemplaza a la antigua, con el nombre que lee el código, en general DATABASE_URL.
Paso 5: lleve los archivos y reemplace las integraciones
App Storage funciona sobre Google Cloud Storage (App Storage). Para descargar, abra la pestaña App Storage, vaya a Objects y use el ícono de descarga junto a cada archivo. Las bibliotecas oficiales de Replit se autentican solas dentro de Replit. La documentación no dice si el bucket responde desde fuera. Planifique, entonces, un storage propio y ajuste el código que lee y graba archivos.
Las integraciones de Tools → Connectors hay que reconectarlas incluso en una copia dentro de Replit. Fuera de Replit, reemplace cada una por una integración suya, con claves suyas.
Paso 6: resuelva el login
Replit Auth usa el login y la infraestructura de Replit, y los usuarios entran con cuenta de Replit (Replit Auth). La documentación no dice si funciona con la app alojada fuera. Trátelo como una dependencia y resuélvalo antes del cambio.
Replit ofrece una migración de Replit Auth a Clerk, hecha por el Agent, que lleva los datos de identidad de los usuarios (Migrate from Replit Auth to Clerk). El tenant de Clerk creado así lo administra Replit. También puede conectar una app de Clerk propia, pero la documentación advierte que borrar la app administrada elimina su tenant (Clerk Auth). Pruebe el login con usuarios reales en una copia antes de borrar nada.
Paso 7: suba la app al servidor nuevo
Con los comandos del paso 2, el camino es el de cualquier app Node o Python: instale las dependencias, ejecute el build e inicie con el run detrás de un proxy inverso con HTTPS. Si prefiere un panel, Coolify se instala en un VPS Linux con al menos 2 núcleos y 2 GB de RAM y hace deploy desde GitHub.
Para un deploy Static, basta con servir los archivos generados en el build.
Paso 8: pruebe antes del cambio
- Abra rutas internas directo por la URL y recargue.
- Inicie y cierre sesión con un usuario real.
- Lea, grabe y suba un archivo.
- Compruebe que cada integración responde con las claves nuevas.
- Si había un deploy Scheduled, confirme que la tarea corre una sola vez, en el servidor nuevo.
Paso 9: mueva el dominio
Dominio de otro registrador. En Replit, usa un registro A y un TXT, configurados en Publishing → Domains (Custom domains and DNS). En el cambio, desconecte el dominio de la app en Replit y apunte el registro A en su proveedor al servidor nuevo.
Dominio comprado en Replit. La transferencia a otro registrador se hace por el soporte de Replit, después de los 60 días de espera de ICANN (Domain purchasing). Mientras tanto, puede editar el DNS en Tools → Domains → Replit Cloud, que acepta registros A, TXT y MX. La renovación automática tiene su propio interruptor, Auto renewal.
Paso 10: cierre en Replit
- En Publishing, use Unpublish. La app sale de línea y deja de generar cargos de deploy, pero archivos, código y base siguen allí (Deployment and publishing).
- Si algo sale mal, Publish en el proyecto antiguo devuelve la app con los datos del momento en que salió de línea.
- Después de revisar la base nueva, elimine la antigua en Database → Settings → Remove database. Hay 7 días para recuperarla con el soporte; después, no hay vuelta atrás.
Cuánto tiempo lleva
La documentación de Replit prevé de 15 a 60 minutos de app fuera de línea en el cambio, para una copia entre cuentas. Fuera de Replit, sume el tiempo de reemplazar login, storage e integraciones. Los pasos se parecen a los de exportar un proyecto de Bolt.new y salir de Lovable. Vea también el servicio de migración de plataforma.
¿Hacerlo usted mismo o contratar?
Esta guía basta cuando la app es simple; la tabla muestra cuándo conviene tener un equipo al lado.
| Situación | Camino |
|---|---|
| Deploy Static o app sin base de datos, y alguien en el equipo que levanta un servidor Node o Python | Hágalo usted mismo con esta guía |
| Base de producción con datos de usuarios reales | Llame a un equipo para el pg_dump, la restauración y la revisión en el cambio |
| Replit Auth, App Storage o Connectors en la app | Solicite el diagnóstico de Heartscale: lista cada dependencia y los riesgos del cambio |
| Plazo corto o nadie técnico en el equipo | Contrate la migración con precio cerrado |
Solicite un diagnóstico de Heartscale
Nuestro equipo mapea lo que su app usa de Replit: base de producción, Secrets, App Storage, Replit Auth y Connectors. Usted recibe el plan de migración, los riesgos del cambio 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.