Passer au contenu principal
Ces réponses couvrent la publication et les déploiements. Pour le dépannage étape par étape, consultez Dépannage des déploiements, et pour les types de déploiement et la surveillance, consultez Déploiements Autoscale et Surveillance d’un déploiement.
La plupart des échecs de publication Autoscale sont corrigeables une fois que vous lisez les journaux de déploiement :
  1. Ouvrez Publication et trouvez le déploiement échoué.
  2. Sélectionnez le menu à trois points à côté pour ouvrir les journaux.
  3. Copiez la sortie des journaux, ouvrez un nouveau chat Agent, collez-la et demandez ce qui ne va pas et comment y remédier.
Si vous voyez une erreur No run command configured même si vous en avez défini une, ouvrez vos paramètres de déploiement, déconnectez la commande d’exécution, rajoutez-la, puis sauvegardez et republiez. Consultez Dépannage des déploiements.
Si la publication a réussi mais que l’application en direct renvoie une erreur 500, le problème se trouve dans le code de votre application plutôt que dans l’infrastructure de Replit :
  1. Ouvrez Publication, consultez les journaux et copiez le texte d’erreur complet.
  2. Ouvrez un nouveau chat Agent, collez les journaux et demandez ce qui cause l’erreur.
  3. Appliquez la correction et republiez.
Si Agent ne trouve pas le problème, ouvrez Publication → Historique, trouvez la dernière version fonctionnelle et redéployez-la. Consultez Dépannage des déploiements.
  1. Ouvrez le panneau Shell et exécutez kill 1 pour redémarrer le processus en arrière-plan. (kill 1 est sans danger dans Replit—il redémarre le processus principal de votre projet, il ne supprime rien.)
  2. Ouvrez Publication et sélectionnez Publier pour déclencher un nouveau déploiement.
  3. En cas d’échec répété, ouvrez les journaux du déploiement échoué depuis le menu à trois points, copiez le journal de construction et collez-le dans un nouveau chat Agent pour le diagnostic.
Si le déploiement reste bloqué, contactez le support Replit avec vos journaux de construction complets. Consultez Dépannage des déploiements.
  1. Vérifiez vos journaux de déploiement pour des messages récurrents de délai d’attente dépassé ou de mémoire insuffisante.
  2. Vérifiez les ressources de déploiement pour les limites de CPU ou de mémoire—consultez Surveillance d’un déploiement.
  3. Ouvrez un nouveau chat Agent, collez les journaux récents et demandez à Agent de trouver les goulots d’étranglement.
Les causes courantes incluent les requêtes de base de données sans index, les opérations synchrones bloquantes et les fuites mémoire. Avec les déploiements Autoscale, la première requête après une mise à l’échelle à zéro peut prendre quelques secondes—c’est un démarrage à froid normal.
Ouvrez Publication → Historique, sélectionnez le déploiement échoué et consultez les journaux de construction. Trouvez la première ligne marquée ERROR ou FAILED—c’est généralement la cause principale, et les lignes suivantes sont des effets en cascade. Copiez cette section dans un nouveau chat Agent pour le diagnostic. La plupart des échecs de construction proviennent de dépendances manquantes, d’une commande d’exécution incorrecte ou d’une migration de base de données échouée. Consultez Surveillance d’un déploiement.
C’est presque toujours une différence de configuration entre les environnements. Vérifiez que :
  • Chaque clé de votre panneau Secrets de développement est également définie dans vos secrets de déploiement—ce sont des environnements séparés.
  • Votre DATABASE_URL pointe vers la base de données de production, pas celle de développement.
  • Il n’y a pas de références codées en dur vers localhost ou 127.0.0.1 ; utilisez des chemins relatifs ou des URL basées sur l’environnement à la place.
Vérifiez ensuite vos journaux de déploiement pour les erreurs spécifiques à la production. Consultez Dépannage des déploiements.
Les déploiements Autoscale redémarrent régulièrement par conception. Un SIGTERM dans vos journaux signifie que le processus a été arrêté gracieusement—c’est normal. Exit code 1 signifie que le processus s’est planté de lui-même ; vérifiez les lignes juste avant pour l’erreur réelle.Si les redémarrages sont suffisamment fréquents pour affecter les utilisateurs, recherchez les rejets de promesses non gérés, les erreurs de mémoire insuffisante ou les variables d’environnement manquantes qui font échouer le démarrage.
Replit conserve les secrets de développement et de production dans des magasins séparés, et la modification de l’un ne met pas à jour l’autre. Le panneau Secrets de développement n’est disponible que dans l’éditeur ; votre application déployée lit depuis vos secrets de déploiement.Pour mettre à jour une variable dans votre application en direct, définissez-la dans vos secrets de déploiement, puis ouvrez Publication et sélectionnez Publier pour redéployer. Les nouvelles valeurs prennent effet au démarrage du nouveau déploiement. Consultez Dépannage des déploiements.
Ouvrez Publication et sélectionnez Publier. Replit construit et déploie votre code actuel même si rien n’a changé—utile après la mise à jour d’un secret, après une réactivation de base de données ou pour récupérer une mise à jour de dépendance.Si votre application ne répond pas et qu’un redéploiement complet semble lourd, ouvrez le panneau Shell et exécutez kill 1 pour redémarrer le processus en arrière-plan sans redéployer.
Oui. Ouvrez Publication, sélectionnez une nouvelle région et publiez pour redéployer là-bas. Consultez Géographie de publication.La région de votre base de données ne peut pas être modifiée sur place—pour la déplacer, forkez l’application et déployez la version forkée dans la nouvelle région. Après le changement de région, votre sous-domaine .replit.app peut changer, donc connectez d’abord un domaine personnalisé si vous avez besoin d’une URL stable, et rajoutez les secrets de déploiement.
Ouvrez Publication et sélectionnez l’option pour arrêter votre déploiement, puis confirmez. Votre application passe hors ligne et cesse d’engendrer des frais de déploiement. Vos fichiers de projet, votre code et votre base de données ne sont pas supprimés—seul le déploiement en direct s’arrête. Les connexions de domaine personnalisé liées à ce déploiement sont supprimées, alors rajoutez-les si vous republicez.Si le coût est votre préoccupation, notez que les déploiements Autoscale se mettent à l’échelle à zéro en l’absence de trafic, donc vous n’avez peut-être pas besoin d’arrêter du tout.

​
Vous avez encore besoin d’aide ?

Si votre question sur le déploiement n’est pas répondue ici, contactez le support Replit.