Ce billet explique comment configurer Coolify et Traefik pour gérer des certificats SSL wildcard sur des sous-domaines dynamiques (comme user1.monapp.com, user2.monapp.com, etc.). L’auteur détaille d’abord le problème : avec des sous-domaines dynamiques, la validation HTTP classique de Let’s Encrypt ne fonctionne pas, car les domaines n’existent pas encore au moment de la demande de certificat. La solution passe par le DNS challenge, qui consiste à prouver le contrôle du domaine en ajoutant un enregistrement TXT dans la zone DNS, plutôt qu’un fichier sur le serveur.
Le guide décrit la configuration d’un résolveur de certificats dans Traefik (via Coolify) en utilisant l’API d’un fournisseur DNS compatible (comme bunny.net), puis montre comment appliquer ce résolveur à une application. Enfin, il aborde la gestion des custom domains, où l’utilisateur peut utiliser son propre domaine, en combinant un routeur Traefik avec une règle HostRegexp pour capturer tout le trafic inconnu et générer automatiquement les certificats via HTTP challenge. Un retour d’expérience utile pour qui veut automatiser la gestion du SSL sur des architectures multi-tenants.
Ce billet explique comment configurer une application multi-tenant avec des sous-domaines dynamiques (ex: clientA.monapp.com, clientB.monapp.com) en utilisant Coolify et Nuxt. Coolify, une alternative open-source aux PAAS comme Heroku, permet de déployer des applications et services managés. L’astuce repose sur l’utilisation des wildcard domains et la modification des Container labels de Traefik pour accepter tout le trafic sur *.monapp.com
via une expression régulière (HostRegexp(
.+.monapp.com$)). Côté Nuxt, un composable
useTenant()` extrait le sous-domaine de l’URL pour identifier le client. Une solution simple une fois la configuration Traefik bien comprise !
La multi-location (multi-tenancy) en base de données désigne une architecture où une seule instance d’application et d’infrastructure sert plusieurs clients (tenants), tout en garantissant une isolation logique de leurs données. Ce modèle, largement adopté dans le cloud, permet une meilleure scalabilité, une réduction des coûts de maintenance et une optimisation des ressources. L’article détaille quatre approches principales : base unique avec schéma partagé (simple mais risqué en cas d’oubli de filtrage par tenant), base unique avec schémas séparés (meilleure isolation mais complexité accrue), base dédiée par tenant (isolation maximale mais coûteuse en gestion), et plusieurs bases avec tenants partagés (compromis entre coût et performance). Chaque méthode présente des avantages et des inconvénients selon les besoins en sécurité, performance et maintenance
L’article explique comment implémenter une architecture multi-tenant dans Symfony à l’aide du bundle Hakam Multi Tenancy Bundle. L’objectif est de créer une application SaaS où chaque client (tenant) dispose de sa propre base de données isolée, tout en partageant une infrastructure commune. L’architecture repose sur une base principale (pour les utilisateurs et les configurations) et des bases dédiées par tenant (pour les données métiers, comme les patients dans l’exemple d’une application médicale). Le tutoriel détaille la configuration du bundle, la séparation des entités (Main/Tenant), la création des fixtures, et l’automatisation de la commutation de contexte en fonction de l’utilisateur connecté. L’approche permet une isolation totale des données, une scalabilité optimisée et une maintenance simplifiée. Idéal pour les applications nécessitant une sécurité et une personnalisation par client.
Tout est dans le titre
Cette association propose plusieurs services, en mode multi tenant :
- Nextcloud
- Wordpress
- Paheko (comptabilité / gestion d'adhérents)
L'auteur montre les différentes approches qu'il a utilisées pour répondre à son besoin
Les 19 conférences résumées :
- Résoudre AdventOfCode avec Github Copilot et OpenAI ChatGPTP
- Conversations avec ChatGPT : Illusion ou réalité ?
- Où va la Data Science ?
- Le multi-tenancy chez Apache Kafka, navigation dans un sujet majeur
- Storybook, une vraie bonne idée ?
- Revisiting Design Patterns after 20
- Java 19 & 20 : What’s new and noteworthy ?
- Comment des images peuvent-elles cacher des données secrètes dans leur encodage ?
- Rendons le DDD aux devs
- Container Builders : Which is the best image builder ?
- Alice au pays d’OpenTelemetry
- CRAC VM vs GRaal VM : Pour un démarrage rapide
- Cloud Native Security for the rest of us
- FoundationDB : Le secret le mieux gardé des nouvelles architectures distribuées !
- SQL (le retour) : Démystifions les idées préconçues et utilisons la DB efficacement
- Comment réduire et optimiser une table postgreSQL de plus de 5To ?
- De Chroot à Docker, Podman, et maintenant les modules Wasm, 40 ans d’évolution de la conteneurisation
- Voyage au centre de la veille : Apprendre en continu avec sa veille technologique
- Le numérique c’est pour tout le monde… Ou pas !