Next Zitadel preview: Control your login from code, starting in a minute

June 17, 2026

Founder and CEO

announcement

Today, adding login often starts outside your app. You sign up for a service, create a tenant, configure an application, copy secrets into an .env file, switch back to your editor, and only then find out whether anything works.

For developers, that is friction. For coding agents scaffolding an app from a prompt, it is worse: a long chain of browser-driven steps with no verifiable success until the end.

So we started rebuilding the first five minutes.

With the new Zitadel preview, you can add login and registration to an existing app, or scaffold a fresh one from an empty directory. The example below starts from an empty directory, uses Next.js, and requires Node.js 24 or newer.

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, create an account, log out, and log back in. You should have a working local login and registration flow with username/password and passkeys support. In our recorded browser test, including registration and login, the flow completed in 57 seconds.

setup --framework next creates a Next.js skeleton when the directory is empty, then wires in Zitadel. You can also run the same setup command inside an existing app. Other early framework adapters include React, Vue, Angular, and Nuxt.

No manual dashboard setup. No manual tenant provisioning. No copying secrets between browser tabs. Start inside your code.

This preview is local-first and intentionally early. It does not yet connect to Zitadel Cloud, and it is not a migration path for existing projects. Zitadel v4 is not going away, and nothing changes for the product you run today. This is a preview of where we want the developer experience to go, built and tested in the open before bringing it to the product.

Why we are building this

Zitadel has always been about secure, open identity infrastructure. What has changed is how that infrastructure gets consumed.

More software now gets developed locally, validated in pull requests, tested in CI, deployed through preview environments, automated through scripts and pipelines, and increasingly assisted by coding agents that write, run, and test code on a developer's behalf.

Identity should be part of the development workflow, not a separate setup workflow.

Developers should be able to start locally, inspect what changed, review configuration in code, and test auth before touching production. Coding agents need the same things, plus predictable commands, structured output, non-interactive execution, and clear success or failure states.

That is the bar we set for this preview: authentication should feel like part of building software, not a separate setup process that starts in a dashboard.

What is included in this preview

This preview focuses on local development and the first setup experience.

A local Zitadel runtime started with a single npx command
Runtime metadata and local server data stored in your project
Setup paths for Next.js, React, Vue, Angular, and Nuxt
--json and --non-interactive flags, so coding agents can drive setup without scraping prose or clicking through CLI prompts

No Docker required. Authentication should be something you can try in minutes, not something that requires additional infrastructure before you can even get started.

How it works

The principle behind the architecture is simple: your app owns the experience, while the runtime owns the security-sensitive state.

When you start the local runtime, the CLI writes runtime metadata to .zitadel/local/runtime.json and stores local server data under .zitadel/local/nextgen-data. When you run setup, the CLI checks your environment, writes project configuration, and patches your framework app.

For server frameworks such as Next.js and Nuxt, the SDK routes auth requests through a same-origin path, /__nextgen, which removes the need for CORS setup. For React, Vue, and Angular, setup wires the same path through a local dev-server proxy; production SPA deployments need an edge or hosting-provider proxy such as Vercel, Netlify, or Cloudflare.

Either way, the browser receives only public runtime metadata. Credentials, sessions, challenges, cookies, and flow state stay inside the runtime and the framework or proxy layer.

The <zitadel-login> web component renders a working local login and registration experience. Today it runs on the server's default schema, flows, and page templates. Moving those into your project as reviewable files is the direction we describe next.

Where we are going next: identity that adapts to your application

The first preview gets the local loop working. The bigger direction is to make identity configuration feel like part of the application workflow.

Getting authentication running locally is only the first step. From there, teams usually run into a different set of problems: custom user models, application-specific authentication flows, identity changes that need review before production, and increasingly, agents acting on behalf of users.

We want identity configuration to behave more like application code: local, versioned, reviewable, testable, and safe to promote into shared environments.

Model humans, services, and agents explicitly

Most identity systems start with a predefined user model and expect applications to adapt to it. In practice, it usually works the other way around.

A B2B SaaS platform, an internal tool, a marketplace, and an AI-powered application often have very different identity requirements. A human user might need an email address, a profile name, and recovery options. A machine user might authenticate through credentials without any human profile fields. An AI agent might act on behalf of a user for a limited task and need delegation context rather than an inbox.

That is why user schemas should become local, versioned files. Developers and coding agents should be able to read, diff, review, and test them before they affect a shared environment. Different products should be able to define different fields, identifiers, constraints, and lifecycle rules without forcing everything into one fixed shape.

Define flows as code

Login, registration, recovery, step-up authentication, and custom journeys should be defined as ordered steps, fields, actions, and transitions.

Those flows should be reviewable and testable like application changes. Teams should be able to see what changed, discuss it in a pull request, run it in a preview environment, and promote it intentionally.

The goal is not to make every application team an authentication security expert. The goal is to let teams customize the experience while Zitadel continues to own the security-critical authentication machinery behind passkeys, sessions, challenges, credentials, and audit trails.

Build agent governance into identity

Most identity systems understand two things: users and applications. Agents do not fit neatly into either category.

An agent is not just another user. It is not just another service account either. It acts on behalf of someone, often with limited permissions, for a specific task, and with an expectation that the work can be audited later.

That changes the questions identity needs to answer. Who delegated the work? Which agent acted? What was it allowed to do? Which resources could it access? What actions did it take?

We want agents to become first-class identities in Zitadel, with delegation chains, scoped credentials, and audit trails built into the identity layer.

Try it with a coding agent

This preview was built to be driven from the command line, so try it with your coding agent too. The important part is not just whether the commands run. Ask the agent to prove the generated auth flow in a browser.

Copy this prompt:

Create or use an empty directory for a fresh Next.js app. Use Node.js 24 or newer.

Install and run Zitadel through the CLI, not through the dashboard. Prefer non-interactive JSON commands and capture stdout/stderr separately where possible.

Run:

npx @zitadel/cli@alpha doctor --non-interactive --json
npx @zitadel/cli@alpha start --non-interactive --json
npx @zitadel/cli@alpha setup --framework next --server local --non-interactive --json
npm run dev

Then use the in-app browser, Playwright, Chrome, or another available browser to open http://localhost:3000/login. Register a local user, verify the signed-in state, log out, log back in with the same user, and finish on the signed-in profile page.

When you are done, summarize what worked, what failed, which files changed, and any CLI or browser/UI friction you hit.

What is not here yet

For this first preview, we are keeping the scope intentionally small: get auth running locally, try the workflow, and tell us what works and what does not. Cloud integration, enterprise protocols, management features, migrations, and broader framework support will come later.

The API and CLI are still alpha. Expect changes while we use feedback from this preview to shape the next iteration.

We want your feedback

We are especially interested in the first setup experience. Tell us where things got in the way. What felt harder than it should have been? What required workarounds? What was missing? And if you tried it with a coding agent, where did the agent need help from a human?

We also want feedback on the direction. What are the biggest identity challenges in your application today? Where do you run into friction when building, testing, reviewing, or operating authentication? Which parts of the workflow feel harder than they should be?

Join the conversation in our GitHub Discussions or on Discord.