Domaines, réseaux et secrets dans Coolify

Domaines, réseaux et secrets dans Coolify répond à une question opérationnelle : comment prendre une décision reproductible, compréhensible par l’équipe et compatible avec les responsabilités du service. Le guide relie conception, mise en œuvre, contrôle et passage de relais.

Chaque étape produit un résultat concret : une carte, une règle, une configuration, un test ou une décision. Cette discipline évite que l’exploitation repose sur la mémoire d’une seule personne. Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback.

L’URL publique est celle du navigateur, des courriels et des callbacks ; elle passe par le proxy et utilise HTTPS. L’adresse interne relie les conteneurs par nom de service et port Docker. Mélanger les deux provoque redirections, cookies invalides, boucles de proxy ou trafic inutile hors du réseau privé.

Le résultat est consigné dans une fiche courte, relue par la personne qui utilisera ou administrera le service. KoboToolbox exige plusieurs origines coordonnées ; Baserow conserve une seule entrée Caddy ; Mem0 sépare tableau de bord et API.

Identifier l’unique point d’entrée prévu par le produit : frontend, passerelle ou serveur web. Attacher le domaine à ce service et laisser les bases, caches et workers sans exposition publique. Pour une application multi-domaines, documenter la fonction de chaque route et sa cible exacte.

Le contrôle est d’abord exercé sur un périmètre réduit, puis rejoué après chaque changement qui touche cette responsabilité. La même précision s’applique aux secrets : identifier qui les génère, qui les consomme, quelle syntaxe ils autorisent et comment ils traversent YAML, Compose, les fichiers gérés et le shell.

Distinguer le port écouté dans le conteneur, le port déclaré par l’image et l’éventuel port publié sur l’hôte. Dans Coolify, le proxy atteint généralement le port interne sans publication directe. Tester depuis le réseau du projet permet de confirmer l’écoute avant d’accuser le domaine ou le certificat.

L’équipe conserve un exemple nominal et un cas d’erreur afin que la procédure couvre le fonctionnement courant comme l’incident. Cette carte prévient les redirections, CORS et substitutions silencieuses.

L’application doit recevoir hôte, protocole et adresse client selon les conventions qu’elle supporte. Configurer la confiance dans le proxy et l’URL canonique ensemble. Une erreur à ce niveau peut produire des liens HTTP, des cookies rejetés, des protections CSRF déclenchées ou des redirections vers un nom interne.

Les rôles fonctionnel, technique et données valident ensemble les points qui traversent leurs responsabilités.

Créer des valeurs longues avec le mécanisme de secrets de la plateforme, une fois par responsabilité. Éviter les valeurs par défaut et ne pas les écrire dans le fichier téléchargé. Les clés qui chiffrent ou signent un état persistant font partie du plan de reprise et ne sont pas régénérées lors d’un simple redéploiement.

Une personne qui n’a pas conçu le dispositif suit ensuite les instructions et signale les étapes ambiguës ou implicites. Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback.

Lorsqu’un backend, un worker et une passerelle vérifient la même signature ou accèdent à la même base, ils doivent référencer le même secret. Réutiliser un identifiant de variable plutôt que copier plusieurs valeurs. Un contrôle après rendu vérifie que les services reçoivent bien la cohérence attendue.

Le temps nécessaire, les dépendances et le résultat observé sont notés pour dimensionner l’exploitation et le support. Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback.

Recenser les URL utilisées par OAuth, SSO, webhooks, formulaires et intégrations. Elles doivent correspondre au domaine public exact, y compris schéma et chemin, puis être autorisées chez le fournisseur externe. Tester un aller-retour complet révèle les erreurs que la seule ouverture de la page ne montre pas.

Le même repère est utilisé en test, lors du passage en exploitation et pendant les revues périodiques.

Une erreur 502 oriente vers le port, le protocole ou un service non prêt ; une 503 vers l’indisponibilité ou l’absence de cible ; une 421 vers l’hôte et le routage TLS. Vérifier successivement DNS, certificat, règle de proxy, écoute interne et santé applicative en conservant une seule hypothèse par essai.

Toute exception reçoit un responsable, une action et une échéance afin de rester visible jusqu’à sa résolution. Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback.

Avant de terminer, rejouer le scénario sans utiliser l’historique du navigateur ni une session administrateur déjà ouverte. Vérifier les erreurs visibles, les journaux, la persistance et les actions de l’utilisateur. Une autre personne doit pouvoir suivre la procédure avec les informations publiées et obtenir le même résultat. KoboToolbox exige plusieurs origines coordonnées ; Baserow conserve une seule entrée Caddy ; Mem0 sépare tableau de bord et API.

Le responsable fonctionnel définit le besoin, les règles métier et les critères de réussite. Le responsable des données fixe les catégories, les droits, la durée de conservation et les usages. L’administrateur applicatif gère les comptes, la configuration et l’assistance. L’équipe infrastructure prend en charge serveur, réseau, certificats, supervision et sauvegardes. Ces responsabilités peuvent être portées par peu de personnes, mais elles doivent rester explicites. La même précision s’applique aux secrets : identifier qui les génère, qui les consomme, quelle syntaxe ils autorisent et comment ils traversent YAML, Compose, les fichiers gérés et le shell.

Pour chaque opération récurrente, désigner qui prépare, qui approuve, qui exécute et qui vérifie. Cette matrice réduit les dépendances et accélère la réponse lorsque le contexte change. Cette carte prévient les redirections, CORS et substitutions silencieuses.

Planifier une revue après les premières semaines d’usage, puis à chaque changement important. Examiner les incidents, les demandes d’assistance, les écarts de qualité, les restaurations et le temps consacré à l’administration. Ces observations montrent si la procédure reste adaptée ou si une responsabilité doit être clarifiée. Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback.

La revue se termine par peu de décisions, chacune avec un responsable et une échéance. Les changements sont intégrés au guide, testés et communiqués aux utilisateurs concernés. Le document reste ainsi aligné sur le service réellement exploité. KoboToolbox exige plusieurs origines coordonnées ; Baserow conserve une seule entrée Caddy ; Mem0 sépare tableau de bord et API.

Noter la version, la date, la personne qui a exécuté le contrôle et le résultat attendu. Conserver les commandes ou captures strictement nécessaires à la reproduction. Une trace courte et structurée aide davantage qu’un long journal de dépannage sans décision. Elle facilite aussi la revue périodique et le transfert de responsabilité. La même précision s’applique aux secrets : identifier qui les génère, qui les consomme, quelle syntaxe ils autorisent et comment ils traversent YAML, Compose, les fichiers gérés et le shell.

Transformer le guide en séquence de travail avant d’intervenir. Définir le périmètre, l’environnement, les accès, les données d’essai, le créneau et les personnes disponibles. Prévoir un point d’arrêt avant chaque changement difficile à inverser et confirmer la manière de revenir à l’état précédent. Cette préparation réduit les improvisations et protège le service courant. Cette carte prévient les redirections, CORS et substitutions silencieuses.

Présenter ensuite la séquence aux futurs utilisateurs et aux responsables concernés. Leurs questions révèlent souvent une dépendance oubliée, une règle métier implicite ou un horaire inadapté. Intégrer ces éléments au scénario permet d’évaluer le dispositif dans les conditions où il sera réellement utilisé. Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback.

Un résultat fonctionnel aujourd’hui doit rester compréhensible demain. Vérifier qu’une deuxième personne peut localiser la configuration, identifier les états durables, lire les alertes et exécuter la procédure sans accès personnel du concepteur. Les dépendances externes, dates de renouvellement, versions et contacts d’assistance sont regroupés dans un emplacement partagé. KoboToolbox exige plusieurs origines coordonnées ; Baserow conserve une seule entrée Caddy ; Mem0 sépare tableau de bord et API.

Après un incident, une mise à jour ou un exercice de reprise, comparer le déroulement réel au guide. Corriger immédiatement les étapes imprécises, supprimer les opérations devenues inutiles et ajouter les contrôles qui auraient permis de détecter plus tôt le problème. La documentation devient ainsi une composante vivante du service. La même précision s’applique aux secrets : identifier qui les génère, qui les consomme, quelle syntaxe ils autorisent et comment ils traversent YAML, Compose, les fichiers gérés et le shell.

Avant d’élargir le périmètre, comparer les hypothèses du pilote avec l’usage observé : charge, qualité, demandes d’assistance, incidents, temps d’administration et capacité des équipes. Ajuster les rôles, les automatismes et la formation avant d’ajouter de nouveaux utilisateurs ou territoires. Une montée en charge progressive permet de conserver la compréhension du dispositif et de corriger les fragilités tant qu’elles restent maîtrisables. Cette carte prévient les redirections, CORS et substitutions silencieuses.

Pour chaque service, noter l’URL du navigateur, la cible du proxy Coolify, le nom Docker interne et les éventuelles URL de callback. KoboToolbox exige plusieurs origines coordonnées ; Baserow conserve une seule entrée Caddy ; Mem0 sépare tableau de bord et API. La même précision s’applique aux secrets : identifier qui les génère, qui les consomme, quelle syntaxe ils autorisent et comment ils traversent YAML, Compose, les fichiers gérés et le shell. Cette carte prévient les redirections, CORS et substitutions silencieuses.