Español
English
Català
FrançaisUne application Replit peut réunir code, publication, base de données, authentification, stockage de fichiers et secrets. La déplacer vers un autre hébergement ne consiste pas seulement à copier les fichiers : identifiez d’abord les services utilisés et ceux que la nouvelle destination devra continuer à exécuter.
Si vous choisissez encore le type d’hébergement, consultez les besoins d’un site créé avec une IA. Si votre question générale est de passer de localhost à une URL publique, commencez par le guide de publication depuis localhost.
1. Synchronisez le code et gardez une possibilité de retour
Dans Replit, vérifiez le panneau Git et confirmez que le dépôt connecté contient les derniers changements à déployer. La documentation de contrôle de version Replit explique GitHub, les commits et les branches. Les checkpoints de l’Agent font partie de l’historique Git ; vérifiez tout de même le dernier commit et la fin de la synchronisation GitHub avant le déploiement.
Avant de changer de destination, créez un commit identifiable et une copie sécurisée des données à conserver. N’ajoutez pas de fichiers .env, identifiants, clés privées ou exports de clients au dépôt. Ne désactivez pas encore la publication actuelle : elle sert de référence pendant les tests du nouveau site.
2. Inventoriez les services, pas seulement les fichiers
Examinez package.json, la commande de démarrage, .replit, les Dockerfiles et la documentation du projet. Notez le rôle de chaque composant :
- Le frontend peut produire des fichiers statiques ou dépendre d’un serveur Node actif.
- La connexion peut utiliser des URL de retour, identifiants ou un fournisseur d’identité configuré dans Replit.
- L’application peut se connecter à une base de données, stocker des fichiers ou appeler des API externes.
- Les secrets configurés dans Replit doivent être réinstallés de manière sécurisée dans l’environnement cible.
Testez le projet localement ou dans l’environnement cible, en dehors de l’aperçu Replit. Vérifiez la commande de compilation, le démarrage, le port, les routes et les variables nécessaires à chaque processus. Si le frontend est statique, n’achetez pas un serveur simplement parce que le projet a été créé dans Replit. S’il a besoin d’une API ou de tâches persistantes, un dossier dist ne suffit pas.
3. Migrez la base de données et les fichiers avec prudence
Identifiez où se trouvent les données de développement et de production avant de modifier DATABASE_URL. Replit sépare ces bases (documentation sur le développement et la production) et décrit sa base de données SQL. Ces pages décrivent le service dans Replit, pas une migration complète vers un autre fournisseur. Pour un transfert externe, suivez une procédure compatible avec le moteur et la destination, puis vérifiez le schéma, les extensions, les rôles et les données. Faites une sauvegarde vérifiée avant toute restauration ; ne testez jamais de commandes destructives en production.
Planifiez une courte interruption des écritures ou une synchronisation finale, créez une sauvegarde, restaurez sur la destination et vérifiez les utilisateurs, enregistrements et relations avec des données de test. Si vous déplacez PostgreSQL vers une autre base gérée, suivez notre guide de migration avec pg_dump et pg_restore. Les fichiers App Storage, sessions et données d’autres services exigent leurs propres procédures.
4. Choisissez la destination selon le runtime et les responsabilités
Hostbrid Projects peut publier des projets depuis Git et exécuter des services Docker dans la limite de l’offre. Vérifiez le runtime, le stockage, les ports et les ressources avant de commander ; Dev publie des projets statiques et les services permanents nécessitent une offre payante. Consultez les offres et limites actuelles.
Si vous avez besoin d’un accès root, du contrôle du système d’exploitation ou de services réseau et processus hors des limites de Projects, envisagez un VPS, que vous devrez administrer. Pour WordPress et les autres services PHP gérés, consultez Sites. Le guide officiel Replit sur les domaines personnalisés décrit sa configuration actuelle ; lors du changement de nom d’hôte, vérifiez aussi les domaines autorisés et les URL de retour de connexion.
5. Testez avant de changer le domaine
Déployez d’abord sur une URL temporaire. Vérifiez connexion, récupération du mot de passe, lectures et écritures en base, dépôt de fichiers, e-mails, callbacks et routes internes. Comparez les journaux d’erreurs et contrôlez qu’aucune requête de production ne pointe encore par erreur vers l’ancien service.
Après validation, modifiez le DNS selon les instructions de la nouvelle destination et contrôlez HTTPS. Gardez l’ancienne version accessible pendant la transition. Définissez ce qui rétablit l’ancien domaine et les données à synchroniser avant un retour arrière.
Déplacer l’application peut vous donner le contrôle du code, de la destination et des coûts, mais ne garantit pas une facture plus basse ni la migration automatique des services liés à Replit. Si vous ne pouvez pas identifier le backend, la base ou l’authentification, indiquez-nous le framework et ses dépendances avant de choisir une offre ; ne transmettez ni secrets ni exports de données.