Pack de déploiement Coolify — 12 architectures

Le pack réunit Baserow, CKAN, ERPNext, Frappe Framework, KoboToolbox, Mem0, NetBox, ODK Central, OpenEMR, OpenMRS, OpenSPP et Overleaf Community Edition. Chaque composition part de l’architecture du produit ciblé. Elle ne transpose pas les services d’un logiciel vers un autre et ne cherche pas un nombre moyen de conteneurs.

Les modèles Docker Compose versionnés sont accompagnés de règles de découverte d’architecture, de réseau, de domaines, de secrets, de cycle de vie et de reprise. Les études de cas expliquent les échecs et corrections propres à chaque cible. Les scripts de validation contrôlent la structure des fichiers et protègent les comportements déjà acceptés contre les régressions.

Commencer par la fiche Solution puis sélectionner la version et le profil d’hébergement. Identifier le service public, les états durables, le propriétaire des migrations, les tâches asynchrones et les dépendances externes. Ouvrir ensuite le Déploiement et son Compose. Cette progression permet de comprendre pourquoi chaque service, volume et variable existe avant de modifier le fichier.

Une URL de navigateur, une cible de proxy et un nom Docker répondent à des rôles distincts. Un secret généré conserve le même identifiant complet chez tous ses consommateurs. Les fichiers gérés, commandes Compose et scripts embarqués n’interprètent pas les caractères de la même manière. Enfin, les healthchecks observent une responsabilité précise : socket, application, worker, activation de produit ou parcours utilisateur.

Le déploiement n’est accepté qu’après un parcours représentatif : formulaire soumis dans KoboToolbox, ressource importée dans CKAN, projet compilé dans Overleaf, dossier clinique relu ou modules OpenSPP activés. Le redéploiement vérifie la persistance. Lorsque la reprise est couverte, la restauration s’effectue dans des volumes isolés et retourne jusqu’à ce même parcours.

Pour une nouvelle version, relire d’abord les changements amont puis comparer images, variables, schémas, chemins persistants et procédures de migration. Produire un point de reprise avant l’essai. Une correction reste locale tant que sa cause n’est pas démontrée ailleurs. Cette discipline permet d’apprendre d’un cas sans contaminer une autre architecture avec des services ou contournements inutiles.

OpenEMR montre qu’un runtime à deux services peut couvrir un produit clinique complet ; KoboToolbox justifie au contraire plusieurs domaines et magasins. NetBox sépare deux Valkey aux sémantiques opposées. Baserow conserve une passerelle applicative derrière Coolify. Ces contrastes sont essentiels : ils empêchent de transformer un succès local en règle universelle et orientent la découverte vers les responsabilités actuelles du logiciel.

Pour chaque architecture, conserver la version, les domaines, l’inventaire des états, la procédure de contrôle et la date du dernier exercice de reprise. Les secrets restent hors des fichiers partagés. Une deuxième personne doit pouvoir importer le modèle, comprendre le premier échec éventuel et retrouver le parcours d’acceptation sans dépendre de l’historique des essais.

Les compositions ciblent les versions indiquées et servent de points de départ reproductibles. Elles ne remplacent ni le dimensionnement, ni la politique de sécurité, ni l’administration du produit. Avant toute exploitation, l’organisation adapte les domaines, le courrier, la rétention, la supervision et les procédures d’assistance, puis rejoue le parcours fonctionnel sur son propre environnement.