[{"data":1,"prerenderedAt":244},["ShallowReactive",2],{"seo-verification":3,"blog-deployer-zitadel-vps-ma-fr":6,"promo-bar-likely":243},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-deployer-zitadel-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":197,"ctaBody":198,"ctaButton":199,"ctaUrl":200,"relatedPosts":201},351,"deployer-zitadel-vps",{"fr":10,"en":12,"ar":13,"es":14},"self-host-zitadel-vps-open-source-iam-developers","zitadel-vps-iam-maftouh-almassdar-lilmutatawireen","instalar-zitadel-vps-iam-codigo-abierto-desarrolladores","ZITADEL sur VPS : IAM open source pour développeurs","Déployez ZITADEL en self-hosted sur VPS : OIDC, OAuth 2.0, passkeys et multi-tenant natif avec Docker Compose en moins de 5 minutes.",11,0,false,"2026-01-08T00:00:00+00:00","2026-11-04T16:30:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdeployer-zitadel-vps-poster.svg",{"categorySlug":34,"appSlug":35},"security","zitadel","ZITADEL est une plateforme IAM open source écrite en Go : SSO OIDC\u002FOAuth 2.0, passkeys et multi-tenant natif, en self-hosted. Ce guide la déploie sur un VPS ServOrbit avec Docker Compose, corrige les chiffres que l'ancienne version répétait sans source, et documente ce qui ne marche pas encore : la découverte de domaine (Domain Discovery), ouverte en bug sur la v4 depuis septembre 2025. Guide fourni, sans prise en charge.",[38,41,44,46,55,57,70,72,74,76,83,85,87,89,91,97,99,101,105,107,109,117,119,121,153,155,157,175,182,184,190,193,195],{"type":39,"title":40},"h2","Pourquoi choisir ZITADEL plutôt qu'Authentik ou Keycloak ?",{"type":42,"body":43},"p","ZITADEL occupe un créneau précis parmi les plateformes d'authentification open source. Contrairement à **Authelia** (proxy d'authentification sans gestion d'utilisateurs propre) ou **Authentik** (IdP full-stack riche en fonctionnalités), il vise les équipes de développement qui veulent un IAM de niveau entreprise dès le départ : multi-tenant natif, APIs gRPC + REST complètes, provider Terraform officiel (`zitadel\u002Fzitadel` sur le registre Terraform).\n\nSur la mémoire, restez prudent. La documentation d'exploitation indique que ZITADEL lui-même demande environ 512 Mo de RAM et moins d'un cœur CPU, base de données non comprise, avec des pics CPU au hachage des mots de passe. L'ancienne version de cet article annonçait « moins de 100 Mo » : ce chiffre ne figure pas dans la documentation, ne dimensionnez pas votre VPS dessus. Le comparatif de ressources avec Keycloak n'est pas chiffré ici faute de mesure sourcée.",{"type":39,"title":45},"Prérequis chiffrés",{"type":47,"items":48},"ul",[49,50,51,52,53,54],"**VPS** : 2 vCPU et 2 Go de RAM (le guide Docker Compose amont demande au moins 2 Go), Ubuntu 24.04. Prévoyez davantage dès que la base grossit : l'amont compte environ 4 Go de RAM par cœur de base de données.","**Docker** : Docker Engine 24 ou plus avec Compose v2 ; l'ancien binaire `docker-compose` (v1) n'est pas pris en charge.","**PostgreSQL** : les versions 14 à 18 sont prises en charge. Le template ServOrbit déploie PostgreSQL 16.","**Ports** : ZITADEL écoute en interne sur `8080`. Seul `443` doit être public (plus `80` si vous laissez Let's Encrypt émettre le certificat). Le template lie `8080` à `127.0.0.1` et laisse nginx servir l'extérieur.","**Domaine** : un nom ou sous-domaine pointant vers l'IP du VPS, par exemple `auth.votre-domaine.com`, en HTTPS.","**Masterkey** : `ZITADEL_MASTERKEY` doit faire exactement 32 caractères et ne peut plus changer après l'initialisation sans perdre l'accès aux données chiffrées. Le template la génère ; sauvegardez-la hors du VPS.",{"type":39,"title":56},"Installer ZITADEL depuis le Marketplace",{"type":58,"title":59,"steps":60},"steps","Installation en 3 étapes",[61,64,67],{"title":62,"body":63},"Créer le VPS","Depuis votre espace client ServOrbit, choisissez la gamme VPS et cliquez sur **Configurer**. Dans le champ Application, sélectionnez **ZITADEL**. Saisissez votre domaine (ex. `auth.votre-domaine.com`).\n\nSi vous n'avez pas de domaine, le sous-domaine gratuit ServOrbit est disponible immédiatement, HTTPS inclus.",{"title":65,"body":66},"Démarrage automatique","Le script d'installation génère le `MASTERKEY`, le mot de passe PostgreSQL et le mot de passe admin, puis lance PostgreSQL 16 et ZITADEL via Docker Compose. Durée habituelle : 2 à 4 minutes.",{"title":68,"body":69},"Accéder à la console","Une fois l'installation terminée, vos identifiants sont affichés dans l'espace client.\n- URL : `https:\u002F\u002F\u003Cvotre-domaine>\u002Fui\u002Fconsole`\n- Identifiant : `admin`. Si la page le refuse, essayez `admin@zitadel.\u003Cvotre-domaine>` : ZITADEL compose les noms de connexion sous la forme utilisateur@organisation.domaine, comme dans l'exemple `zitadel-admin@zitadel.localhost` de l'amont.\n- Mot de passe : celui qui a été généré\n\nConnectez-vous et changez-le immédiatement.",{"type":39,"title":71},"Ce que déploie le template",{"type":42,"body":73},"Le template est un fichier Docker Compose de deux services : `db` (PostgreSQL 16) et `zitadel`, lancé avec `start-from-init --tlsMode disabled --masterkeyFromEnv`. Le TLS est donc terminé par nginx, pas par ZITADEL. L'image suivie est le tag `stable` de `ghcr.io\u002Fzitadel\u002Fzitadel`, ce qui signifie que la version réellement démarrée dépend du jour où l'image a été tirée : contrôlez-la avec `docker compose images` (voir la section sur les mises à jour).\n\nLe domaine est transmis à `ZITADEL_EXTERNALDOMAIN`, avec `ZITADEL_EXTERNALPORT=443` et `ZITADEL_EXTERNALSECURE=true`. Le template considère le domaine comme figé au premier démarrage : choisissez le bon dès le départ.",{"type":39,"title":75},"Domaine externe, TLS et reverse proxy",{"type":47,"items":77},[78,79,80,81,82],"**Trois valeurs à aligner** — `ZITADEL_EXTERNALDOMAIN`, `ZITADEL_EXTERNALPORT` et `ZITADEL_EXTERNALSECURE` doivent décrire l'URL publique réelle. ZITADEL ne sert que les requêtes envoyées au protocole, à l'hôte et au port attendus ; sinon vous obtenez « Instance not found ».","**Changer de domaine** — l'amont documente que ces options peuvent être modifiées à tout moment, à condition de rejouer la phase de setup. Ce n'est donc pas impossible comme l'affirmait l'ancienne version, mais ce n'est pas un geste anodin : toute application cliente référence l'ancienne URL.","**Hôte conservé** — le reverse proxy doit transmettre l'en-tête `Host` d'origine et `X-Forwarded-Proto: https`. L'exemple nginx amont termine le TLS puis parle à ZITADEL en HTTP\u002F2 non chiffré (h2c) avec `grpc_pass`.","**HTTP\u002F2 de bout en bout** — la console exige HTTP\u002F2 jusqu'à ZITADEL. Les proxys testés par l'amont sont Traefik v3, NGINX 1.x stable, Caddy v2 et Apache httpd 2.4.","**CDN ou WAF devant** — la documentation précise qu'un proxy, un WAF ou un CDN placé devant ZITADEL doit lui aussi supporter HTTP\u002F2. Testez la console après toute bascule de DNS vers un mode proxifié.",{"type":39,"title":84},"Créer votre première application OIDC",{"type":42,"body":86},"Une fois connecté à la console ZITADEL :\n\n1. Allez dans **Projects** puis **Create**\n2. Nommez votre projet (ex. `My App`)\n3. Cliquez sur **Add Application**\n4. Choisissez le type : **Web** (applications serveur), **Native** (mobile\u002Fdesktop) ou **API** (machine-to-machine)\n5. Pour une app Web, choisissez **PKCE** (recommandé) et renseignez vos **Redirect URIs**\n\nZITADEL génère le **Client ID**. Notez le discovery endpoint OIDC : `https:\u002F\u002F\u003Cvotre-domaine>\u002F.well-known\u002Fopenid-configuration`.",{"type":39,"title":88},"Intégrer ZITADEL avec vos applications self-hosted",{"type":42,"body":90},"Toute application qui parle OIDC peut s'appuyer sur ZITADEL : il suffit du Client ID, du secret éventuel et du discovery endpoint. Exemples courants :",{"type":47,"items":92},[93,94,95,96],"**Gitea** : Administration du site, Authentification, ajouter une source OAuth2 de type OpenID Connect, puis saisir Client ID, secret et discovery endpoint","**Grafana** : section `[auth.generic_oauth]` de `grafana.ini` avec les URL d'autorisation, de jeton et d'informations utilisateur de ZITADEL","**Nextcloud** : application `Social Login` ou `OpenID Connect user backend`","**Toute autre application OIDC** : renseignez le discovery endpoint, le Client ID et les Redirect URIs déclarées dans le projet ; consultez la documentation de l'application pour les réglages exacts",{"type":39,"title":98},"Gérer le multi-tenant : organisations et projets",{"type":42,"body":100},"ZITADEL repose sur un modèle multi-tenant natif : vous créez plusieurs **Organisations** (par exemple une par client de votre SaaS), chacune avec ses utilisateurs et ses politiques de connexion. Chaque organisation peut avoir ses **Projets** et **Rôles**.\n\nAttention : les rôles ne sont pas inscrits dans les jetons automatiquement, contrairement à ce qu'affirmait l'ancienne version. Il faut cocher **Assert Roles on Authentication** dans le projet pour les obtenir via userinfo, ou **User Roles Inside ID Token** dans l'application, et demander le scope de rôles `urn:zitadel:iam:org:project:{projectId}:roles`. Ajoutez aussi `urn:zitadel:iam:org:project:id:{projectId}:aud` si vous obtenez « Invalid audience ».",{"type":102,"title":103,"body":104},"tip","Conseil : activer les passkeys dès le départ","Dans les paramètres de l'instance, activez l'authentification Passkey\u002FWebAuthn. Vos utilisateurs s'authentifient sans mot de passe depuis leur navigateur.",{"type":39,"title":106},"Découverte de domaine : ce qui doit fonctionner",{"type":42,"body":108},"La découverte de domaine (Domain Discovery) route un utilisateur vers la bonne organisation d'après le domaine de son adresse e-mail. Dans le scénario décrit par l'amont, un utilisateur de `alice@alpha.com` est redirigé vers le fournisseur d'identité de son entreprise, tandis qu'un utilisateur de `bob@beta.com` voit une page de connexion par mot de passe et MFA, et qu'un domaine inconnu tombe dans l'organisation par défaut.\n\nLes conditions décrites dans le guide amont sont les suivantes :",{"type":47,"items":110},[111,112,113,114,115,116],"**Instance** — dans Login Behavior and Security, l'option « Domain discovery allowed » est activée","**Organisation par défaut** — elle reçoit tous les utilisateurs sans correspondance","**Domaine vérifié** — chaque domaine est vérifié dans les Organization Domains de l'organisation, par enregistrement DNS TXT ou défi HTTP ; gardez l'enregistrement DNS, car ZITADEL revérifie périodiquement","**Politique de connexion de l'organisation** — « External IDP allowed » activé, et pour une organisation purement fédérée « Username Password allowed » désactivé","**Fournisseur d'identité** — configuré et rattaché à cette organisation ; avec un seul fournisseur la redirection est automatique, avec plusieurs l'utilisateur choisit","**Connexion par e-mail** — le nom de connexion saisi doit pouvoir être une adresse e-mail dont le domaine correspond",{"type":39,"title":118},"Limites connues : le ticket zitadel\u002Fzitadel n°10662",{"type":42,"body":120},"Sur ZITADEL v4.1.2 auto-hébergé, la découverte de domaine ne fonctionne pas pour certains déploiements malgré des organisations au domaine vérifié et un fournisseur d'identité configuré. Le ticket n°10662 (« Domain Discovery doesn't work ») a été ouvert en septembre 2025 et est toujours ouvert à la rédaction de cet article. Le tableau sépare ce que l'équipe ou la documentation établit de ce que des utilisateurs rapportent.",{"type":122,"title":123,"headers":124,"rows":128},"comparison","Ticket n°10662 : confirmé et rapporté",[125,126,127],"Point","Confirmé (équipe ou documentation)","Rapporté par des utilisateurs, non confirmé",[129,133,137,141,145,149],[130,131,132],"Symptôme","Le ticket est ouvert, classé priorité moyenne en octobre 2026, avec les étiquettes area\u002Fconsole, area\u002FloginV1 et ng-v4-legacy","Message « User not found in the system » pour une adresse au domaine vérifié, sur v4.1.2, identique sous OKD et sous Docker",[134,135,136],"Correctif annoncé","Un mainteneur a indiqué en octobre 2025 que la PR n°10729 le corrigeait, puis le ticket a été rouvert","Le défaut persiste sur v4.3.1, puis en Login V1 sur v4.5.0, v4.6.3, v4.7.0 et v4.11.0",[138,139,140],"Cause","Aucune cause n'est établie publiquement","Aucune hypothèse vérifiée",[142,143,144],"Périmètre","Des sous-tickets existent (état du 16 juillet 2026 : un terminé, deux en cours, un non démarré), rattachés au chantier parent n°12337","Reproduit en Login V2 (rapport initial) puis en Login V1 ; le cas de plusieurs domaines dans une même organisation reste sans réponse",[146,147,148],"Console","Le 27 juillet 2026, une contributrice indique que la Console doit être dépréciée dans les 12 mois et qu'aucun correctif n'est priorisé d'ici là ; le ticket est maintenu ouvert","Rien à signaler",[150,151,152],"Contournement","Aucun contournement n'est documenté dans le fil","Aucun n'est éprouvé par les participants",{"type":42,"body":154},"En pratique : ne bâtissez pas une architecture SSO d'entreprise sur la seule découverte de domaine tant que ce ticket est ouvert. Prévoyez un second chemin (lien de connexion par fournisseur, voir plus bas) et testez le routage avec un utilisateur réel avant la mise en production. Le 27 octobre 2026, un membre de l'équipe a demandé la vérification de l'état du ticket : suivez-le plutôt que cet article pour son issue.",{"type":39,"title":156},"Dépannage de la connexion SSO et du domaine vérifié",{"type":58,"title":158,"steps":159},"Diagnostic en 5 étapes",[160,163,166,169,172],{"title":161,"body":162},"Contrôler l'instance","Dans les paramètres de l'instance, section Login Behavior and Security, vérifiez que « Domain discovery allowed » est bien activé. Sans lui, aucune règle d'organisation n'est consultée.",{"title":164,"body":165},"Contrôler le domaine","Dans l'organisation visée, ouvrez les Organization Domains : le domaine doit être au statut vérifié. Si la vérification échoue, rétablissez l'enregistrement TXT ou le défi HTTP demandé, et ne supprimez jamais l'enregistrement après coup.",{"title":167,"body":168},"Contrôler la politique de connexion","Dans la même organisation, « External IDP allowed » doit être activé et le fournisseur d'identité actif. Si « Username Password allowed » reste activé, l'utilisateur peut atterrir sur la saisie du mot de passe au lieu d'être redirigé, symptôme décrit dans le ticket.",{"title":170,"body":171},"Tester le nom de connexion","En navigation privée, saisissez une adresse complète dont le domaine est exactement celui qui est vérifié. Une faute de domaine, un sous-domaine ou un utilisateur déjà existant dans une autre organisation changent le résultat.",{"title":173,"body":174},"Court-circuiter la découverte","Si tout est conforme et que « User not found in the system » persiste, vous êtes probablement dans le cas du ticket n°10662. Le scope `urn:zitadel:iam:org:idp:id:\u003Cidp_id>` redirige directement l'utilisateur vers le fournisseur d'identité choisi : la documentation le décrit, mais il n'a pas été éprouvé sur ce défaut.",{"type":47,"items":176},[177,178,179,180,181],"**« User not found in the system »** : appliquez les cinq étapes ci-dessus ; si elles sont conformes, c'est le défaut du ticket","**« Instance not found » (404)** : le couple hôte, port et protocole reçu ne correspond pas à `ZITADEL_EXTERNALDOMAIN`, `ZITADEL_EXTERNALPORT` et `ZITADEL_EXTERNALSECURE` ; vérifiez que nginx conserve l'en-tête `Host`","**Console blanche ou appels API en échec derrière un proxy ou un CDN** : contrôlez HTTP\u002F2 de bout en bout","**Identifiant `admin` refusé** : essayez la forme `admin@zitadel.\u003Cvotre-domaine>` indiquée plus haut","**Vérification de domaine qui échoue** : le guide amont précise que le défi ACME de vérification peut être désactivé dans les réglages par défaut, mais ne le faites qu'en connaissance de cause",{"type":39,"title":183},"Mises à jour et sécurité",{"type":47,"items":185},[186,187,188,189],"**Version courante** — à la rédaction, la dernière version stable publiée est la v4.20.0, parue en octobre 2026 ; lisez les notes de version avant chaque montée","**Avis GHSA-jh92-5mrj-p2w2** — prise de contrôle de compte par des identifiants de session prévisibles dans le Login V2 (sévérité haute, aucun identifiant CVE indiqué). Versions 4.0.0 à 4.19.1 touchées, correctif en 4.19.2 ; un déploiement qui n'utilise que le Login V1 n'est pas concerné","**Secret de cookie de session** — le correctif demande `ZITADEL_SESSION_COOKIE_SECRET` (32 caractères au moins, identique sur tous les réplicas) ; les utilisateurs doivent se reconnecter après la montée","**Branche 3.x** — elle est arrivée en fin de vie le 31 août 2026 et ne recevra pas de correctif : migrez vers une 4.x récente",{"type":102,"title":191,"body":192},"Avant de mettre à jour","Sauvegardez la base avec `pg_dump` et la masterkey, puis lancez `docker compose pull` suivi de `docker compose up -d` depuis le dossier du Compose. Comme le template suit le tag `stable`, vérifiez ensuite la version démarrée avec `docker compose images`.",{"type":39,"title":194},"Installer ZITADEL via le Marketplace ServOrbit",{"type":42,"body":196},"Vous pouvez installer ZITADEL directement depuis le [Marketplace ServOrbit](\u002Fapplications\u002Fsecurity\u002Fzitadel) : VPS préconfiguré avec Docker Compose, nginx, HTTPS et secrets générés automatiquement. Le template est fourni comme point de départ, sans prise en charge de votre configuration d'identité.","Déployer ZITADEL sur votre VPS","IAM open source, OIDC\u002FOAuth 2.0, passkeys et multi-tenant natif — pré-configuré avec Docker Compose et HTTPS inclus.","Déployer ZITADEL","\u002Fapplications\u002Fcybersecurity\u002Fzitadel",[202,225],{"id":203,"slug":204,"slugs":205,"title":209,"excerpt":210,"readTime":211,"views":18,"isPinned":19,"noindex":19,"publishedAt":212,"updatedAt":213,"category":214,"categories":219,"featuredImage":30,"bgImage":31,"posterImage":221,"relatedSolution":222},112,"keycloak-sso-vps",{"fr":204,"en":206,"ar":207,"es":208},"deploy-keycloak-for-sso-on-your-vps","نشر-keycloak-لتسجيل-الدخول-الموحد-sso-على-خادمك-vps","desplegar-keycloak-sso-en-un-vps","Déployer Keycloak pour le SSO sur votre VPS","Déployez Keycloak sur votre VPS pour un SSO de niveau entreprise : OIDC, SAML, realms et fédération. Guide Docker complet et comparatif.",10,"2026-02-28T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":215,"name":216,"slug":217,"color":218,"icon":34},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400",[220],{"id":215,"name":216,"slug":217,"color":218,"icon":34},"\u002Fblog\u002Fcovers\u002Fkeycloak-sso-vps-poster.svg",{"categorySlug":223,"appSlug":224},"cybersecurity","keycloak",{"id":226,"slug":227,"slugs":228,"title":232,"excerpt":233,"readTime":234,"views":235,"isPinned":19,"noindex":19,"publishedAt":236,"updatedAt":21,"category":237,"categories":238,"featuredImage":30,"bgImage":31,"posterImage":240,"relatedSolution":241},272,"authentik-vs-authelia-keycloak-sso-vps-2026",{"fr":227,"en":229,"ar":230,"es":231},"authentik-authelia-or-keycloak-choosing-your-sso-on-vps","authentik-أو-authelia-أو-keycloak-اختيار-sso-على-vps","authentik-authelia-o-keycloak-elegir-sso-en-vps","Authentik, Authelia ou Keycloak : choisir son SSO sur VPS","Authentik, Authelia ou Keycloak sur VPS : comparez l'empreinte mémoire réelle, les protocoles couverts et les CVE de Keycloak 26.7.1 pour choisir le bon SSO self-hosted.",6,3,"2026-08-16T00:00:00+00:00",{"id":215,"name":216,"slug":217,"color":218,"icon":34},[239],{"id":215,"name":216,"slug":217,"color":218,"icon":34},"\u002Fblog\u002Fcovers\u002Fauthentik-vs-authelia-keycloak-sso-vps-2026-poster.svg",{"categorySlug":223,"appSlug":242},"authentik",true,1794270701962]