Pourquoi utiliser un gestionnaire de feature flags
Le déploiement continu repose sur une séparation nette entre la mise en production d'un binaire et l'activation d'une fonctionnalité pour les utilisateurs. Sans cette séparation, chaque rollout est binaire : toute la base utilisateurs voit le changement, ou personne. En cas de problème, la seule option est le rollback du déploiement entier — souvent 10 à 30 minutes et un incident.
Unleash rompt ce couplage. Vous mergez la branche, vous déployez, puis vous activez la fonctionnalité manuellement ou par un rollout progressif configurable. Si quelque chose cloche, vous désactivez la flag en quelques secondes — pas de rollback, pas de hotfix, pas de nuit blanche.
Le second avantage est l'expérimentation. En définissant un segment d'utilisateurs (beta testeurs, plan Pro, utilisateurs de tel pays), vous pouvez activer une fonctionnalité uniquement pour eux et mesurer l'impact avant le déploiement général. C'est le principe des feature flags de type Experiment : vous A/B testez une fonctionnalité réelle, pas une copie de staging.
Unleash open source (Apache-2.0) couvre ces deux cas avec des projets, des environnements, des stratégies d'activation et un log d'audit complet — le tout sans dépendance propriétaire.
Ce que vous gagnez avec Unleash self-hosted
- Toggles en temps réel — activez ou désactivez une fonctionnalité sans redéployer votre application.
- Rollouts progressifs — ouvrez à 5 %, 20 %, 50 % de vos utilisateurs, avec ciblage par userId, email ou attribut personnalisé.
- Environnements séparés — maintenez des états de flags distincts entre développement, staging et production.
- SDK multilangage — clients officiels Node.js, Python, Go, Java, .NET, Ruby et PHP ; évaluation locale pour une latence nulle.
- Log d'audit complet — chaque changement de flag enregistre l'auteur, l'horodatage et la raison.
- Mises à jour sans interruption —
docker compose pull && docker compose up -d, migrations PostgreSQL automatiques.
Prérequis
Unleash est conçu pour fonctionner sur un VPS modeste. La configuration minimale recommandée est 1 vCPU et 1 Go de RAM — l'application Node.js consomme environ 86 Mo en veille, PostgreSQL 17 environ 46 Mo, pour un total de l'ordre de 132 Mo en conditions de test. En production avec un traffic SDK actif, prévoyez 256 Mo de marge et choisissez un VPS 1 Go en toute sécurité.
Aucun domaine n'est requis pour démarrer — Unleash écoute sur le loopback et est accessible via tunnel SSH. Pour un accès permanent depuis vos applications et pipelines CI, rattachez un domaine depuis votre espace client ServOrbit : nginx le proxifiera en HTTPS.
Docker doit être installé sur le VPS. Le template ServOrbit le préconfigure automatiquement — aucune action manuelle n'est nécessaire pour le setup initial.
Déployer Unleash sur votre VPS ServOrbit
Commander depuis la Marketplace ServOrbit
Depuis votre espace client ServOrbit, installez Unleash en un clic depuis la Marketplace : sélectionnez la catégorie Développement, choisissez Unleash et confirmez votre commande. La stack Docker Compose (Unleash + PostgreSQL 17) démarre automatiquement sur votre VPS. Vous recevrez une notification dès que le healthcheck répond, avec le port d'exposition assigné et le mot de passe admin généré.
Se connecter à l'interface d'administration
Ouvrez
https://<votre-domaine>/dans votre navigateur — ou, sans domaine, ouvrez un tunnel SSH :ssh -L 4242:127.0.0.1:<port> root@<ip-vps>puis naviguez surhttp://localhost:4242/. La page de connexion est à/auth/simple/login. Entrez le nom d'utilisateuradminet le mot de passe qui figure dans votre espace client ServOrbit.Créer un projet et votre première flag
Dans l'interface Unleash, créez un projet (par exemple
mon-app). Dans ce projet, ajoutez un feature toggle en cliquant sur New feature flag. Donnez-lui un nom (nouvelle-checkout), choisissez le type — Release pour une activation progressive, Kill switch pour un interrupteur de sécurité, Experiment pour un A/B test — et confirmez. La flag est créée mais désactivée par défaut dans tous les environnements.Configurer une stratégie d'activation
Cliquez sur votre flag, puis sur Add strategy dans l'environnement de votre choix (par défaut
production). Unleash propose plusieurs stratégies : Standard (activé pour tous), Gradual rollout (pourcentage d'utilisateurs), UserIDs (liste explicite), Remoteaddress (par IP). Pour un rollout progressif, choisissez Gradual rollout et fixez le curseur à 10 %. Cliquez sur Save strategy — la flag est maintenant active pour 10 % de vos utilisateurs.Connecter votre application au SDK
Installez le SDK pour votre langage :
npm install unleash-client(Node.js),pip install UnleashClient(Python), ou le package équivalent dans votre écosystème. Initialisez le client avec l'URL de votre API Unleash (https://<domaine>/api) et une clé d'API client (à créer dans Unleash → Settings → API access → Add new API token, type CLIENT). Appelez ensuiteclient.isEnabled('nouvelle-checkout')là où vous souhaitez conditionner le comportement.Surveiller et ajuster
L'onglet Metrics de chaque flag affiche le nombre d'évaluations positives et négatives par période. Augmentez progressivement le pourcentage de rollout en modifiant la stratégie, ou désactivez la flag globalement depuis le tableau de bord si vous observez un problème — sans aucun redéploiement. Pour archiver une flag définitivement activée, cliquez sur Archive dans les paramètres de la flag.
Pour les flags de type Kill switch, activez l'impression de métriques dans votre SDK (impressionDataAll: true) : chaque évaluation génère un événement que vous pouvez router vers votre outil d'observabilité (Glitchtip, Plausible, etc.) pour corréler un rollout avec une variation de vos indicateurs métier.
Gestion des environnements et promotion
Unleash open source crée deux environnements par défaut : development et production. Chaque flag possède un état indépendant par environnement — vous pouvez activer une fonctionnalité en développement pour toute l'équipe tout en gardant le rollout production à 0 %. C'est le modèle de promotion : la fonctionnalité est testée en développement, puis validée en production par une action délibérée dans l'UI.
Pour ajouter un environnement staging, rendez-vous dans Unleash → Settings → Environments → Add environment. Nommez-le staging, sauvegardez. Chaque flag affichera désormais trois onglets d'environnement. Le SDK doit être initialisé avec environment: 'staging' (ou 'development') pour que les évaluations atterrissent dans le bon état.
Un cas courant : activer une fonctionnalité en staging pour l'ensemble de l'équipe QA (UserIDs strategy avec la liste des emails internes), et en production avec un Gradual rollout à 5 %. Les deux stratégies coexistent dans la même flag, dans des environnements différents — sans aucun conflit.
Sécurité et tokens d'API
Unleash sépare les tokens par type et par environnement. Un token de type CLIENT donne accès en lecture seule à l'état des flags pour un environnement donné — c'est le token à injecter dans vos applications. Un token ADMIN donne accès complet à l'API d'administration — à réserver aux scripts de déploiement ou aux outils d'intégration, jamais embarqué dans le code client.
Creer un token CLIENT : Unleash → Settings → API access → Add new API token. Choisissez le type CLIENT, sélectionnez l'environnement (production) et l'ensemble de projets concernés. Copiez la valeur générée — elle n'est affichée qu'une fois. Stocker ce token dans les secrets de votre CI (variable d'environnement UNLEASH_API_TOKEN) ou dans le vault de votre gestionnaire de secrets.
Sur ServOrbit, Unleash est lié à 127.0.0.1 et exposé uniquement via nginx. Le port 4242 n'est pas directement accessible depuis internet — nginx ajoute TLS, et seul le domaine proxifié répond sur 443. Le mot de passe admin initial est généré à l'installation et disponible depuis votre espace client ; modifiez-le lors de la première connexion via Unleash → Profile → Change password.
Historique CVE et pourquoi la version 8.0.3 est épinglée
Unleash 8.0.3 est épinglé dans le template ServOrbit pour une raison précise : deux vulnérabilités ont été corrigées entre 8.0.0 et 8.0.3. CVE-2026-63004 (CVSS 5.5, SSRF) permettait à un administrateur authentifié de déclencher des requêtes serveur vers des endpoints réseau internes via la configuration des webhooks. CVE-2026-63466 (CVSS 4.1, XSS stocké par contournement d'échappement HTML) permettait d'injecter du HTML dans les descriptions de flags. Les deux nécessitent une authentification, donc le rayon d'impact se limite à des comptes admin compromis. Elles sont entièrement corrigées dans 8.0.3. Épingler le tag exact plutôt que :latest garantit que vous savez toujours quelle version tourne et pouvez l'auditer par rapport au registre CVE.
