Español
English
Català
FrançaisBolt.new permet déjà de publier depuis son espace et documente des options avec GitHub et Netlify. Si Bolt Cloud répond aux besoins de votre application, rien n’oblige à la déplacer. Si le coût motive ce choix, comparez les offres actuelles de Bolt Cloud au prix et aux limites de la destination, en incluant base de données, authentification et stockage. Ce guide s’adresse aux projets qui doivent fonctionner sur une autre infrastructure, suivre le processus de déploiement de votre équipe ou séparer l’hébergement des services créés par Bolt.
Si vous choisissez encore où publier un site créé avec l’IA, commencez par identifier ce que le projet doit exécuter. Si votre projet est toujours sur un ordinateur et n’a pas d’URL publique, suivez d’abord le guide de localhost à Internet.
1. Sécurisez le code et la dernière modification
Connectez le projet à GitHub ou vérifiez que le dépôt synchronisé contient les dernières modifications. La documentation GitHub de Bolt explique comment conserver le code dans un dépôt et le publier avec un autre service. Vérifiez la branche active, le dernier commit et la fin de la synchronisation. Un dossier source téléchargé ne sauvegarde pas les données de production.
Avant de changer d’hébergeur, créez un commit identifiable et une copie récupérable des données à conserver. N’ajoutez pas de fichier .env, clé privée ou identifiant au dépôt. Gardez le déploiement actuel disponible jusqu’à la validation de la nouvelle version.
2. Vérifiez ce que la destination doit exécuter
Examinez package.json, les commandes de compilation et de démarrage, la configuration et les routes de l’application. Lancez le build localement ou dans l’environnement cible et identifiez le dossier produit (dist, build ou autre). Un dossier statique peut servir le frontend ; il n’exécute pas à lui seul une API, des tâches persistantes ou des fonctions serveur.
Bolt peut héberger des projets et connecter GitHub à des services externes. Sa documentation sur l’hébergement et le guide de publication avec Netlify présentent ces options. Si l’app utilise des routes serveur ou les fonctions de Bolt Cloud, trouvez une solution compatible avant de modifier le DNS.
3. Migrez les dépendances absentes de Git
Le dépôt ne transfère pas automatiquement les bases de données, utilisateurs, fichiers, secrets ni les e-mails. Bolt Cloud peut inclure une base de données, le stockage de fichiers, l’authentification et des fonctions serveur. Si le projet utilise Supabase, vérifiez la connexion et le guide d’intégration ; une base externe nécessite également son propre plan de migration.
Relevez chaque variable du backend, URL de retour de connexion, domaine autorisé et intégration. Transférez les données avec des outils compatibles avec les moteurs source et cible ; vérifiez schéma, permissions, extensions et fichiers sur une copie de test. Ne lancez pas de restauration destructive sur la base active. Conservez les clés privées dans les paramètres secrets du nouvel environnement, jamais dans le code envoyé au navigateur.
4. Choisissez la destination selon les besoins
Hostbrid Projects peut déployer depuis Git et exécuter des services Docker dans les limites de l’offre. Dev est destiné aux sites statiques ; les services persistants nécessitent une offre payante. Avant de commander, vérifiez les offres et limites ainsi que runtime, mémoire, stockage, ports et processus requis.
Si vous avez besoin de l’accès root, de gérer le système d’exploitation ou d’exécuter des services hors de Projects, envisagez un VPS que vous administrerez. Pour WordPress et les autres services PHP gérés, consultez Sites. Ne choisissez pas un VPS simplement parce que Bolt a généré un projet JavaScript.
5. Testez avant de déplacer le domaine
Publiez d’abord sur une URL temporaire. Vérifiez les routes directes, formulaires, lectures et écritures, téléversement de fichiers, connexion et récupération du compte, callbacks et e-mails. Assurez-vous que le frontend appelle la nouvelle API et qu’aucun secret n’apparaît dans le navigateur. Si l’app dépend de Node ou Docker, suivez aussi la liste de contrôle du port et de la santé du service.
Ne changez le DNS qu’après ces tests et la validation du HTTPS sur la nouvelle destination. Gardez une procédure claire pour revenir à l’ancien service. Pour PostgreSQL, notre guide de migration et vérification des données décrit le transfert entre bases compatibles.
Si vous ne savez pas si votre app est statique ou dépend de Bolt Cloud, indiquez-nous son framework et ses dépendances ; ne transmettez ni mot de passe ni clé. Déplacer le code ne garantit pas une facture plus faible et ne transfère pas automatiquement tous les services associés.