Español
English
Català
FrançaisUna aplicació creada a Replit pot combinar codi, publicació, base de dades, autenticació, emmagatzematge de fitxers i secrets. Moure-la a un altre allotjament no és només copiar arxius: primer identifica quins serveis fa servir i quins ha de continuar executant el nou destí.
Si encara estàs triant el tipus d’allotjament, consulta què necessita una web creada amb IA. Si la pregunta general és com passar un projecte de localhost a una URL pública, comença per la guia de publicació des de localhost.
1. Sincronitza el codi i conserva una manera de tornar enrere
A Replit, revisa el panell Git i confirma que el repositori connectat conté els darrers canvis que vols desplegar. La documentació de control de versions de Replit explica com treballar amb GitHub, commits i branques. Els checkpoints de l’Agent formen part de l’historial Git; tot i així, comprova l’últim commit i que la sincronització amb GitHub hagi acabat abans de desplegar.
Abans de canviar de destí, crea un commit identificable i una còpia segura de les dades que hagis de conservar. No afegeixis .env, credencials, claus privades ni exportacions de clients al repositori. Encara no apaguis la publicació actual: et servirà de referència mentre proves la nova.
2. Fes inventari dels serveis, no només dels fitxers
Revisa package.json, l’ordre d’inici, .replit, els Dockerfiles i la documentació del projecte. Anota què fa cada part:
- El frontend pot generar fitxers estàtics o dependre d’un servidor Node en execució.
- L’inici de sessió pot dependre d’URL de retorn, credencials o un proveïdor d’identitat configurat a Replit.
- L’aplicació pot connectar-se a una base de dades, desar fitxers o cridar APIs externes.
- Els secrets configurats a Replit s’han de tornar a introduir de manera segura a l’entorn de destí.
Prova el projecte localment o a l’entorn de destinació, fora de la previsualització de Replit. Comprova l’ordre de compilació, l’ordre d’inici, el port, les rutes i les variables que necessita cada procés. Si només hi ha frontend estàtic, no contractis un servidor només perquè el projecte s’ha creat a Replit. Si necessita una API o tasques persistents, un directori dist tot sol no és suficient.
3. Migra la base de dades i els fitxers amb cura
Identifica on són les dades de desenvolupament i de producció abans de canviar DATABASE_URL. Replit separa aquestes bases (documentació de desenvolupament i producció) i explica la seva base de dades SQL. Aquestes pàgines descriuen el servei dins de Replit, no una migració completa a un altre proveïdor. Per moure les dades fora, segueix un procediment compatible amb el motor i el destí, i valida l’esquema, les extensions, els rols i les dades. Fes una còpia verificada abans de restaurar; no provis ordres destructives en producció.
Planifica una pausa breu d’escriptures o una sincronització final, crea una còpia, restaura al destí i valida usuaris, registres i relacions amb dades de prova. Si vols moure PostgreSQL a una altra base gestionada, segueix la nostra guia de migració amb pg_dump i pg_restore. Els fitxers d’App Storage, les sessions i les dades d’altres serveis requereixen procediments propis.
4. Tria el destí segons el runtime i les responsabilitats
Hostbrid Projects pot publicar projectes des de Git i executar serveis Docker dins de la quota del pla. Verifica el runtime, l’emmagatzematge, els ports i els recursos abans de contractar; Dev publica projectes estàtics i els serveis permanents requereixen un pla de pagament. Revisa els plans i límits actuals.
Si necessites accés root, control del sistema operatiu o serveis de xarxa i processos que superen Projects, considera un VPS, que hauràs d’administrar. Per a WordPress o altres serveis PHP gestionats, consulta Sites. La guia oficial de Replit sobre dominis personalitzats explica la configuració actual; en moure el nom de domini, revisa també els dominis permesos i les URL de retorn de l’inici de sessió.
5. Prova abans de moure el domini
Desplega primer amb una URL temporal. Comprova inici de sessió, recuperació de contrasenya, lectura i escriptura de dades, pujada de fitxers, correus, callbacks i rutes internes. Compara els registres d’errors i comprova que cap petició de producció continuï apuntant al servei antic per accident.
Quan la nova versió estigui validada, canvia DNS seguint les instruccions del destí i revisa HTTPS. Mantén disponible la versió antiga durant la transició. Decideix quin canvi tornaria a posar el domini antic i quines dades s’haurien de sincronitzar abans de fer marxa enrere.
Moure l’aplicació et pot donar control sobre el codi, el destí i els costos, però no garanteix una factura més baixa ni la migració automàtica dels serveis vinculats a Replit. Si no identifiques el backend, la base de dades o l’autenticació, explica’ns el framework i les dependències abans de triar pla; no enviïs secrets ni volcats de dades.