Das beste selbst gehostete CIAM für B2B-SaaS-Entwickler

Wenn Sie sich die Preise einiger SaaS-CIAM-Plattformen angesehen haben, ist Ihnen vermutlich aufgefallen, wie teuer sie werden können, und Sie haben wahrscheinlich über eine selbst gehostete Lösung nachgedacht.

In diesem Artikel geht es um die vier selbst gehosteten CIAM-Plattformen, die ein kleines B2B-SaaS-Team tatsächlich betreiben kann, ohne dass daraus ein zweiter Vollzeitjob wird: ZITADEL, FusionAuth, Logto und Ory Hydra. Sie haben nicht alle dieselbe Form, und welche die richtige ist, hängt weniger von einer Feature-Checkliste ab als davon, welche Art von B2B-Produkt Sie bauen. Ich habe sie eine Woche lang nebeneinander auf einem einzigen VPS betrieben, um diesen Vergleich zusammenzustellen, und was folgt, ist die Fassung, die ich einem Gründer schicken würde, der mir wegen CIAM schreibt.

Eines vorweg: Es geht um CIAM als Produktfunktion, nicht um internes SSO für Ihr eigenes Team.

Die Kurzfassung

Vier selbst gehostete CIAM-Plattformen, je eine Zeile:

• ZITADEL wenn Sie Mandantenfähigkeit und B2B-Organisationen sofort einsatzbereit wollen.
• FusionAuth wenn Sie eine ausgefeilte Admin-Oberfläche und eine lange, planbare Release-Historie wollen.
• Logto wenn Sie die sauberste Entwicklererfahrung am ersten Tag wollen.
• Ory Hydra wenn Sie auf Protokollebene arbeiten und die OAuth-2.0-Engine wollen, keine vorgefertigte Login-App.

Unterm Strich: ZITADEL ist die sicherste erste Wahl für ein typisches B2B-SaaS, und der Rest des Artikels führt diese Begründung aus.

Warum CIAM eine andere Entscheidung ist als internes SSO

Wenn das SSO für Ihr internes Team ausfällt, bleibt der Schaden meist begrenzt. Ihre Entwickler verlieren vielleicht eine Stunde lang den Zugang zu Grafana oder einem anderen internen Werkzeug. Fällt das CIAM aus, können sich Ihre zahlenden Kunden überhaupt nicht mehr am Produkt anmelden. Damit verschiebt sich die Frage von „welches Auth-Tool ist für unser Team bequem?“ zu „welchem Auth-System können wir als Teil des Produkts selbst vertrauen?“

CIAM, also die Art von Identitätsinfrastruktur, die ein B2B-SaaS braucht, benötigt außerdem Primitive, die viele interne SSO-Werkzeuge nicht in den Vordergrund stellen. Ihr Kunde ist kein einzelner Nutzer, sondern eine Organisation (ein Tenant) mit eigenen Nutzern, Rollen, eigenem Branding und möglicherweise einer eigenen SAML-Verbindung zu einem Unternehmens-IdP. Sie authentifizieren nicht nur Menschen, sondern isolieren die Nutzer eines Unternehmens von denen eines anderen innerhalb desselben Produkts. Genau auf diese B2B-Form zielen die vier Werkzeuge unten, jedes auf seine Art. Keycloak hat inzwischen vollwertige Organizations, es als reines Workforce-Tool abzutun wäre also überholt; ich erkläre sein Fehlen in der FAQ.

Auch das Dreieck aus Bauen, Kaufen und Selbsthosten sieht hier anders aus. OAuth von Grund auf zu bauen ist ein vermeidbarer Fehler. Sie liefern ein SaaS-Produkt aus, keinen Identity Provider. Managed einzukaufen (Auth0, Clerk, WorkOS) ist die richtige Wahl, wenn Ihr Team keinerlei Ops-Kapazität und ein vernünftiges Budget hat. Einem Zwei-Personen-Startup würde ich nie raten, Auth am ersten Tag selbst zu hosten. Selbsthosten wird sinnvoll, sobald die MAU-Preise von managed CIAM die Kosten für Infrastruktur plus laufende Engineering-Zeit übersteigen, oder wenn Sie direkte Kontrolle über Deployment und Data Plane brauchen. In den Teams, mit denen ich gearbeitet habe, liegt dieser Punkt meist zwischen „wir haben ein echtes Produkt“ und „wir haben eine echte Customer-Success-Funktion“.

Wenn Sie SSO für Ihre eigenen Anwendungen suchen statt für die Ihrer Kunden, ist das ein anderer Vergleich als dieser. Weiter zu unseren Empfehlungen.

Die vier Werkzeuge, eines nach dem anderen

Ich habe diese vier gewählt, weil sie CIAM-förmig genug sind, um sie als Produktinfrastruktur zu bewerten und nicht nur als internes SSO. ZITADEL, FusionAuth, Logto und Ory bieten alle einen echten Self-Hosting-Weg und genug Zugkraft, um sie ernsthaft in Betracht zu ziehen. Reine Bibliotheken, Workforce-SSO-Lösungen und weniger ausgereifte Optionen sind in der FAQ besser aufgehoben.

ZITADEL

ZITADEL ist eine in der Schweiz entwickelte Identitätsplattform in Go, mit einer Event-Sourcing-Architektur und PostgreSQL als Backend. Stand 27. Juli 2026 ist das neueste GitHub-Release the 4.16 series, current as of July 2026. ZITADEL ist ab v3 von Apache 2.0 auf AGPL-3.0 gewechselt; für normale SaaS-Nutzung fällt die praktische Auswirkung meist weniger dramatisch aus, als es klingt, und ich gehe in der FAQ auf die Details ein.

Was ZITADEL für B2B-SaaS auszeichnet: Organisationen und Mandantenfähigkeit sind vollwertige Primitive, keine Funktionen, die Sie aus generischen Objekten zusammensetzen. Sie legen eine Organization an, sie erhält eigene Nutzer, Richtlinien, Branding und Zugriffseinstellungen, und Sie können ihr Projekte zuweisen, damit ihre Admins die Rollenvergabe für ihre eigenen Nutzer verwalten. Sie müssen das Konzept „Tenant“ nicht über generischen Nutzern erfinden. Sie fangen damit an.

Die Entwicklererfahrung ist API-first, mit den aktuellen v2-REST-Ressourcen-APIs sowie gRPC- und REST-Zugriff auf die alten v1-Dienste. Offizielle und Community-SDKs decken die gängigen Server-Stacks ab. Die Admin-Konsole ist funktional, aber schlichter als die von FusionAuth.

Meine Einschätzung: Wenn Sie ein B2B-SaaS bauen und wissen, dass Sie Tenants haben werden, würde ich mit ZITADEL anfangen. Unter den selbst gehosteten Optionen ist es die, die am deutlichsten um das B2B-Login-Problem herum gebaut ist.

FusionAuth

FusionAuth ist eine US-Plattform von Inversoft, LLC (eine LLC in Delaware, firmierend als FusionAuth), die länger am Markt ist als die anderen drei, und man merkt es im positiven Sinne. Die Admin-Oberfläche wirkt deutlich durchdachter als die der anderen, die Dokumentation ist ausgereift, und die Release-Kadenz ist stetig statt atemlos. Wenn Sie je eine vier Jahre alte Auth-Integration geerbt und dem vorherigen Entwickler still dafür gedankt haben, dass er die langweilige Option gewählt hat, dann ist FusionAuth genau die CIAM-Variante, die diesen Dank verdient.

Die Lizenzierung ist der Stolperstein: FusionAuth Community lässt sich kostenlos selbst hosten, das Kernprodukt ist aber nicht Open Source. Das Produkt unterliegt der eigenen Lizenz von FusionAuth, und diese Grenzen sind relevant, wenn Sie FusionAuth weitervertreiben, einbetten, umbenennen, weiterverkaufen oder für Ihre eigenen Kunden hosten wollen. Die selbst gehostete Community-Variante deckt den Kernfall eines B2B-SaaS ab; kostenpflichtige Pläne ergänzen Funktionen etwa IdP-initiiertes SAML, fortgeschrittene MFA und anwendungsspezifische Themes, während SCIM, Tenant Manager und MFA-Richtlinien auf Anwendungsebene in Enterprise liegen.

Zur B2B-Form: FusionAuth modelliert Tenants und Anwendungen, aber die Abstraktion ist eher „containerisierte Auth pro Tenant“ als „B2B-Organisationen als Domänenobjekt“. Es funktioniert (ich habe Produkte damit ausgeliefert), aber die Mandantenfähigkeit fühlt sich eher wie ein Isolationsprimitiv an als wie ein vollwertiges B2B-Modell. Die offiziellen SDKs und Client-Bibliotheken sind breit aufgestellt:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Die serverseitigen Bibliotheken sind schlanke API-Clients. Die Admin-Konsole lässt sich im Vergleich leichter an eine Ops-Person ohne Entwicklerhintergrund übergeben als die anderen.

Meine Einschätzung: Wenn Ihrem Team eine ausgefeilte Oberfläche und eine lange, planbare Historie wichtiger sind als B2B-native Primitive, dann FusionAuth. Es ist die „langweiligste“ Wahl hier, und das ist ein Kompliment.

Logto

Logto ist das jüngste der vier, entwickelt von Silverhand Inc. und unter MPL-2.0 lizenziert, und es ist dasjenige, dem sein Dashboard am sichtbarsten am Herzen liegt. Die Einrichtung am ersten Tag geht vergleichsweise schnell. Sie provisionieren, klicken sich durch den Assistenten und haben in rund fünfzehn Minuten einen funktionierenden OIDC-Provider mit einer ordentlichen Standard-Login-Oberfläche (ich habe es in der Woche gestoppt, in der ich alle vier parallel betrieben habe). Die offiziellen Quickstarts decken moderne Frameworks und Server-Stacks ab, wenn Ihr Stack also „Next.js + Postgres + irgendwas“ ist, fühlen Sie sich zu Hause.

Seine B2B-Antwort heißt Logto Organizations. Es deckt die zentralen B2B-Primitive ab: Organisationszugehörigkeit, auf die Organisation begrenzte Rollen, Mitgliedseinladungen, Just-in-time-Provisionierung und Enterprise-SSO-Integration. Das Organisationsmodell ist jünger als das von ZITADEL, daher würde ich jeden ungewöhnlichen SAML-, SCIM- oder Föderationsablauf mit Ihren Zielkunden testen, bevor Sie sich festlegen.

Der Kompromiss heißt Reife: Logto ist hier die jüngste Option. Die Roadmap bewegt sich schnell, was großartig ist, wenn eine benötigte Funktion kommt, und unangenehm, wenn ein Breaking Change kommt. Liegt Ihr B2B-SaaS am einfacheren Ende des Mandantenspektrums (wenige Organisationen und keine exotischen Föderationsanforderungen), macht die Entwicklererfahrung von Logto den Rest der Entscheidung leichter.

Meine Einschätzung: Wenn Sie den schnellsten ersten Tag wollen und Ihre B2B-Anforderungen noch relativ einfach sind, dann Logto.

Ory Hydra (und der Ory-Stack)

Ory Hydra ist der OAuth 2.0 / OpenID Connect Server aus dem Ory-Ökosystem, unter Apache-2.0 lizenziert. Der vollständige Ory-Stack kombiniert Hydra mit Ory Kratos (Identität und Benutzerverwaltung, Self-Service-Login, Registrierung, MFA und Kontowiederherstellung), Ory Keto (einem Autorisierungsserver im Zanzibar-Stil als Policy Decision Point) und Ory Oathkeeper (einem Identitäts- und Zugriffsproxy, der eingehende HTTP-Anfragen authentifiziert, autorisiert und verändert). Sie setzen zusammen, was Sie brauchen. Alles ist in Go geschrieben, und die APIs sind sauber.

Der Haken (und das ist kein Mangel, sondern für das richtige Team ein Vorteil) ist, dass Hydra die Engine ist und nicht die Anwendung. Von Haus aus verbindet sich Hydra mit einer separaten Login- und Consent-App , die Sie bereitstellen. Wenn Sie einen fertigen Login-Bildschirm wollen, ist das nicht das richtige Werkzeug. Wenn Sie etwas bauen, bei dem der Auth-Flow Teil Ihres Produkts ist (eine Entwicklerplattform, ein maßgeschneidertes B2B-Portal oder ein API-first-Produkt mit eigenem Onboarding), ist genau das Fehlen einer vorgegebenen Oberfläche das, was Sie wollen.

Die B2B-Geschichte ist komponierbar statt schlüsselfertig. Sie können Mandantenfähigkeit modellieren, indem Sie Kratos-Schemas und Keto-Relationen an Ihre eigene Organisationsebene anbinden, und das funktioniert, aber die Verkabelung machen Sie. Der Preis ist mehr Klempnerarbeit, der Nutzen ist Kontrolle über das Erlebnis. Die Dokumentation von Ory deckt die Protokolloberfläche tiefgehend ab, aber das komponierbare Modell setzt voraus, dass Sie Entscheidungen auf Protokollebene selbst treffen wollen. Wenn Ihnen „audience claim“ oder „PKCE“ nichts sagt, fangen Sie mit einem der anderen drei an.

Meine Einschätzung: Wenn Sie etwas auf Protokollebene bauen (Auth-Gateway, eigene Flows, Entwicklerplattform) und die Standardanwendungen einengend wirken, ist Ory die richtige Antwort. Für ein typisches B2B-SaaS, das heute ein funktionierendes Login will, ist es das nicht.

Der Vergleich auf einen Blick

Hier die Zusammenfassung der vier Werkzeuge in einer Tabelle, nützlich für den zweiten Durchgang, kein Ersatz für die Profile oben.

Mit welchem sollten Sie anfangen?

Vier kurze Szenarien, die die meisten Teams abdecken, mit denen ich darüber sprechen würde.

Sie bauen ein B2B-SaaS und wissen, dass Sie Tenants haben werden. Fangen Sie mit ZITADEL an. Die Primitive für Mandantenfähigkeit und Organisationen sind genau dafür gemacht, die API-Oberfläche ist umfassend, und Sie verbringen weniger Zeit damit, das Tenant-Modell zu erfinden, als bei den anderen drei. Der Wechsel zur AGPL verdient eine Lizenzprüfung, aber ein unverändertes, separat integriertes Deployment ist normalerweise ein unkomplizierter SaaS-Anwendungsfall.

Sie wollen die ausgefeilte Admin-Oberfläche und eine stabile, planbare Plattform. FusionAuth. Der Community-Plan deckt die Kernbedürfnisse vieler Teams ab; planen Sie Zeit ein, um Lizenz und Feature-Matrix gründlich zu lesen. Funktionen wie IdP-initiiertes SAML, fortgeschrittene MFA und anwendungsspezifische Themes erfordern einen kostenpflichtigen Plan, während SCIM, Tenant Manager und MFA-Richtlinien auf Anwendungsebene in Enterprise liegen.

Ihre B2B-Anforderungen sind heute einfach und Sie wollen den schnellsten ersten Tag. Logto. Seine Entwicklererfahrung am ersten Tag war in meinem Direktvergleich die schnellste. Akzeptieren Sie, dass Sie auf ein jüngeres Ökosystem setzen, und überdenken Sie die Wahl, wenn Ihre Anforderungen zu Föderations-Sonderfällen wachsen, die Sie nicht getestet haben.

Sie bauen etwas, bei dem Auth-Flows Teil des Produkterlebnisses sind. Ory Hydra (plus Kratos, plus Keto, wenn Sie Berechtigungen brauchen). Sie schreiben mehr Code. Sie haben mehr Kontrolle. Wenn Ihnen dieser Tausch nicht einleuchtet, sind Sie nicht die Zielgruppe von Ory. Nehmen Sie eines der anderen drei.

Wenn zwei dieser Beschreibungen auf Sie zutreffen, nehmen Sie standardmäßig ZITADEL. Es passt am breitesten und ist das, was ich einem kleinen Gründerteam ohne viele Rückfragen in die Hand geben würde.

Was Selbsthosting Sie kostet (im Betrieb)

Jetzt kommt der unromantische Teil des Artikels.

Ihre PostgreSQL-Backup-Disziplin ist jetzt etwas, wovon Ihr Geschäft abhängt. Über diese Deployments hinweg kann der zu schützende Identitätszustand Nutzerdatensätze, gehashte Zugangsdaten, MFA-Secrets, OAuth-Client-Credentials und Sitzungsdaten umfassen. Geht dieser Zustand verloren, können Ihre Kunden die Anmeldefähigkeit verlieren. Richten Sie automatische Backups ein, bevor sich Ihr erster echter Nutzer registriert, testen Sie die Wiederherstellung und legen Sie die Backup-Gesundheit in denselben Alarmkanal wie Ihre Anwendungsverfügbarkeit.

Das Release-Tempo ändert sich im Lauf der Zeit. ZITADEL v4.16.1 erschien am 17. Juli 2026 nach mehreren Juni-Releases, und jedes Projekt hier pflegt seine eigene Kadenz und Kompatibilitätspolitik. Behandeln Sie diese Kadenz als Wartungsthema, nicht als Abkürzung zur Qualitätsbeurteilung. Lesen Sie die Release Notes, bevor Sie docker compose pull ausführen, und planen Sie ein wiederkehrendes Patch-Fenster ein. Wer Updates des Identity Providers monatelang auslässt, hinkt bei der ersten echten Prüfung Sicherheits- und Kompatibilitätsfixes hinterher.

Die banalen Dinge, die einen immer einholen: TLS-Zertifikatserneuerung (nutzen Sie einen Reverse Proxy mit Let's Encrypt, automatisieren Sie die Erneuerung und alarmieren Sie bei Fehlern), die Konfiguration des ausgehenden Mailers für Verifizierungs- und Passwort-Reset-Mails (SES, SendGrid, Postmark: eines auswählen und SPF/DKIM/DMARC sauber konfigurieren, sonst landen Ihre Reset-Mails im Spam), das Rotieren von OAuth-Client-Credentials, wenn ein Entwickler geht, und Rate-Limiting der Login-Endpunkte, damit ein Credential-Stuffing-Angriff Ihre CPU nicht auslastet.

Profi-Tipp: Wenn Sie ein Managed Postgres nutzen, gehen Sie nicht davon aus, dass der Laufzeit-Datenbankbenutzer auch das Schema anlegen kann. Legen Sie Datenbank und Benutzer vorab an, vergeben Sie die nötigen Eigentums- oder Setup-Rechte, und führen Sie das erste Setup mit den Zugangsdaten aus, die das jeweilige Werkzeug erwartet. Sonst scheitert Ihr erster Lauf an einem vagen Datenbank-Berechtigungsfehler und Sie verbrennen eine Stunde mit der falschen Spur.

Was der Self-Hosting-Weg an Dollar spart, kostet er an Verantwortung. Planen Sie nach dem Setup ein paar Entwicklerstunden pro Monat ein, um die Identitätsschicht gesund zu halten. Teams, die null Zeit einplanen, entdecken die Kosten meist später: bei einem Ausfall, einem seltsamen SAML-Sonderfall oder ihrem ersten Sicherheitsaudit.

Wo Sie sie betreiben

Ein Linux-VPS mit Docker Compose kann ein vernünftiger Ausgangspunkt für Evaluierung und moderate Lasten sein, aber Produktionsdimensionierung und Hochverfügbarkeit hängen von Traffic, Sicherheitsanforderungen und Ihrer Ausfalltoleranz ab. So ordnen sich die gängigen Deployment-Optionen ein:

• Shared Hosting kann keines davon betreiben. Sie brauchen persistenten Speicher, eigene Ports, Root-Zugriff für die Container-Runtime und ein echtes Datenbank-Backend. PostgreSQL ist für die meisten dieser Liste der Standardweg, aber nicht buchstäblich die einzige unterstützte Datenbank für jedes Werkzeug.
• Kubernetes kann alle vier betreiben, aber der First-Party-Weg ist uneinheitlich. ZITADEL, FusionAuth, und Ory veröffentlichen eigene Helm-Charts, während die Self-Hosting-Dokumentation von Logto sich auf Docker- und VM-Deployment konzentriert. Für ein kleines B2B-SaaS, das den Punkt noch nicht erreicht hat, an dem sich Kubernetes anderswo bezahlt macht, ist das meist Over-Engineering. Greifen Sie dazu, wenn der Rest Ihrer Infrastruktur ohnehin schon dort läuft.
• Bare Metal ist in Ordnung, wenn Sie ohnehin schon darauf laufen. Die meisten B2B-SaaS-Teams tun das nicht.

Für einen kleinen Single-Node-Piloten würde ich mit 4 GB RAM, 2 vCPU und 60 GB NVMe-Speicher starten und dann den echten Login-Flow lasttesten. Das ist eine Planungsbasis, kein universelles Produktionsminimum. Die Anwendungen sind vergleichsweise leichtgewichtig, aber PostgreSQL braucht Speicher und Passwort-Hashing braucht CPU-Reserve. Die Produktionsempfehlungen von ZITADEL empfehlen, vier CPU-Kerne für Spitzen beim Passwort-Hashing bereitzuhalten.

Sobald das Produkt real ist und der Traffic anhält, dimensionieren Sie anhand von Messungen neu. Schneller Speicher hilft der PostgreSQL-Latenz, während CPU-Reserve beim gleichzeitigen Passwort-Hashing zählt. Beobachten Sie Speicher, Datenbank-I/O, Login-Latenz und CPU-Sättigung, statt anzunehmen, dass eine Ressource am wichtigsten ist.

CIAM in Produktion zu betreiben bedeutet, dass dessen Verfügbarkeit jetzt Ihr Problem ist. Wir betreiben Cloudzy Linux VPS Instanzen für diese Art von Workload, mit NVMe-Speicher und einem Verfügbarkeits-SLA von 99,95 % auf der zugrunde liegenden Plattform. Cloudzy bietet außerdem einen ZITADEL-VPS mit einem Klick falls Sie sich das anfängliche Provisionierungsskript sparen möchten; die anderen drei stellen offizielle Container-Images für ein Docker-basiertes Setup bereit. Für eine Management-Sicht darauf, wie Zugriffskontrolle in Ihre gesamte Sicherheitslage passt, deckt der Leitfaden zu IAM-Best-Practices das Thema von der Policy-Seite ab.

Häufig gestellte Fragen

Betrifft die AGPL-Lizenz von ZITADEL mein SaaS?

Bei einem unveränderten, separat integrierten Deployment normalerweise nicht, aber das ist keine Rechtsberatung. Die AGPL-Pflichten von ZITADEL gelten für ZITADEL selbst. Wenn Sie ZITADEL verändern und diese veränderte Fassung als Netzwerkdienst betreiben, kann die Lizenz verlangen, dass Sie den entsprechenden Quellcode unter AGPL anbieten. Die veröffentlichte Position von ZITADEL lautet, dass die bloße Nutzung einer unveränderten Instanz als Identitätsdienst Ihres SaaS für sich genommen nicht dazu verpflichtet, Ihre separate Anwendung unter AGPL zu lizenzieren. Lesen Sie die Lizenzankündigung von ZITADEL und holen Sie Rechtsrat ein, wenn Sie die Software verändern, weitergeben, einbetten oder Dritten anbieten. Eine kommerzielle Lizenz ist ebenfalls verfügbar.

Warum stehen Keycloak oder Authentik nicht auf dieser Liste?

Keycloak und Authentik sind ausgezeichnete selbst gehostete Identitätswerkzeuge (ich nutze sie), aber Keycloak auszuschließen, weil ihm B2B-Organisationen fehlen, wäre heute falsch: aktuelle Keycloak-Releases enthalten Organizations, Organisationsgruppen und delegierte Administrationssteuerung. Ich habe es weggelassen, weil dieser Vergleich sich auf vier Optionen mit einem direkteren Weg für kleine B2B-SaaS-Teams konzentriert; Keycloak verdient eine eigene Bewertung, wenn JVM-Betrieb, Ökosystemtiefe und Flexibilität auf Realm-Ebene zählen. Authentik passt weiterhin besser zu Workforce- und Intranet-SSO als zu produktnativer Tenant-Modellierung.

Ist Selbsthosting günstiger als Auth0?

Bei niedrigen MAU-Zahlen oft nicht. Ihre Entwicklerstunden kosten mehr als die Auth0-Rechnung auf der Early-Startup-Stufe. Selbsthosting gewinnt wirtschaftlich in der Größenordnung, in der die MAU-Preise von managed CIAM die Summe aus einem kleinen VPS und den paar Entwicklerstunden pro Monat übersteigen. Der genaue Break-even hängt vom Stundensatz Ihres Teams, Ihrer MAU-Wachstumskurve und davon ab, ob Ihr Produkt Enterprise-Funktionen braucht, die Sie in die teureren Auth0-Stufen drängen. Betrachten Sie die Ersparnis als real, aber nicht als sofortig.

Welche VPS-Größe ist das Minimum für ein produktives CIAM?

Für einen kleinen Single-Node-Piloten sind 4 GB RAM, 2 vCPU und NVMe-Speicher ein vernünftiger Ausgangspunkt, keine Produktionsgarantie. Dimensionieren Sie anhand Ihres Datenbankvolumens, der gleichzeitigen Login-Last, der Kosten des Passwort-Hashings und Ihres Verfügbarkeitsziels. Die Produktionsempfehlungen von ZITADEL raten dazu, vier CPU-Kerne für Hashing-Spitzen bereitzuhalten; andere Werkzeuge und Traffic-Muster brauchen eigene Lasttests.

Kann ich später von einem managed CIAM zu Selbsthosting migrieren?

Ja, aber planen Sie es als echtes Projekt. Passwort-Resets sind nicht zwangsläufig: Exportierbarkeit und unterstützte Hash-Formate unterscheiden sich, und manche Ziele unterstützen eine Massen- oder Just-in-time-Benutzermigration während andere ein Zurücksetzen erzwingen. MFA-Faktoren, OAuth-Clients, aktive Sitzungen, der E-Mail-Verifizierungsstatus sowie Tenant- oder Rollenzuordnungen brauchen eine gesonderte Behandlung. Wenn Sie schon ahnen, dass Sie später selbst hosten werden, halten Sie diese Export- und Migrationsbeschränkungen fest, bevor Sie den Managed-Anbieter auswählen.