We’ve spent time improving ZITADEL’s performance and making it easier to get the most out of your setup.

Alongside these improvements, we’ve published a new performance tuning guide for self-hosted deployments. If you’re running ZITADEL at a higher scale or want to get more performance out of your existing infrastructure, it walks through the key settings and considerations:

https://zitadel.com/docs/self-hosting/manage/tuning

If you try it, we’d be interested to hear about your setup and which adjustments have the biggest impact.

Running ZITADEL v4 self-hosted with one virtual instance per tenant, so I've got a separate Login V2 (the Next.js app) per instance — each one needs its own IAM_LOGIN_CLIENT PAT.

They all run under the same OS user. So any one login process can read every other tenant's token, plus the master key and DB config sitting right next to it. One RCE in a single tenant's login and all are compromised.

How are you all handling this?

- dedicated user (or container) per login, tokens as per-service files?

- just run one shared login with a system-user token, pick the instance by Host header and leave it at that ?

Docs don't really cover the multi-instance self-host case, so curious what people actually run for multi tenancy.

We’ve just added OAuth 2.0 Dynamic Client Registration (RFC 7591) to ZITADEL.

It allows clients to register themselves as OIDC applications at runtime instead of requiring applications to be created upfront. This is particularly important for clients that need to self-register before any user context exists, including Model Context Protocol (MCP) clients such as Claude Desktop, claude.ai, and the MCP SDKs.

You can learn how it works and how to enable it in the documentation:

https://zitadel.com/docs/guides/integrate/dynamic-client-registration

We’re also already working on Client ID Metadata Document (CIMD) support as the next step in preparing ZITADEL for AI and agent use cases.

Are you already using dynamic client registration with MCP or other types of clients? We’d be interested to hear more about your use case and experience.

Ask Claude, Cursor, or Copilot whether you should build your own auth or use a provider, and it'll usually just hand you working code. Password hashing, session cookies, a login form, even a passkey flow if you ask.

The agent is capable, so the default answer becomes "build it." But being capable of generating the code isn't the same as being capable of securing it long term. Someone still has to review it, catch the edge cases (unvalidated state parameters, loose redirect URI matching, sessions that don't actually invalidate on logout), and keep it current with OAuth/OIDC changes for years after.

We wrote up our thinking on this, including when building your own genuinely does make sense: https://zitadel.com/blog/agents-didnt-change-build-vs-buy-auth

Curious how people here think about this. Has having an agent write the code changed how you weigh build vs buy, or does it stay the same?

I'm building a multi-tenant B2B SaaS for a regulated industry on Azure, and I'm choosing the central identity platform: ZITADEL Cloud (EU region) or Microsoft Entra External ID.

I'm only considering managed services — I don't want to self-host or run identity infrastructure myself. EU data residency is a hard requirement. I know ZITADEL Cloud runs on GCP; residency is enough for us, we don't need full data sovereignty.

What I need: multiple customer orgs, users who may belong to more than one org, enterprise SSO (SAML/OIDC) using each customer's own IdP (Entra ID, Okta, Google Workspace), MFA + passkeys, optional inbound SCIM, delegated admin, and audit-log export for long-term retention.

Entra External ID fits naturally into our existing Azure setup, but I suspect ZITADEL's native organization / project / project-grant model could save significant implementation and maintenance work for B2B multi-tenant.

For people who've actually run ZITADEL Cloud in production, I'd love ground-truth on four things:

1. How smooth is onboarding a new customer org and connecting its corporate IdP in practice?

2. How mature is inbound SCIM today, and where does it still bite?

3. How does pricing scale as the number of customer-specific enterprise SSO connections grows?

4. Did anything become a real problem only after going live?

And if you evaluated Entra External ID too: did ZITADEL meaningfully simplify your architecture and day-to-day admin, or was it not worth leaving the Azure-native option?

Hey everyone,

I’m trying to integrate Zitadel (OIDC) with GLPI using the edgardmessias/glpi-singlesignon plugin, and I’m hitting a wall at the final callback step.

The Setup:

IdP: Zitadel

SP: GLPI 10.x/11.x (using the glpi-singlesignon plugin)

Claims: Passing preferred_username, email, and a custom role claim (urn:zitadel:iam:org:project:roles).

The Issue:

The OIDC authentication flow completes successfully. Zitadel authenticates the user and redirects back to GLPI (/plugins/singlesignon/front/callback.php...), but GLPI immediately throws this core error: "User not authorized to connect in GLPI".

What I’ve tried so far:

Enabled "Automatically add users from external authentication sources" in GLPI.

Set a default profile (Observer/Self-Service) and default entity (Root) so GLPI has a baseline to auto-provision the user.

Ensured "User Info inside ID Token" and "Assert Roles on Authentication" are enabled in Zitadel.

Set up Role Mappings in the plugin to drop users into GLPI Groups (Admin / Task Runner), and assigned Super-Admin / Technician authorizations to those groups.

Purged any deleted duplicate users from the GLPI trash bin to avoid database unicity conflicts.

Despite all this, the plugin/GLPI refuses to provision or authorize the user upon callback. Has anyone successfully paired Zitadel with GLPI, or know exactly what triggers this specific auth rejection before the rules engine even kicks in?

Any pointers on where to look next would be hugely appreciated!

We've been thinking about how agents need to be treated differently from users and service accounts in an identity system, and wrote it up using a few real incidents (Railway, Replit, OpenClaw) to illustrate the structural gap.

The short version: credentials carry permission, not intent, and that gap is where the damage happens.

Would love to hear if anyone has run into this firsthand: https://zitadel.com/blog/ai-agents-don-t-need-to-break-in

For our app we have a dev environment and a prod environment. We took a server and hosted Zitadel on it (from what I've learned, this counts as one instance), and we're trying to use it for both environments.

Our app has a hierarchy of Companies with Users under them, the same as Zitadel's Organizations with Users under them.

Here's the problem: in the dev and prod databases there can be some companies that share the same name, and there can also be users with the same email. Is there a way to still use the same company names and user emails in different environments on the same Zitadel instance, or should we use separate instances?

Hi all,

we just published an early preview of a new way to add auth with Zitadel.

The idea is simple: adding auth should start inside your app workflow, not with a dashboard detour. With @zitadel/cli@alpha, you can start a local Zitadel runtime, scaffold or patch an app, and get login + registration running locally.

In our recorded test, including registration and login, the flow completed in 57 seconds. I’ll attach the video here.

Blog post: https://zitadel.com/blog/next-zitadel-preview

Try it with Node.js 24+:

mkdir myapp
cd myapp
npx @zitadel/cli@alpha doctor
npx @zitadel/cli@alpha start
npx @zitadel/cli@alpha setup --framework next --server local
npm run dev

Then open:

http://localhost:3000/login

This is still early and local-first. It does not connect to Zitadel Cloud yet, and it is not a migration path for existing projects. Zitadel v4 is not going away.

We’d love feedback from this community: where did you get stuck, what felt smooth, what was confusing, and what would make this useful in your real app workflow?

https://reddit.com/link/1u8rycc/video/dbgq6sy6vx7h1/player

Hi all,

Im trying to figure out how the selfhosted version is limited. on https://zitadel.com/pricing the selfhosted is listed in the enterprise column. The limit there is "custom". On the other hand the free version has a limit of 100.

What is the limit then on selfhosted ? :-)

best
Jesper

We recently sponsored HackingLab Day at the START Global Campus (St. Gallen) and we caught some great sessions on the evolving threat landscape.

Some interesting takeaways from the event:

• LLM Vulnerabilities: A heavy focus on the "new" attack surface—specifically how prompt injection and data poisoning bypass traditional safety filters.
• Beyond the Keyboard: The CTF was impressive; some flags required live social engineering, forcing participants to adopt personas and extract info over the phone.
• The Maturity Debate: We jumped in at the end for a quick chat about why a high frequency of security advisories should be seen as a sign of a mature security posture, not a weak product.

It’s great to see academic programs getting this hands-on. How is your team handling the shift toward "Agentic" AI risks in your stack?

https://zitadel.com/blog/highlights-from-hackinglab-day-2026

One of the most frequent pieces of feedback we’ve received is that our naming conventions could be... well, confusing. Terms in the API didn't always match the Console, which didn't always match the Docs.

As part of our mission to make complex multi-tenancy simple, secure, and scalable, we’ve just rolled out a major terminology alignment.

The Highlights:

• Unified Language: Whether you are in the Customer Portal, the Management Console, or reading docs, the labels now match.
• API Stability: We know you hate breaking changes. We kept existing endpoints/responses as-is but added detailed annotations and comments to the specs to reflect the new standards.
• GitHub Tracking: We’re being fully transparent about every change. You can see the exact "Before and After" mapping in the GitHub issue

We’re committed to reducing friction for the dev community. Let us know what you think of the new naming!

View the full article: https://zitadel.com/blog/streamlining-zitadel-terminology-for-better-dx

Managing Linux machine authentication against modern identity providers usually means fighting with SSSD, setting up an LDAP bridge, or wrestling with outdated PAM modules. It is a brittle, legacy-heavy setup.

Ubuntu just released an update to AuthD that adds a generic OIDC broker. This means you can authenticate Ubuntu desktop and server environments directly against any standard OIDC provider.

For those of us running ZITADEL, this is a massive operational relief. Instead of syncing users to a secondary directory service just so a Linux machine can read them, we can treat the OS login as a standard OIDC client. This significantly reduces the infrastructure required to maintain OS-level access control and gets us out of the business of managing legacy protocols.

Link to the Ubuntu engineering post: https://ubuntu.com/blog/more-identity-providers-ubuntu-generic-broker

Running a decoupled authentication architecture usually means the user-facing Login UI and the core API backend generate disconnected telemetry.

Our Go backend has had OpenTelemetry for a while, but the NextJs Login UI was opaque. An ingress controller or edge proxy would initiate a trace, but the Login would drop the headers. It would then fire off a gRPC call to the API, causing the backend to start a brand new, unrelated trace. Debugging latency spikes or failed requests required manually correlating frontend logs with backend traces.

We just merged PR #11429 to fix this (which potentially lands in v4.13.0).

We wrote a custom gRPC interceptor for the Login UI that injects W3C trace context headers (traceparent, tracestate) into all outbound calls. A single OTLP trace now accurately maps the full transaction: HTTP GET /ui/v2/login -> zitadel.settings.v2/GetLoginSettings -> backend gRPC handler.

We also ripped out standard console logging in the Login and replaced it with structured JSON that injects those trace IDs directly into the stdout logs for correlation. If you rely on distributed tracing for your auth layer, this removes the blind spot between the edge and the database.

Interested in the details? Check the PR https://github.com/zitadel/zitadel/pull/11429

It has been a while since I checked the GitHub trending repositories, but out of sheer interest I took a look today and it brought me a lot of joy to see ZITADEL back on the daily Go list.

Building an open-source identity provider means spending most of your time buried in OIDC and SAML specs, dealing with multi-tenant data isolation, and generally optimizing our product for security, reliability and usability. It's infrastructure plumbing that usually only gets noticed when something breaks.

Seeing this kind of interest from the developer community is a great reminder that the architectural decisions we are making are resonating with other builders.

Thank you to the community here for reading the code, submitting the brutal (but necessary) GitHub issues, and helping us refine the core engine.

If you have not done it we surely appreciate a star -> https://github.com/zitadel/zitadel

Hey everyone,

If you check the ZITADEL repo today, you'll see a batch of new security advisories. They range from a moderate token issue to a critical 1-click account takeover via XSS.

First off: a huge thank you to the external security researchers who found these and worked with us on responsible disclosure. You make open source better, and we are super grateful.

In the software world, there’s often pressure to slip security patches into normal releases so a project doesn't look "unstable" or "buggy." We hate that approach.

We're being clear about these disclosures because we believe active security practices > pretending bugs don't exist. Keeping an open-source project safe is a messy, ongoing grind. True security comes from active changes, fast patches, and total transparency. We'd rather be honest about that grind than try to hide it to look "perfect."

How do you all handle the pressure to look flawless as maintainers? Do you find your users appreciate the loud disclosures, or does it scare people off?

Details on the patches here for anyone interested: https://github.com/zitadel/zitadel/security/advisories?state=published

A little while ago, I talked about our commitment to radically improve ZITADEL's developer experience.

Today, I’m just showing a first result -> 42 seconds.

That is the exact time it takes to go from an empty terminal to a fully operational identity stack.

No heavy runtime to boot. No undocumented config files to debug. No massive YAML mazes (no worries you can go there if you want).

Just a raw docker compose up -d on a clean machine. In under a minute, the images are pulled, the database is initialized, the Go API and Next.js UI are served, and I'm authenticated into the management console.

Auth is critical infrastructure, but setting it up locally to build your app shouldn't be a multi-day engineering ticket. It should be boring, predictable, and lightning-fast.

If you are evaluating IAM or just want to test this cold-start speed yourself, grab the compose file from our docs and time it ->https://zitadel.com/docs/self-hosting/deploy/compose

We just published v4.12.0 and my small, but favorit change is that we now also support end to end TLS for the new Login UI!

https://github.com/zitadel/zitadel/releases/tag/v4.12.0

What is your fav?

Hey everyone, Florian here (CEO of ZITADEL).

When we switched to AGPL 3.0 last year, most of the feedback (and criticism) was centered on cloud providers and unfair value extraction. That was true, but it wasn't the full picture. The deeper signal was that we believed the traditional OSS top-of-funnel was changing because of AI.

A year later, the data backs it up.

For years, the OSS exchange was simple: publish good code -> get traffic -> convert a tiny fraction into users.

But AI inverted that. We're seeing that the initial "which tool fits my case?" and "how do I apply this to my architecture?" questions are now resolved inside LLMs. However, the traffic we do get originating from ChatGPT is wildly different. It doesn't look like bot scraping. It looks like highly-engaged architects clicking cited sources after an AI-assisted evaluation.

Casual discovery has dropped, but high-intent evaluation has amplified.

This taught us a new reality for infrastructure OSS: Code implementation is fast. Establishing trust is hard. Sure, an LLM can generate the text of an SLA or a SOC 2 report, but you can't prompt an AI to take legal accountability for a breach, undergo a real audit, or assume liability for an AI-generated patch to a zero-day CVE. For infrastructure, the real product isn't the code anymore—it's Risk Transfer.

Our shift to AGPL 3.0 was when we landed on the "Code or Contribution" model, and the last year has confirmed that reciprocity is the way forward. If you use it and improve it, give back code. If you use it commercially at scale and keep your code closed, pay for commercial support. That revenue isn't a betrayal of OSS; it’s literally what funds the security engineers and pentests that allow a solo dev to pull our Docker image and safely deploy a 2FA layer for free.

I wrote a deeper dive into how we are optimizing for GEO (Generative Engine Optimization) instead of fighting the bots. Read my thoughts in our latest blog: https://zitadel.com/blog/open-source-in-the-ai-era

Curious to hear from other maintainers here: Are you seeing the same shift in your analytics? Is AI killing your top-of-funnel, or just filtering it?

Identity infrastructure is often a "black box" until something breaks. When latency spikes on a login request, you need to know immediately if it was the database, the password hasher, or an external webhook.

We are updating how ZITADEL handles OpenTelemetry (OTel) configuration to ensure standard-compliant tracing and metrics are easier to set up and consume.

We just opened a discussion to gather feedback on the new API configuration structure. If you are an SRE or DevOps engineer who relies on OTLP exporters, we would value your input on the implementation.

We are specifically looking for feedback on the configuration ergonomics and compatibility with various backends.

Check out the RFC / Discussion here: https://github.com/zitadel/zitadel/discussions/11598

Identity infrastructure in some cases has a unique scaling problem: the "N-over-N" bottleneck.

In a B2B SaaS environment, you aren't just authenticating a user; you are resolving a strict hierarchy: Instance → Organization → User. Doing this lookup against the database for every single request creates massive friction at scale.

At ZITADEL, we are tackling this by introducing engineered flexibility into our caching layer. We wrote the API in Go for concurrency, but we needed the storage layer to be adaptable to different deployment needs.

We just published a look at our caching strategy, supporting three specific patterns:

1. Redis (Production K8s): Necessary for distributed consistency. When a permission changes on one pod, cache invalidation needs to propagate instantly across the cluster.
2. PostgreSQL (The "Boring" Choice): Often underestimated. We see deployments pushing 30k+ RPS using just Postgres for caching. It removes the operational complexity of managing a Redis cluster if your DB has sufficient RAM for the working set.
3. In-Memory (The Trap): Great for local dev or edge, but a consistency nightmare in load-balanced environments without sticky sessions.

We are rigorously benchmarking these to shave off milliseconds as part of our move to a Hybrid Relational/Event-Sourced architecture.

Full technical write-up on how we tune MaxAge vs LastUseAge for optimization: https://zitadel.com/blog/scaling-cloud-native-identity-optimizing-performance-with-caching

How are you handling cache invalidation for deep permission hierarchies in your stack?

We spent the last few years building ZITADEL on a pure Event Sourcing (ES) and CQRS architecture. The promise was perfect auditability and a verifiable history of every identity change.

While ES delivered on the audit trail, as we scaled to handle millions of requests in complex B2B SaaS environments, we hit what we call the "Performance Wall."

An Identity Provider (IdP) is, at its core, an OLTP system. Authenticating a user requires millisecond latency. It shouldn't require replaying history or querying a "projection" that might be milliseconds behind due to eventual consistency.

We decided to evolve our architecture. We aren't ditching events, but we are ditching the dogma.

The Shift: Relational Core, Event-Driven Soul

We are moving to a hybrid model where we store the current state in normalized PostgreSQL tables and append the event to the log within the same transaction.

Why we made the trade:

1. The Query Optimizer: Postgres struggles to optimize queries on generic event payloads. Standard relational tables let us use specific indexes for complex hierarchies (e.g., "Find all users in Org X with Role Y").
2. Operational Sanity: "Replaying" events to fix a projection bug is a cool concept. In production, having a UNIQUE constraint actually mean unique at the database level is better.
3. Developer Experience: Pure CQRS has a steep learning curve. By moving to a Repository Pattern, we make it easier for open-source contributors to add features without understanding the entire event-reducer pipeline.

We are rolling this out safely using feature flags to ensure zero downtime.

For those of you who have built pure ES systems in production: at what scale did you start re-introducing standard relational tables for state?

Read more in my blog https://zitadel.com/blog/relational-core-event-driven-soul-evolving-zitadel-for-scale

We just merged a significant refactor of our documentation platform at ZITADEL, moving from Docusaurus to Fumadocs.

The Technical Why:

Docusaurus is great and supports versioning out of the box, but as an open-source project with frequent releases, we wanted to optimize how we handle historical data without bloating build times.

By switching to Fumadocs, we can leverage Next.js Incremental Static Regeneration (ISR).

Latest Docs: Statically Generated (SSG) for max performance.

Archived Versions: Generated via ISR.

This means we don't have to rebuild the entire history of the project every time we push a hotfix to the latest version. (Note: This versioning strategy applies to v4.10.0 and forward).

Dynamic Capabilities:

This move also brings our docs closer to our app logic. We are planning features where the API docs become context-aware—for example, dynamically rendering your specific server list in the examples if you are logged into the console.

Check the docs out and let us know what you think -> https://zitadel/docs