Dépannage

Les pannes les plus fréquentes, dans l’ordre où vous risquez de les rencontrer. Chacune commence par ce qu’il faut vérifier en premier.

Le SSL d’un domaine reste sur PENDING

• Le DNS n’est pas propagé — attendez, puis cliquez Vérifier maintenant dans l’onglet Enregistrements.
• L’enregistrement A pointe vers la mauvaise adresse — corrigez chez votre registrar.
• Les ports 80 et 443 sont fermés sur le serveur — vérifiez le pare-feu. Let’s Encrypt doit joindre le serveur pour valider le domaine.

L’application est RUNNING mais l’URL ne répond pas

• Aucun domaine n’est attaché — Applications → l’application → Domaines → attacher.
• Le reverse proxy est désynchronisé — Domaines → Synchroniser le reverse proxy.
• Le port est faux. L’application doit écouter sur le port configuré, dans le conteneur — et sur 0.0.0.0, pas 127.0.0.1. Une application liée à localhost est injoignable hors de son propre conteneur.

Les services d’un serveur distant ne se voient pas

Le réseau de projet nécessite un agent à jour. L’agent est un binaire autonome, pas un dépôt Git : le mettre à jour, c’est relancer son installateur — Serveurs → votre serveur → Commande d’installation, collée en SSH. Il télécharge le dernier binaire et redémarre le service.

curl -fsSL '<api>/api/agent/install.sh?token=…' | sh

Vérifiez ensuite que les deux services sont dans le même projet — le réseau ne franchit pas les projets. Voir réseau de services.

Après un déplacement, les données sont restées sur l’ancien serveur

• Les volumes se transfèrent de façon asynchrone pendant un déplacement. Si la mise en place a échoué, les applications ont été déployées avec des volumes vides et un avertissement a été levé — consultez les avertissements de migration sur le projet.
• Les volumes source sont préservés sur l’ancien serveur. Le déplacement lui-même ne purge jamais rien.
• La récupération fiable, c’est une sauvegarde prise sur l’ancien serveur et restaurée sur le nouveau.

Je suis passé en mode Local et mes applications ont disparu

Elles tournent toujours sur les serveurs distants — le mode Local les masque, c’est tout. Rebasculez en multi-serveur pour les revoir, ou rapatriez-les d’abord sur ce serveur. Rien n’a été supprimé. Voir modes de déploiement.

Le build échoue sur un monorepo

Presque toujours le contexte de build. Un COPY pnpm-lock.yaml dans le Dockerfile d’un sous-dossier échoue si le contexte est ce sous-dossier, car le lockfile est au-dessus. DockBoard détecte les workspaces et construit depuis la racine du dépôt automatiquement ; quand la détection se trompe, réglez-le explicitement — applications, monorepos.

Le log de build complet est sur le déploiement — ouvrez-le depuis l’historique de déploiement.

Toujours bloqué

• Lisez d’abord le log de build du déploiement — la plupart des échecs disent exactement ce qui s’est passé.
• Consultez le journal d’audit : il enregistre qui a changé quoi et quand, ce qui explique souvent un changement de comportement dont personne ne se souvient.
• Vérifiez les quotas — un projet à son plafond refuse le travail supplémentaire plutôt que de se dégrader en silence.