Fonctionnement
Préparer votre application
Lisez le port dans process.env.PORT
Ne codez pas le port en dur. Écoutez sur 0.0.0.0, jamais sur localhost. Si cette règle est ignorée: Le routeur livre sur le port déclaré et personne ne répond. Le visiteur reçoit une 502 alors que le conteneur est sain.
Lancez les migrations au démarrage, pas pendant le build
Un migrate deploy avant de démarrer le serveur. Pendant la construction de l’image, il n’y a aucune base à laquelle se connecter. Si cette règle est ignorée: La base reste avec zéro table et l’application renvoie une erreur dès la première requête. C’était le défaut le plus fréquent lors des vraies migrations.
Échouez bruyamment quand la migration échoue
Si le migrate échoue, le processus doit s’arrêter avec le message dans le log — et ne pas démarrer quand même. Si cette règle est ignorée: L’application reste en ligne en servant des erreurs, le tableau de bord est vert, et personne ne s’en aperçoit avant qu’un client se plaigne.
Les variables NEXT_PUBLIC_* sont des arguments de build
Dans Next.js, elles sont écrites dans le bundle pendant le build. Déclarez chacune comme ARG et promouvez-la en ENV avant la ligne qui construit. Si cette règle est ignorée: La valeur de développement reste intégrée pour toujours. Le site de production continue d’appeler localhost.
Rien d’important sur le disque du conteneur
Fichiers envoyés, images, pièces jointes : envoyez-les vers le stockage S3. Le disque du conteneur disparaît quand la copie est recréée. Si cette règle est ignorée: Les fichiers disparaissent au déploiement suivant, sans avertissement et sans moyen de les récupérer.
Ne gardez pas l’état uniquement en mémoire
Session, file, cache partagé : placez-les dans la base ou dans Redis. Avec plusieurs copies, chaque processus a sa propre mémoire. Si cette règle est ignorée: L’utilisateur perd sa session dès qu’une requête arrive sur une autre copie, et des écritures disparaissent sans aucune erreur.
Un planificateur intégré exige une seule copie
Si l’application a un cron interne, prévenez la personne qui déploie. L’autre solution est de déplacer la tâche dans un service à part. Si cette règle est ignorée: Facturation en double, message envoyé deux fois, client bloqué par erreur.
Répondez quelque chose sur /
Toute réponse inférieure à 500 convient — y compris une redirection vers la connexion. C’est ainsi que la plateforme sait que l’application est vivante. Si cette règle est ignorée: L’application est considérée comme hors ligne et le propriétaire reçoit une alerte de panne qui n’existe pas.
Logs sur stdout, pas dans un fichier
Écrivez sur la sortie standard. N’ouvrez pas de fichier de log dans le conteneur. Si cette règle est ignorée: Le log reste coincé sur un disque que personne n’atteint, précisément quand vous en avez besoin.
Chaque secret vient de l’environnement
Clé d’API, secret de jeton, identifiant tiers : uniquement via des variables d’environnement. Jamais commité, jamais avec une valeur par défaut qui fonctionne. Si cette règle est ignorée: Le secret fuit dans le dépôt et fonctionne pour quiconque clone le code.
Monorepo : un service par programme, dans le même projet
Le site et l’API du même dépôt deviennent deux services du même projet, chacun avec son Dockerfile et son port. Ne créez pas deux projets. Si cette règle est ignorée: Avec deux projets, les secrets doivent être recopiés à la main de l’un à l’autre — et le jour où l’un change et pas l’autre, le jeton n’est plus accepté et personne ne comprend pourquoi.
Dockerfile : indiquez le chemin, gardez le contexte à la racine
Dans un monorepo, indiquez le chemin complet du Dockerfile du service. Le contexte reste à la racine pour trouver le lockfile partagé. Si cette règle est ignorée: Le build échoue avec « open Dockerfile: no such file or directory » dans un dépôt qui contient pourtant un Dockerfile.