[{"data":1,"prerenderedAt":235},["ShallowReactive",2],{"seo-verification":3,"blog-zitadel-sso-self-hosted-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-zitadel-sso-self-hosted-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":30,"ctaBody":30,"ctaButton":153,"ctaUrl":154,"relatedPosts":155},435,"zitadel-sso-self-hosted-vps",{"fr":10,"en":12,"ar":13,"es":14},"self-hosting-zitadel-vps-multi-tenant-sso","استضافة-zitadel-على-vps-sso-متعدد-المستأجرين","zitadel-vps-sso-multi-tenant-sin-keycloak","Héberger ZITADEL sur un VPS : SSO multi-tenant sans Keycloak","Déployez ZITADEL sur votre VPS avec Docker Compose : IAM cloud-native en Go, multi-tenant natif, OIDC, OAuth2, SAML et Passkeys — sans la lourdeur de Keycloak.",14,0,false,"2026-10-12T00:00:00+00:00","2026-10-13T14:10:28+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fzitadel-sso-self-hosted-vps-poster.svg",{"categorySlug":34,"appSlug":35},"cybersecurity","zitadel","ZITADEL est un fournisseur d'identité cloud-native écrit en Go, conçu dès l'origine pour les équipes B2B qui gèrent plusieurs clients ou plusieurs projets distincts. Là où Keycloak demande de configurer un realm par tenant — avec tout le risque de dérive de configuration que cela implique — et où Authentik traite le multi-tenant comme une fonctionnalité additionnelle, ZITADEL place les organisations et les projets au cœur de son modèle de données. Chaque tenant dispose de ses propres utilisateurs, ses propres règles d'authentification et ses propres applications, sans jamais interférer avec les voisins.\n\nSon empreinte mémoire est celle d'un binaire Go — 150 à 300 Mo pour la stack complète avec PostgreSQL, contre 512 Mo à 1 Go de JVM pour Keycloak au repos. Il supporte OIDC, OAuth2, SAML 2.0, LDAP et les Passkeys WebAuthn depuis la version 2.x, avec une API gRPC\u002FREST qui permet d'automatiser la gestion des tenants sans jamais toucher à une interface graphique.",[38,42,54,57,91,94,97,143,147,150],{"type":39,"title":40,"body":41},"h2","ZITADEL vs Keycloak vs Authentik : lequel choisir pour un B2B SaaS","La question revient systématiquement dès qu'une agence ou un développeur SaaS cherche à centraliser l'authentification de plusieurs clients : faut-il rester sur Keycloak, passer à Authentik, ou regarder ZITADEL ?\n\nKeycloak est le standard historique, riche en fonctionnalités et supporté par Red Hat. Il couvre OIDC, SAML, LDAP, Kerberos, WebAuthn et dispose d'une documentation exhaustive. Son problème pour un VPS self-hosted : la JVM. Au repos, Keycloak consomme entre 512 Mo et 1 Go de RAM, et chaque realm est une arborescence de configuration distincte à maintenir. La semaine 38 de 2026 a illustré le risque : six CVEs corrigées en deux releases consécutives, dont deux DoS non authentifiés sur les endpoints SAML et de login.\n\nAuthentik (2026.8.2) est le choix naturel pour les équipes qui veulent un IdP complet avec une interface graphique, des flux visuels et du provisionnement SCIM. Il est écrit en Python\u002FDjango avec un frontend TypeScript, et sa stack complète demande au moins 1 Go de RAM utilisable. Le multi-tenant existe, mais s'implémente via des tenants séparés ou des groupes — pas via un modèle de données dédié.\n\nZITADEL (v2.x, Go) est le seul des trois à avoir conçu le multi-tenant comme primitif de première classe. Une installation unique expose des organisations indépendantes — chacune avec ses utilisateurs, ses IdP externes, ses politiques de mot de passe et ses applications. Pour une agence qui héberge dix clients sur un seul VPS, c'est la différence entre dix fichiers de configuration Keycloak et une API qui orchestre tout.",{"type":43,"title":44,"items":45},"ul","Pourquoi ZITADEL se distingue pour un usage agence ou B2B SaaS",[46,47,48,49,50,51,52,53],"**Multi-tenant natif** : organisations et projets sont des primitives du modèle de données, pas des contournements — chaque client obtient son espace isolé sans duplication de configuration","**Écrit en Go** : binaire unique, démarrage en quelques secondes, empreinte mémoire de 150 à 300 Mo stack complète contre 512 Mo à 1 Go de JVM pour Keycloak","**OIDC, OAuth2, SAML 2.0 et LDAP** : tous les protocoles d'entreprise en une seule installation — pas besoin d'ajouter des extensions comme sur Keycloak","**Passkeys et WebAuthn natifs dès v2** : chaque organisation peut imposer des Passkeys comme seul facteur d'authentification, sans plugin ni configuration avancée","**API-first gRPC\u002FREST** : toute opération disponible dans la console l'est aussi via l'API — provisionner un tenant, créer une application OIDC, ou réinitialiser un MFA se script en quelques lignes","**Actions (webhooks\u002Fcode)** : logique personnalisée déclenchée lors des événements d'authentification (pre\u002Fpost-auth, post-register) sans modifier le core","**Déploiement sans état applicatif** : ZITADEL stocke tout dans PostgreSQL — pas de cache distribué, pas de volume supplémentaire, la scalabilité horizontale se réduit à démarrer une seconde instance","**Licence Apache 2.0** : le cœur est entièrement open source, sans fonctionnalité critique cachée derrière une licence Enterprise",{"type":39,"title":55,"body":56},"Prérequis : serveur, Docker et DNS","ZITADEL est raisonnable en ressources pour un fournisseur d'identité de cette envergure. La configuration minimale recommandée par l'équipe pour un déploiement de production est **2 vCPU et 4 Go de RAM** — dont environ 300 Mo seront utilisés par ZITADEL lui-même, le reste revenant à PostgreSQL et aux autres services de votre stack.\n\nEn pratique, sur un VPS dédié avec 4 Go de RAM, ZITADEL + PostgreSQL laissent largement de la place pour un reverse proxy nginx, un service de notification et quelques applications. Pour des tests ou un déploiement de développement, 2 Go suffisent.\n\n**Logiciels requis :** Docker Engine 24+ et Docker Compose v2. Les ports 80 et 443 doivent être ouverts (nginx terminera le TLS). Un nom de domaine pointé vers l'IP de votre VPS — ZITADEL exige un FQDN même en développement, car les cookies OIDC sont liés au domaine. Si vous n'avez pas encore de certificat TLS, Let's Encrypt avec Certbot ou le plugin nginx suffisent.\n\n**Base de données :** PostgreSQL 15 ou 16. ZITADEL supporte aussi CockroachDB pour les déploiements hautement disponibles, mais sur un VPS single-node, PostgreSQL est le choix naturel. La base doit être accessible depuis le conteneur ZITADEL — le réseau Docker bridge par défaut convient.\n\n**Stockage :** ZITADEL ne stocke pas de fichiers sur disque (hors logs) — pas de volume de données dédié au-delà du volume PostgreSQL. Prévoir 10 Go pour la base de données en conditions normales d'utilisation.",{"type":58,"title":59,"steps":60},"steps","Déployer ZITADEL avec Docker Compose et PostgreSQL",[61,64,67,70,73,76,79,82,85,88],{"title":62,"body":63},"Créer l'arborescence de travail","Connectez-vous à votre VPS en SSH et créez les répertoires nécessaires :\n```bash\nmkdir -p \u002Fopt\u002Fzitadel\u002F{config,certs}\ncd \u002Fopt\u002Fzitadel\n```\nTous les fichiers de configuration et les secrets résideront ici.",{"title":65,"body":66},"Créer le fichier .env avec les secrets","Générez des secrets forts avant de les inscrire dans `.env` :\n```bash\ncat > \u002Fopt\u002Fzitadel\u002F.env \u003C\u003CEOF\nPOSTGRES_PASSWORD=$(openssl rand -base64 32 | tr -d '\\n')\nZITADEL_MASTERKEY=$(openssl rand -base64 32 | tr -d '\\n' | head -c 32)\nZITADEL_DOMAIN=sso.votre-domaine.com\nEOF\n```\nLe `MASTERKEY` doit faire exactement 32 caractères — ZITADEL refuse de démarrer sans cela.",{"title":68,"body":69},"Écrire le docker-compose.yml","Créez `\u002Fopt\u002Fzitadel\u002Fdocker-compose.yml` :\n```yaml\nservices:\n  db:\n    image: postgres:16-alpine\n    restart: unless-stopped\n    environment:\n      POSTGRES_USER: zitadel\n      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}\n      POSTGRES_DB: zitadel\n    volumes:\n      - pgdata:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata\n    healthcheck:\n      test: [\"CMD-SHELL\", \"pg_isready -U zitadel\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n\n  zitadel:\n    image: ghcr.io\u002Fzitadel\u002Fzitadel:stable\n    restart: unless-stopped\n    command: start-from-init --masterkey \"${ZITADEL_MASTERKEY}\" --tlsMode disabled\n    environment:\n      ZITADEL_DATABASE_POSTGRES_HOST: db\n      ZITADEL_DATABASE_POSTGRES_PORT: 5432\n      ZITADEL_DATABASE_POSTGRES_DATABASE: zitadel\n      ZITADEL_DATABASE_POSTGRES_USER_USERNAME: zitadel\n      ZITADEL_DATABASE_POSTGRES_USER_PASSWORD: ${POSTGRES_PASSWORD}\n      ZITADEL_DATABASE_POSTGRES_USER_SSL_MODE: disable\n      ZITADEL_DATABASE_POSTGRES_ADMIN_USERNAME: zitadel\n      ZITADEL_DATABASE_POSTGRES_ADMIN_PASSWORD: ${POSTGRES_PASSWORD}\n      ZITADEL_DATABASE_POSTGRES_ADMIN_SSL_MODE: disable\n      ZITADEL_EXTERNALSECURE: \"true\"\n      ZITADEL_EXTERNALDOMAIN: ${ZITADEL_DOMAIN}\n      ZITADEL_EXTERNALPORT: 443\n    depends_on:\n      db:\n        condition: service_healthy\n    ports:\n      - \"8080:8080\"\n\nvolumes:\n  pgdata:\n```\nLe flag `--tlsMode disabled` délègue le TLS à nginx. ZITADEL écoute en HTTP sur le port 8080 en interne, nginx termine le TLS en amont.",{"title":71,"body":72},"Configurer nginx comme reverse proxy TLS","Créez `\u002Fetc\u002Fnginx\u002Fsites-available\u002Fzitadel` :\n```nginx\nserver {\n    listen 80;\n    server_name sso.votre-domaine.com;\n    return 301 https:\u002F\u002F$host$request_uri;\n}\n\nserver {\n    listen 443 ssl http2;\n    server_name sso.votre-domaine.com;\n\n    ssl_certificate \u002Fetc\u002Fletsencrypt\u002Flive\u002Fsso.votre-domaine.com\u002Ffullchain.pem;\n    ssl_certificate_key \u002Fetc\u002Fletsencrypt\u002Flive\u002Fsso.votre-domaine.com\u002Fprivkey.pem;\n\n    # ZITADEL utilise gRPC-Web — http2 est requis\n    location \u002F {\n        grpc_pass grpc:\u002F\u002F127.0.0.1:8080;\n        proxy_pass http:\u002F\u002F127.0.0.1:8080;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-Proto https;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n    }\n}\n```\nActivez le site et obtenez le certificat :\n```bash\nln -s \u002Fetc\u002Fnginx\u002Fsites-available\u002Fzitadel \u002Fetc\u002Fnginx\u002Fsites-enabled\u002F\ncertbot --nginx -d sso.votre-domaine.com\nnginx -t && systemctl reload nginx\n```",{"title":74,"body":75},"Démarrer la stack ZITADEL","```bash\ncd \u002Fopt\u002Fzitadel\ndocker compose up -d\ndocker compose logs -f zitadel\n```\nLe premier démarrage (`start-from-init`) initialise la base de données, applique les migrations et crée l'organisation par défaut. Attendez le message `server is listening on [::]:8080` dans les logs — cela prend généralement 30 à 60 secondes.",{"title":77,"body":78},"Récupérer les credentials admin initiaux","Lors du premier démarrage avec `start-from-init`, ZITADEL génère un compte admin et un fichier de clé de service. Récupérez-les avec :\n```bash\ndocker compose logs zitadel 2>&1 | grep -A 5 'initial'\n```\nLes credentials s'affichent une seule fois dans les logs. Notez le login et le mot de passe — ils ne peuvent pas être récupérés après. Si vous les perdez, relancez avec `start-from-init` après avoir vidé la base.",{"title":80,"body":81},"Se connecter à la console d'administration","Ouvrez `https:\u002F\u002Fsso.votre-domaine.com\u002Fui\u002Fconsole` dans un navigateur. Connectez-vous avec les credentials récupérés à l'étape précédente. Vous arrivez sur le tableau de bord de l'organisation par défaut — c'est votre organisation principale (votre propre compte ou votre agence). Depuis ici, vous pouvez créer des organisations clients, des projets et des applications OIDC.",{"title":83,"body":84},"Créer votre première organisation client","Dans la console, allez dans **Organisation → Nouvelle organisation**. Donnez-lui le nom de votre client (ex. `client-acme`). ZITADEL crée automatiquement un espace isolé : les utilisateurs de cette organisation ne voient pas ceux des autres, et les politiques de mot de passe peuvent être différentes. Vous pouvez ensuite inviter un administrateur de l'organisation client — il aura accès uniquement à son espace.",{"title":86,"body":87},"Créer un projet et une application OIDC","Dans l'organisation, allez dans **Projets → Nouveau projet**. Un projet regroupe une ou plusieurs applications. Créez ensuite une **Application web** de type **OIDC**. ZITADEL vous demande le type de client (Web, SPA, Native) et les URLs de redirection. Il génère un `Client ID` et un `Client Secret`. Notez le Discovery URL : `https:\u002F\u002Fsso.votre-domaine.com\u002F.well-known\u002Fopenid-configuration` — toutes vos applications configurées en OIDC pointent vers cet endpoint.",{"title":89,"body":90},"Vérifier l'état et activer les mises à jour automatiques","Vérifiez que tout fonctionne :\n```bash\ncurl -s https:\u002F\u002Fsso.votre-domaine.com\u002Fhealthz | jq .\n```\nUne réponse `{\"status\": \"pass\"}` confirme que ZITADEL répond correctement. Pour les mises à jour, remplacez le tag `stable` par le numéro de version exact dans `docker-compose.yml` et fixez-le — `stable` suit le dernier release, ce qui peut introduire des changements non planifiés en production.",{"type":39,"title":92,"body":93},"Configurer l'authentification OIDC pour vos applications","Une fois ZITADEL démarré et une application OIDC créée, la configuration côté application est standard — n'importe quelle bibliothèque OIDC (passport.js, next-auth, python-oidc, etc.) fonctionne sans adaptation spécifique à ZITADEL.\n\nLes paramètres OIDC essentiels à fournir à votre application :\n\n```\nISSUER=https:\u002F\u002Fsso.votre-domaine.com\nCLIENT_ID=\u003Cclient_id_généré>\nCLIENT_SECRET=\u003Cclient_secret_généré>  # seulement pour les apps Web (pas les SPAs)\nREDIRECT_URI=https:\u002F\u002Fvotre-app.com\u002Fcallback\nSCOPES=openid profile email\n```\n\nLe Discovery Document est disponible à `https:\u002F\u002Fsso.votre-domaine.com\u002F.well-known\u002Fopenid-configuration`. Il expose automatiquement tous les endpoints : `authorization_endpoint`, `token_endpoint`, `userinfo_endpoint`, `jwks_uri`. La plupart des bibliothèques OIDC modernes peuvent se configurer depuis ce seul URL de découverte.\n\n**Exemple avec next-auth (Next.js) :**\n```js\n\u002F\u002F pages\u002Fapi\u002Fauth\u002F[...nextauth].js\nimport NextAuth from 'next-auth'\n\nexport default NextAuth({\n  providers: [\n    {\n      id: 'zitadel',\n      name: 'ZITADEL',\n      type: 'oauth',\n      wellKnown: 'https:\u002F\u002Fsso.votre-domaine.com\u002F.well-known\u002Fopenid-configuration',\n      clientId: process.env.ZITADEL_CLIENT_ID,\n      clientSecret: process.env.ZITADEL_CLIENT_SECRET,\n      authorization: { params: { scope: 'openid profile email' } },\n      idToken: true,\n      checks: ['pkce', 'state'],\n      profile(profile) {\n        return { id: profile.sub, name: profile.name, email: profile.email }\n      }\n    }\n  ]\n})\n```\n\nPour une SPA (React, Vue), utilisez le flow PKCE sans secret côté client. ZITADEL gère la rotation des codes PKCE nativement — pas de configuration supplémentaire requise.",{"type":39,"title":95,"body":96},"Modèle multi-tenant : organisations, projets et applications","Le modèle de données ZITADEL s'articule en trois niveaux qui correspondent exactement aux besoins d'une agence ou d'un SaaS B2B.\n\n**L'organisation** est le conteneur d'un tenant. Chaque organisation a ses propres utilisateurs, ses propres IdP externes (Google, GitHub, SAML d'entreprise) et ses propres politiques de complexité de mot de passe. Elle peut être administrée par un délégué de l'organisation — votre client — sans que cela lui donne accès aux autres organisations.\n\n**Le projet** regroupe les applications d'un même produit. Un projet peut contenir une application web, une application mobile et une API — toutes partageant les mêmes rôles et permissions, définis une seule fois au niveau du projet. Les tokens JWT émis par ZITADEL portent les rôles du projet dans le claim `urn:zitadel:iam:org:project:roles`.\n\n**L'application** représente un client OIDC, OAuth2 ou SAML spécifique. Elle définit les URLs de redirection, le type de client et les scopes autorisés.\n\nCe modèle permet à une agence de gérer dix clients sur une seule installation ZITADEL sans aucun risque de contamination entre tenants. Comparez avec Keycloak où chaque realm est une configuration complète à maintenir séparément, ou avec Authentik où le multi-tenant s'implémente via des tenants distincts partageant le même espace de noms.\n\n**Utiliser l'API pour automatiser** : ZITADEL expose une API gRPC\u002FREST complète. Créer une organisation et ses premières applications depuis un script d'onboarding prend une vingtaine de lignes :\n```bash\n# Créer une organisation via l'API REST\ncurl -X POST https:\u002F\u002Fsso.votre-domaine.com\u002Fv1\u002Forgs \\\n  -H 'Authorization: Bearer \u003Cadmin_token>' \\\n  -H 'Content-Type: application\u002Fjson' \\\n  -d '{\"name\": \"client-acme\", \"domain\": \"acme.example.com\"}'\n```\nL'API renvoie l'ID de l'organisation, que vous passez ensuite aux appels de création de projet et d'application.",{"type":98,"title":99,"headers":100,"rows":105},"comparison","ZITADEL vs Authentik vs Keycloak — comparatif technique",[101,102,103,104],"Critère","ZITADEL v2.x","Authentik 2026.8","Keycloak 26.7",[106,111,116,121,124,129,133,138],[107,108,109,110],"Langage \u002F runtime","Go — binaire unique","Python + Rust (frontend)","Java (JVM)",[112,113,114,115],"RAM stack complète (repos)","150 – 300 Mo","~1 Go (worker + PostgreSQL)","512 Mo – 1 Go (JVM seule)",[117,118,119,120],"Multi-tenant natif","Oui — Organisations primitives","Partiel — tenants séparés","Partiel — realms séparés",[122,123,123,123],"OIDC \u002F OAuth2 \u002F SAML","Oui — les trois natifs",[125,126,127,128],"Passkeys \u002F WebAuthn","Oui, natif v2","Oui (2026.2+)","Oui (v21+)",[130,131,132,132],"API-first","gRPC + REST, 100 % coverage","REST partielle",[134,135,136,137],"Interface admin","Console web + API","UI complète avec flux visuels","UI complète, configuration XML",[139,140,141,142],"Licence","Apache 2.0 (core)","MIT (Community) \u002F Enterprise","Apache 2.0",{"type":144,"title":145,"body":146},"tip","Activer les Passkeys et le MFA dans ZITADEL v2","ZITADEL v2 propose les Passkeys WebAuthn comme facteur d'authentification principal — pas seulement comme second facteur. Pour les activer dans une organisation :\n\n1. Dans la console, ouvrez **Organisation → Politique de sécurité → Politique MFA**.\n2. Activez **Passkeys** (WebAuthn sans mot de passe) et sélectionnez **Forcer** si vous souhaitez que tous les utilisateurs de cette organisation utilisent uniquement des Passkeys.\n3. Pour une politique plus souple : autorisez à la fois les Passkeys et le TOTP — l'utilisateur choisit lors de l'enrôlement.\n\nPour imposer le MFA par défaut à tous les nouveaux utilisateurs d'un projet :\n- Ouvrez le **Projet → Paramètres → Forcer le MFA** — cette option oblige chaque utilisateur de ce projet à enregistrer un second facteur avant d'accéder à l'application.\n\nLes Passkeys sont stockés côté navigateur (ou sur clé de sécurité FIDO2) et jamais transmis à ZITADEL — seule la preuve cryptographique est échangée. C'est particulièrement adapté aux applications B2B où les comptes partagés entre collègues sont courants : chaque appareil enregistre sa propre Passkey, sans mot de passe à partager.\n\n**TOTP avec Google Authenticator ou Bitwarden Authenticator** : ZITADEL génère un QR code standard — n'importe quelle application TOTP compatible RFC 6238 fonctionne. Pour les déploiements entreprise, ZITADEL supporte aussi les clés de sécurité U2F\u002FFIDO2 physiques (YubiKey, etc.).",{"type":39,"title":148,"body":149},"Dépannage : erreurs fréquentes avec ZITADEL sous Docker","**`masterkey must be 32 characters`** : le `ZITADEL_MASTERKEY` généré par `openssl rand -base64 32` produit une chaîne base64 d'une longueur variable selon le padding. Utilisez `head -c 32` pour tronquer à exactement 32 caractères, ou une commande qui génère directement 32 octets aléatoires en hexadécimal : `openssl rand -hex 16` (32 caractères hex = 16 octets).\n\n**`connection refused` sur le port 8080 alors que le conteneur tourne** : ZITADEL ne répond sur `:8080` que lorsque les migrations sont terminées — le `start-from-init` sur une base vide peut prendre 30 à 90 secondes. Attendez le log `server is listening on [::]:8080` avant de tester.\n\n**Boucle de redirection HTTP\u002FHTTPS** : ZITADEL génère ses redirects OAuth2 en HTTPS dès que `ZITADEL_EXTERNALSECURE=true`. Si nginx n'envoie pas correctement l'en-tête `X-Forwarded-Proto: https`, ZITADEL croit être derrière HTTP et génère des redirects cassés. Vérifiez que `proxy_set_header X-Forwarded-Proto https` est bien dans le bloc `location \u002F` de nginx.\n\n**`invalid_client` lors du flux OIDC** : vérifiez que l'URL de redirection déclarée dans l'application ZITADEL correspond exactement à celle envoyée par votre application — ZITADEL est strict sur la correspondance (pas de trailing slash, pas de paramètre supplémentaire). Activez les logs de débogage avec `ZITADEL_LOG_LEVEL=debug` pour voir le détail des validations.\n\n**PostgreSQL refuse la connexion** : le conteneur ZITADEL démarre avant que PostgreSQL soit prêt à accepter des connexions, même avec `depends_on: condition: service_healthy`. Si cela se produit, relancez simplement ZITADEL : `docker compose restart zitadel`. En production, utilisez une politique de restart (`restart: on-failure:5`) pour absorber les délais de démarrage.\n\n**Perte des credentials admin initiaux** : les credentials ne s'affichent qu'une seule fois au premier démarrage. Si vous les perdez, supprimez la base de données PostgreSQL (`docker compose down -v`) et relancez `start-from-init`. Sur un VPS de production, créez immédiatement un second compte admin et notez les credentials dans votre gestionnaire de secrets.",{"type":39,"title":151,"body":152},"Prochaine étape : approfondir votre stack SSO self-hosted","ZITADEL en production sur un VPS est un excellent premier pas. Pour aller plus loin :\n\n- **[Déployer ZITADEL sur VPS — guide avancé](\u002Fdeployer-zitadel-vps)** : certificats TLS automatiques avec Let's Encrypt, backup PostgreSQL avec pg_dump vers S3, et mise à jour sans downtime.\n- **[Authentik vs Authelia : quel SSO self-hosted pour votre VPS ?](\u002Fauthentik-vs-authelia-sso-self-hosted)** : si votre cas d'usage est moins orienté multi-tenant et plus orienté proxy d'authentification, la comparaison des deux alternatives les plus légères.\n- **[Migrer de Keycloak vers Authelia ou ZITADEL](\u002Fkeycloak-cves-semaine-38-migrer-authelia-zitadel-vps)** : les six CVEs de la semaine 38 analysées, et le chemin de migration concret depuis un realm Keycloak existant.\n- **[Héberger Authelia sur VPS](\u002Fself-host-authelia-vps)** : si vous cherchez une passerelle d'authentification ultra-légère (moins de 30 Mo) plutôt qu'un IdP complet, Authelia reste la référence.\n\nUn VPS avec 4 Go de RAM, accès root et IPv4 dédiée couvre confortablement ZITADEL en production avec de la marge pour les applications qu'il protège.","Voir les VPS Cloud","\u002Fvps-cloud",[156,178,200,218],{"id":157,"slug":158,"slugs":159,"title":163,"excerpt":164,"readTime":165,"views":18,"isPinned":19,"publishedAt":166,"updatedAt":167,"category":168,"categories":174,"featuredImage":30,"bgImage":31,"posterImage":176,"relatedSolution":177},351,"deployer-zitadel-vps",{"fr":158,"en":160,"ar":161,"es":162},"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.",3,"2026-01-08T00:00:00+00:00","2026-09-16T14:44:13+00:00",{"id":169,"name":170,"slug":171,"color":172,"icon":173},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[175],{"id":169,"name":170,"slug":171,"color":172,"icon":173},"\u002Fblog\u002Fcovers\u002Fdeployer-zitadel-vps-poster.svg",{"categorySlug":27,"appSlug":35},{"id":179,"slug":180,"slugs":181,"title":185,"excerpt":186,"readTime":187,"views":18,"isPinned":19,"publishedAt":188,"updatedAt":189,"category":190,"categories":195,"featuredImage":30,"bgImage":31,"posterImage":197,"relatedSolution":198},423,"authentik-vs-authelia-sso-self-hosted",{"fr":180,"en":182,"ar":183,"es":184},"authentik-vs-authelia-sso-comparison-vps","authentik-مقابل-authelia-sso-مستضاف-ذاتيا-vps","authentik-vs-authelia-sso-comparativa-vps","Authentik vs Authelia : quel SSO self-hosted pour votre VPS ?","Authentik ou Authelia pour votre SSO self-hosted ? Comparatif technique : protocoles OIDC\u002FSAML, empreinte RAM, architecture et cas d'usage pour choisir.",9,"2026-10-08T00:00:00+00:00","2026-10-08T23:30:51+00:00",{"id":191,"name":192,"slug":193,"color":194,"icon":193},5,"Comparatif","comparatif","bg-info\u002F10 text-info",[196],{"id":191,"name":192,"slug":193,"color":194,"icon":193},"\u002Fblog\u002Fcovers\u002Fauthentik-vs-authelia-sso-self-hosted-poster.svg",{"categorySlug":34,"appSlug":199},"authentik",{"id":201,"slug":202,"slugs":203,"title":207,"excerpt":208,"readTime":209,"views":18,"isPinned":19,"publishedAt":210,"updatedAt":211,"category":212,"categories":213,"featuredImage":30,"bgImage":31,"posterImage":215,"relatedSolution":216},372,"keycloak-cves-semaine-38-migrer-authelia-zitadel-vps",{"fr":202,"en":204,"ar":205,"es":206},"keycloak-cves-week-38-migrate-authelia-zitadel-vps","ثغرات-keycloak-الأسبوع-38-هجرة-إلى-authelia-zitadel","keycloak-cves-semana-38-migrar-authelia-zitadel-vps","Keycloak v26.7.4 : 6 CVEs — migrer vers Authelia ou ZITADEL","Keycloak v26.7.4 corrige 6 CVEs dont deux DoS non authentifiés. Pour moins de 10 apps SSO sur VPS, Authelia (\u003C 30 Mo) ou ZITADEL réduisent la surface.",12,"2026-09-23T00:00:00+00:00","2026-09-23T15:23:17+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[214],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fkeycloak-cves-semaine-38-migrer-authelia-zitadel-vps-poster.svg",{"categorySlug":34,"appSlug":217},"authelia",{"id":219,"slug":220,"slugs":221,"title":225,"excerpt":226,"readTime":227,"views":165,"isPinned":19,"publishedAt":228,"updatedAt":229,"category":230,"categories":231,"featuredImage":30,"bgImage":31,"posterImage":233,"relatedSolution":234},162,"self-host-authelia-vps",{"fr":220,"en":222,"ar":223,"es":224},"self-host-authelia-on-a-vps-mfa-and-sso-for-your-whole-stack","استضافة-authelia-على-vps-مصادقة-ثنائية-ودخول-موحد-لمنظومتك","alojar-authelia-en-un-vps","Héberger Authelia sur un VPS : MFA et SSO pour toute la stack","Déployer Authelia sur VPS avec Docker Compose : TOTP, WebAuthn\u002Fpasskey, OIDC, migration LLDAP, monitoring Prometheus et comparaison avec Authentik.",10,"2026-07-04T00:00:00+00:00","2026-09-24T12:27:51+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[232],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-authelia-vps-poster.svg",{"categorySlug":27,"appSlug":217},1791900996695]