Skip to main content
Consultez Replit Status, puis identifiez où l’échec se produit : pendant le build, le démarrage ou le traitement des requêtes. Conservez les journaux du déploiement en échec avant de réessayer. Consultez Dépannage de la publication pour les détails de configuration.

​
La publication échoue pendant le build

  1. Ouvrez Publishing et les journaux du déploiement en échec.
  2. Trouvez la première erreur exploitable, pas seulement le message final « build failed ».
  3. Vérifiez la commande de build, l’installation des dépendances et les chemins de fichiers référencés.
  4. Vérifiez si les variables d’environnement requises sont configurées pour la publication. Un Preview qui fonctionne ne vérifie pas la configuration de production.
  5. Corrigez le problème identifié, publiez à nouveau et comparez les nouveaux journaux.
Si la commande d’exécution est absente, vérifiez la configuration de publication et enregistrez la commande voulue avant de réessayer. Ne republiez pas à répétition un build inchangé.

​
Le build réussit, mais le démarrage ou les vérifications d’état échouent

Vérifiez que la commande d’exécution démarre un serveur de longue durée plutôt qu’un processus de build qui se termine. Pour un serveur web, vérifiez son adresse de liaison et la configuration du port. Il doit accepter les connexions externes plutôt que d’écouter uniquement sur localhost. Lisez Configuration des ports avant de modifier des mappages de ports explicites. Examinez les journaux de démarrage à la recherche de secrets de production manquants, d’échecs de base de données ou d’exceptions avant que le serveur ne commence à accepter des requêtes. Ne retirez pas sans discernement l’authentification ou les vérifications de l’application pour faire passer un déploiement. Diagnostiquez la route en échec ou la dépendance de démarrage.

​
L’application publiée renvoie une erreur 500 ou 502

  1. Reproduisez une requête et notez son heure et l’URL concernée.
  2. Examinez les journaux d’exécution autour de ce moment à la recherche d’exceptions, de plantages ou de redémarrages.
  3. Vérifiez si une base de données ou une API externe requise est joignable.
  4. Comparez les échecs avec l’utilisation du CPU et de la mémoire dans Surveillance.
Une erreur 500 ou 502 est un symptôme, pas la preuve d’une cause précise. Consultez Réseau et erreurs d’application. Si l’URL replit.app fonctionne mais que le domaine personnalisé échoue, utilisez le guide des domaines. Si seule la connexion échoue, utilisez le guide d’authentification.

​
Preview fonctionne, mais pas la version publiée

Comparez la version publiée, les commandes de build et d’exécution, les secrets de production, la sélection de la base de données et la configuration d’authentification. Mettre à jour un secret de l’espace de travail ne prouve pas que l’application publiée utilise la même valeur. Après une modification ciblée de la configuration de production, publiez-la et testez à nouveau. Avant de redéployer une version plus ancienne, vérifiez si elle est compatible avec le schéma de base de données actuel. Redéployer du code n’est pas une restauration de base de données.

​
La publication est bloquée par une politique de l’espace de travail

Pour « Public deployments are not allowed for this workspace », demandez à l’administrateur de votre espace de travail d’examiner la politique de publication. Ne contournez pas la politique en déplaçant le code ou les données vers un espace de travail personnel.

​
Le problème persiste ?

Envoyez au support l’URL du projet, le type de déploiement, la phase en échec, les journaux de build ou d’exécution nettoyés et l’heure d’une requête en échec. Précisez si Preview et l’URL publiée se comportent différemment. Suivez la liste de vérification du support.