Skip to content

Releases: zitadel/nextgen

Zitadel NextGen v0.4.0

Choose a tag to compare

@github-actions github-actions released this 02 Nov 03:31
72bf4dc

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: 72bf4dcf3ce6

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:0.4.0
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 0.4.0
@zitadel/server 0.4.0
@zitadel/server-linux-x64 0.4.0
@zitadel/server-linux-arm64 0.4.0
@zitadel/server-darwin-x64 0.4.0
@zitadel/server-darwin-arm64 0.4.0
@zitadel/server-win32-x64 0.4.0
@zitadel/api 0.4.0
@zitadel/config 0.4.0
@zitadel/components 0.4.0
@zitadel/sdk-core 0.4.0
@zitadel/sdk-next 0.4.0
@zitadel/sdk-nuxt 0.4.0
@zitadel/sdk-react 0.4.0
@zitadel/sdk-vue 0.4.0
@zitadel/sdk-angular 0.4.0
@zitadel/sdk-solid 0.4.0
@zitadel/sdk-svelte 0.4.0
@zitadel/sdk-qwik 0.4.0
@zitadel/sdk-sveltekit 0.4.0
@zitadel/sdk-solid-start 0.4.0
@zitadel/sdk-qwik-router 0.4.0
@zitadel/sdk-tanstack-start 0.4.0
@zitadel/testing 0.4.0

Package Changes

Minor Changes

  • @zitadel/cli, @zitadel/api, @zitadel/sdk-core: #2357 79d8dd0 - The server SDKs' /__nextgen proxies and the dev proxies zitadel setup writes for single-page apps now recognize the session calls under /api/v1 as well as at their current paths, so sign-in keeps working once the API moves under /api/v1. zitadel doctor warns about a dev proxy an earlier zitadel setup wrote, and zitadel doctor --fix updates it. If you wrote your own production proxy for a single-page app, have it add the project secret to POST /api/v1/sessions/exchange as well as POST /sessions/exchange. @zitadel/api exports API_PREFIX, the path the API moves to.

  • @zitadel/cli: #2464 3481a07 - zitadel deploy and zitadel preview record a message when -m is omitted: a GitHub pull request's title, Vercel's commit message, or the current commit's subject on a clean worktree, so a CI run no longer needs -m. zitadel preview -m and zitadel deployment rollback -m record a message of their own, and a blank or over-long -m is refused.

  • @zitadel/cli: #2439 d277b8f - release list shows when each release was created, release get shows the resources a release pins, and deployment get shows the variables the deployment froze.

  • @zitadel/cli: #2487 bf6ce2e - zitadel skills add gives your project's coding agents the Zitadel skills of the CLI version you run, for Claude Code and most other agents, and the note after setup now names it (Agent setup).

  • @zitadel/cli, @zitadel/server, @zitadel/api, @zitadel/sdk-core, @zitadel/sdk-next, @zitadel/testing: #2359 eb363f0 - The SDKs, the login components, the console and the zitadel CLI now call the API under /api/v1, where the server serves it. @zitadel/api's client puts /api/v1 after the proxy path or server origin it is given, and keeps a single prefix when the origin already ends in it. zitadel api takes a path with or without the prefix and shows the full URL with it. A call the server knows no operation for now says the server may be older than the client.

    Breaking: clients from this release need a server that serves /api/v1, so upgrade a self-hosted server before the apps that call it. In a single-page app set up by an earlier zitadel setup, run zitadel doctor --fix: the dev proxy it wrote adds the project secret only to the old path of the session exchange, so sign-in fails until it is updated, and zitadel doctor now fails on it. A production proxy you wrote for a single-page app must add the project secret to POST /api/v1/sessions/exchange. Until 1.0.0 the server also answers every operation at its old path, with a Deprecation header.

  • @zitadel/cli, @zitadel/server, @zitadel/api, @zitadel/components, @zitadel/sdk-core, @zitadel/sdk-next, @zitadel/sdk-nuxt, @zitadel/sdk-sveltekit, @zitadel/sdk-solid-start, @zitadel/sdk-qwik-router, @zitadel/sdk-tanstack-start, @zitadel/testing: #2488 db05fbb - The session cookie is now __Host-zitadel_session, which a browser accepts only from Zitadel's own host over https, so another site under the same domain can no longer plant a session. On http://localhost it is zitadel_session, so sign-in keeps working in Safari. An app's own, behind a server SDK or dev proxy, adds _<project id>.

    Breaking: every browser signs in again: cookies named __nextgen_session are no longer read. Update the server, the server SDKs, the CLI and @zitadel/testing together; an SDK from before this release keeps no session with this server, nor the other way round. In @zitadel/testing, SESSION_COOKIE_NAME is __Host-zitadel_session, and sessionCookieName(projectId, url) and the new browserSessionCookieName(url) name the cookies for the app's URL. zitadel doctor fails on the dev proxy of a single-page app set up before this release until zitadel doctor --fix updates it.

  • @zitadel/cli: #2461 b2d9cb9 - zitadel setup deploys .zitadel/ to the app's origin once it has committed the project, so the sign-in it asks you to verify is served the release it built. data.deployment reports what it deployed, and a failed deploy is a warning whose next_commands lead with the deploy that fixes it.

  • @zitadel/cli, @zitadel/api, @zitadel/config, @zitadel/testing: #2527 0a00b60 - Every paged list method of the @zitadel/api client now has items(), pages() and all(), which follow the cursor for you, and createZitadelClient takes onResponse and onError hooks; @zitadel/api/client exports pagedFunctions, each paged function's typed readers of a page's items and cursor and the arguments of its next page. The CLI no longer stops --all, the resource list commands or zitadel api --paginate when a server sends the same page cursor twice: that is a server bug, and the client trusts the paging contract. deploy, preview, release create and setup's first deploy check the release body against the API's own schema before sending it, and name each field it refuses. @zitadel/testing no longer re-checks the ids the server answers its bootstrap and seeding with, and types BootstrappedProject.previewSecret as always present, as the server always issues one. @zitadel/config's getDefaultHumanUserSchema is typed as the user schema document it returns, $id included, and exports that type as UserSchemaDocument; getDefaultHumanUserSchemaBody returns it without $id, as an inline schema in a release bundle must be.

  • @zitadel/server: #2335 02677c2 - The console's release detail shows a pinned policy revision: a Policies group with the policy's settings summarised above the document the CLI publishes.

  • @zitadel/server: #2447 3f4da33 - The user schema screen lists every revision of the schema, newest first and marked latest, and opens any of them read-only. An older revision says that users stay on the revision they were created on until they are migrated, and links the migration guide.

  • @zitadel/server, @zitadel/api: #2398 26097dd - Deleting a user who is the last active member of a project's owning team now fails with 409 proj.last_owner and changes nothing. The message names the projects and says to add another member to that team, then retry. details.details.project_ids lists the same ids. Admin grants stay freely revocable, suspending or deactivating a user is still allowed, and a project whose owning team already has no active member is left alone.

  • @zitadel/server: #2469 3b43b2c - The platform project is now deployed like any project: console sign-in is served a release of the configuration the server ships, inc...

Read more

Zitadel NextGen v0.3.0

Choose a tag to compare

@github-actions github-actions released this 01 Nov 21:05
de7a14b

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: de7a14bf7c1d

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:0.3.0
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 0.3.0
@zitadel/server 0.3.0
@zitadel/server-linux-x64 0.3.0
@zitadel/server-linux-arm64 0.3.0
@zitadel/server-darwin-x64 0.3.0
@zitadel/server-darwin-arm64 0.3.0
@zitadel/server-win32-x64 0.3.0
@zitadel/api 0.3.0
@zitadel/config 0.3.0
@zitadel/components 0.3.0
@zitadel/sdk-core 0.3.0
@zitadel/sdk-next 0.3.0
@zitadel/sdk-nuxt 0.3.0
@zitadel/sdk-react 0.3.0
@zitadel/sdk-vue 0.3.0
@zitadel/sdk-angular 0.3.0
@zitadel/sdk-solid 0.3.0
@zitadel/sdk-svelte 0.3.0
@zitadel/sdk-qwik 0.3.0
@zitadel/sdk-sveltekit 0.3.0
@zitadel/sdk-solid-start 0.3.0
@zitadel/sdk-qwik-router 0.3.0
@zitadel/sdk-tanstack-start 0.3.0
@zitadel/testing 0.3.0

Package Changes

Minor Changes

  • @zitadel/cli, @zitadel/config: #2353 1f44571 - zitadel policies test runs the cases in .zitadel/policies/<operation>.test.json against your policy. Each case gives the operation's input (for the password policy, the password itself), optionally the facts the operation would look up (self_service, history_matches), and the decision it expects: allowed, and optionally the error code and exactly the violations. Zitadel evaluates every case as a real password set would, so a case also covers how the password is counted. By default the cases run against the policy file beside them; --release <id> runs them against the policy a built release pins, before you deploy it. A failing case fails the command with E_VALIDATION and lists what was expected and what Zitadel decided. deploy never carries test files, editors validate them against the new .zitadel/meta/policy-test.json, and the policies README that setup writes shows an example.

  • @zitadel/cli: #2428 2d32dbc - The usage analytics events the CLI sends to Vercel Web Analytics now carry one property of the command's own for setup (framework), claim (claim_outcome), doctor (failed_checks), api (operation) and start (runtime). On a failed run it takes the place of non_interactive. The kind of data sent does not change: fixed names only, never a path, id or message.

  • @zitadel/cli: #2288 1cab16f - zitadel deploy --dry-run --json now reports what the deploy would change, so a script or an agent can review it before deploying: data.diff lists each changed file under .zitadel/ with its status and its part of the diff the terminal shows, against the release your primary origins serve. zitadel deploy --json reports the same diff for what it deployed.

  • @zitadel/cli, @zitadel/server, @zitadel/api: #2129 ae0f5eb - POST /users/query can find the users still on an older revision of a schema. The new schema_object_type filter field matches the object type every revision of a schema shares, with equals, not_equals and contains, and schema now accepts not_equals, so schema_object_type equals a type together with schema not_equals its newest revision lists the users left to migrate. zitadel users list --filter accepts schema_object_type.

  • @zitadel/cli: #2321 7722728 - setup now commits the project it scaffolds, initialising a repository first when there is none, so a release records the commit it was built from and a later deploy can show a real diff. Because the commit covers the project directory, setup refuses a repository that already has uncommitted work, untracked files included; only the .zitadel/local/ and .gitignore that start leaves are exempt. It also points at the deploy that pins .zitadel/ into a release. --no-git opts out of the commit.

  • @zitadel/server: #2337 4e481af - The server's API request metrics (ogen.server.request_count, ogen.server.errors_count, ogen.server.duration) now carry only the operation, method, route template and status code, so a request path with an id in it can no longer become a time series of its own. The configuration guide gains a Metrics section that lists every instrument the server reports through instrumentation.metric, with its attributes and their values, and documents the bound every instrument already had: at most 2000 series, past which new attribute combinations are counted on one series marked otel.metric.overflow=true. That bound is now covered by a test.

  • @zitadel/server: #2365 556ace1 - The Console's project page has an Overview tab and an Admins tab. Overview holds the project's name, its origins and its variables and secrets: origins can be added, edited and removed from the page, and variables are listed with the value each kind holds, a secret showing only that it is configured. Admins moves to its own tab. The projects list's row menu opens the page as "View project".

  • @zitadel/server: #2390 4068176 - The console's project page shows the project's password policy: the minimum length and the password history in force, with a warning when the minimum is under the recommended 15 characters.

  • @zitadel/server: #2338 4cd4d57 - The server now measures its database work: db.client.operation.duration times every storage statement, labelled with the database and the statement method that issued it, and db.client.connection.count and db.client.connection.max report the PostgreSQL and SQLite connection pools by state. Both are listed in the configuration guide's Metrics section.

  • @zitadel/server: #2397 a6fb3ce - A server that runs only while it serves a request, such as a Vercel function, can now leave the purge of expired audit events to a scheduler outside it. Set events.retention.trigger_secret to at least 16 characters: the server then stops its hourly purge and runs one each time /cron/events-retention is called with the secret as a bearer token. Without the setting, the server purges hourly as before.

  • @zitadel/server: #2350 1ddde86 - POST /policies/evaluate evaluates an operation's policy as a dry run: it takes a config, the operation's input (for the password policy, the password itself) and the facts the operation would look up (self_service, history_matches), and answers whether the operation would go ahead. A refusal carries the error code and violations the live operation answers with, such as user.password_policy_violation with {"min_length": 12} or user.password_empty, because the server runs the password set's own check, NFC normalization and the 64-character cap included. Nothing is read from or stored in the project; an invalid config is refused with pol.invalid, as on publish.

  • @zitadel/server, @zitadel/api: #2129 ae0f5eb - GET /schemas accepts expand=in_use, which adds metadata.in_use to each listed revision: whether any user of the project is on it. The flag is absent unless asked for, and needs read on the whole project, plus user.read for a token. Users are now indexed by schema, so the check and the schema filter on POST /users/query no longer read every user of the project.

  • @zitadel/server: #2339 b31e6f5 - The server now measures its authentication and audit paths: how long validating a bearer credential takes and whether it was valid, revoked, invalid or failed; how often token records are checked and found active or revoked; how long verifying a password takes and whether it matched, matched and was rehashed, or did not match, for sign-ins and for the comparisons against remembered passwords on a password change; the outcome of every authentication proof by...

Read more

Zitadel NextGen v0.2.0

Choose a tag to compare

@github-actions github-actions released this 27 Oct 23:26
c5557cd

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: c5557cdbed6d

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:0.2.0
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 0.2.0
@zitadel/server 0.2.0
@zitadel/server-linux-x64 0.2.0
@zitadel/server-linux-arm64 0.2.0
@zitadel/server-darwin-x64 0.2.0
@zitadel/server-darwin-arm64 0.2.0
@zitadel/server-win32-x64 0.2.0
@zitadel/api 0.2.0
@zitadel/config 0.2.0
@zitadel/components 0.2.0
@zitadel/sdk-core 0.2.0
@zitadel/sdk-next 0.2.0
@zitadel/sdk-nuxt 0.2.0
@zitadel/sdk-react 0.2.0
@zitadel/sdk-vue 0.2.0
@zitadel/sdk-angular 0.2.0
@zitadel/sdk-solid 0.2.0
@zitadel/sdk-svelte 0.2.0
@zitadel/sdk-qwik 0.2.0
@zitadel/sdk-sveltekit 0.2.0
@zitadel/sdk-solid-start 0.2.0
@zitadel/sdk-qwik-router 0.2.0
@zitadel/sdk-tanstack-start 0.2.0
@zitadel/testing 0.2.0

Package Changes

Minor Changes

  • @zitadel/cli: #2292 6392fe2 - The CLI's usage analytics events now carry surface: cli, which names the Zitadel component that sent them, so they can be read beside the events of other Zitadel components. Nothing else they carry changes.

  • @zitadel/cli: #2402 a7f9216 - zitadel claim --no-wait prints the claim link and exits, with claim_url, challenge_id and expires_at under --json, so a script or coding agent can hand the link to a person; zitadel claim --challenge-id <id> then waits for that link to be used and records the claim.

  • @zitadel/cli: #2348 89bcfca - Running zitadel alone now lists the commands under six headings named for what you are doing, one row per family such as users or release. zitadel users --help lists its operations, every command's help ends by pointing at the overview, and zitadel commands still prints the flat list.

  • @zitadel/cli: #2367 e7b7d61 - zitadel auth-method sso enable --provider custom now asks at a terminal for the connection's name, its sign-in button's name, the issuer URL and the scopes you leave out, instead of failing with a list of flags; scripts still need the flags (docs). A new custom connection also prints its claim mappings and the file to edit them in.

  • @zitadel/cli: #2323 5f49e7d - The CLI's onboarding output now says what to do next: zitadel start points to zitadel setup instead of a console link, setup spells out every choice and shows the sign-in configuration before writing it, and auth-method sso enable says to deploy the provider, then test sign-in. The note about Zitadel's agent skills shows once per machine.

    Breaking: zitadel start --json no longer has data.console, and its next_actions and next_commands no longer mention the console; a script that reads them gets nothing there. Run zitadel console --json for data.sign_in_url.

  • @zitadel/cli, @zitadel/server, @zitadel/api: #1650 2d78353 - zitadel origin add <pattern> --kind primary|preview, origin list and origin rm manage the origins a project serves, with the project secret (docs). A primary origin is an exact URL, and a preview wildcard on a shared host needs a literal label of your own.

  • @zitadel/cli, @zitadel/config: #2270 08a369b - zitadel deploy now carries operation policies from .zitadel/policies/, one file per operation, checked against the new .zitadel/meta/policy.json schema before anything is sent; zitadel policies list and policies get read them back (docs). Sign-ins and sign-ups use the policy the deployed release carries, so deploying without a file switches that policy off.

  • @zitadel/cli: #1652 3494326 - Preview a branch's release on its pull-request URLs with zitadel preview. Run inside a preview build, it reads the preview URLs from the hosting platform (Vercel or Netlify; pass Cloudflare Pages URLs with --origin) or from --origin, builds the same release deploy does, validates it without touching your live sign-in providers, and makes it live on those URLs for a time-to-live (--ttl, between 60s and 365d; omitted, the project's default applies). Its last line is NEXT_PUBLIC_ZITADEL_RELEASE=sha256:... for the build to pin. Outside a preview or development build it does nothing — even with an explicit --origin — because production is deployed by zitadel deploy after merge, and --origin primary or a primary origin's own URL is refused. On a CI platform other than Vercel or Netlify, set ZITADEL_ENV=preview in the pull-request build: a CI build that names no environment is skipped too.

    zitadel preview list shows the project's live previews, and zitadel preview rm <url> ends one early. All three authenticate with ZITADEL_PROJECT_SECRET for now, because the server does not accept the narrower preview token yet (#1575); they never fall back to the other credential. preview list and preview rm fail, naming the variable, when it is not set; zitadel preview instead warns and still exits successfully unless --strict is passed.

  • @zitadel/cli: #1407 5ab100f - zitadel pull rebuilds .zitadel/ from what a release pins — the live release by default, a release id (rel_…) or a deployment id (dep_…) — so the next deploy builds the same release (docs). It restores schemas and flow definitions, and warns for branding and identity provider connections, which it cannot read back yet.

  • @zitadel/cli: #2307 44029c8 - zitadel start no longer reports a login URL, because the server no longer serves a login page: sign in through the login page zitadel setup adds to your app.

    Breaking: zitadel start --json no longer has data.urls.login; a script that reads it gets nothing there.

  • @zitadel/cli: #2253 0529137 - The CLI now sends its anonymous usage events to Vercel Web Analytics on the Zitadel cloud (preview.zitadel.com), with at most eight of their properties, and sends nothing to Mixpanel for now. The existing opt-outs (--no-telemetry, DO_NOT_TRACK=1, ZITADEL_TELEMETRY=0) turn them off, and runs in CI send nothing.

  • @zitadel/cli: #2245 ad626b9 - zitadel logs now shows the local server's warnings in yellow and errors in red, and --level warn shows only those, so the reason a sign-in failed is easy to find. zitadel start and zitadel doctor say to keep zitadel logs --follow open, and zitadel logs works from an app inside the directory zitadel start ran in.

  • @zitadel/cli, @zitadel/server, @zitadel/api: #1651 c21caeb - zitadel deploy replaces plan and apply: it builds .zitadel/, identity provider connections included, into one immutable release, shows its git diff against the live one, and makes it live on the project's primary origins (guide). New release and deployment commands, and their @zitadel/api operations, create, list, deploy, roll back and revoke releases directly; a rollback lists the revisions it restores.

    Breaking: plan and apply are removed. Use deploy --dry-run where you ran plan, and deploy where you ran apply. The generated releases list and releases get are now release list and release get, beside release create and release revoke. Add the origins your project serves with origin add before the first deploy — deploy needs at least one p...

Read more

Zitadel NextGen v0.1.0

Choose a tag to compare

@github-actions github-actions released this 21 Oct 23:50
c621117

0.1.0 is the first proper release of Zitadel NextGen, and the first on npm's latest tag. Registration and login live in your app, under your brand, while Zitadel guards the credentials, sessions and tokens underneath. An empty folder becomes an app with a working login in three commands, with no account and no Docker:

npx @zitadel/cli@latest start
npx @zitadel/cli@latest setup --framework next --server local
npm run dev

This release sums up everything the alpha previews built; those versions are deprecated now. NextGen is still a preview: until 1.0.0, a minor release can include breaking changes, and each one is called out as breaking. The quickstart walks you through it.

What you get

  • Sign-in and sign-up in your app. <zitadel-login> runs the whole flow in one element: email and password, passkeys, and social sign-in with Google or any OIDC provider, where the first sign-in creates the account. <zitadel-session> and <zitadel-logout> show who is signed in and sign them out. For a UI of your own, the flow and auth-attempt APIs drive sign-in headless. Components
  • 12 frameworks. zitadel setup creates a new app or patches an existing one with login, registration and profile pages, for Next.js, Nuxt, SvelteKit, SolidStart, Qwik Router, TanStack Start, React, Vue, Angular, Solid, Svelte and Qwik. The server SDKs keep auth on your own origin: they check sessions, protect routes and keep the project secret on the server. SDKs
  • Users shaped by your schema. A user schema in JSON Schema says which attributes your users have, which one they sign in with, which must be unique and which sign-in methods they may use. Every write is checked against it. Flows and schemas
  • Auth as code. Schemas, login flows, branding and sign-in connections are files in your repository. zitadel plan checks them against the server's rules before anything changes, and zitadel apply publishes them as immutable revisions. Plan and apply
  • Your brand, your words. Theme the login with --zl-* tokens and light and dark branding, or take over its markup with zitadel branding eject. Override any text per language; English, German and Italian are built in. Design, copy
  • A console. At /ui/console/, manage users through forms built from your schema, as well as teams and project admins, and look through your schemas, flows, sign-in methods and branding, with a live preview of the login.
  • Create first, claim later. zitadel setup --server https://preview.zitadel.com creates a hosted project without an account, and zitadel claim attaches it to your team within 14 days. Projects and teams
  • Runs anywhere. zitadel start runs the server from npm on your machine, with no Docker, Go or checkout, and signs you in to the console with a one-time link. To host it, take the binary for macOS, Linux or Windows or the image ghcr.io/zitadel/nextgen, with SQLite by default and PostgreSQL or Spanner in production. Local runtime, databases
  • Audit events. Sign-ins, sessions, users and configuration changes are recorded as typed events you can query through the API, and a self-hosted server can export them to a webhook. Events
  • One API for all of it. Every operation is in the API reference, with stable error codes. zitadel api calls any of them from the terminal, and @zitadel/api is a typed client with an error type per operation. API client
  • Built for agents. Every CLI command answers --json with one envelope. npx skills add zitadel/nextgen --full-depth installs Agent Skills for the CLI, the components and each SDK, and the docs come as llms.txt and over MCP. Agents
  • Tests against a real server. @zitadel/testing starts a local Zitadel for Playwright, with seeded users, signed-in pages and virtual passkeys.

Not there yet

  • Password recovery, email or SMS codes, TOTP, email verification and enforced MFA. The default flow covers sign-in and sign-up with passwords, passkeys and social sign-in.
  • Social sign-in is OIDC only, and a provider can't be linked to an existing account yet.
  • Zitadel doesn't issue OIDC or OAuth tokens to your apps in this preview: apps use its sessions through the SDKs, and the SPA frameworks need a proxy of your own in production.
  • Deploying a release to your own domains goes through the API; deploying to preview URLs, rollback and a CLI command for it are still to come.

Upgrading from 1.0.0-alpha.N

  • Install with @latest, for the CLI and every SDK; @alpha now points at 0.1.0 and stays there. npm sorts 0.1.0 below 1.0.0-alpha.28, so Renovate and Dependabot won't offer this update: set the @zitadel/* versions in your package.json to 0.1.0 yourself. The GitHub releases v1.0.0-alpha.20 to .28 are now v0.1.0-alpha.20 to .28.
  • Security: an auth attempt could issue a session after verifying only the user's identifier (#2211). Upgrade the server, then revoke active sessions whose only factor is identifier. Step-up sign-in now needs the session's session_token as well as its session_id (#2166).
  • Breaking: a deploy that names a primary origin answers 400 with dep.invalid; deploy with targets: ["primary"] (#1736). Also check the new error codes for schema failures (req.invalid, #1894) and over-long passwords (user.password_policy_violation, #2107), and how POST /flow picks the release by Origin (#2043).

The changes listed below are the ones since 1.0.0-alpha.28, the last alpha.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: c621117bceb2

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:0.1.0
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 0.1.0
@zitadel/server 0.1.0
@zitadel/server-linux-x64 0.1.0
@zitadel/server-linux-arm64 0.1.0
@zitadel/server-darwin-x64 0.1.0
@zitadel/server-darwin-arm64 0.1.0
@zitadel/server-win32-x64 0.1.0
@zitadel/api 0.1.0
@zitadel/config 0.1.0
@zitadel/components 0.1.0
@zitadel/sdk-core 0.1.0
@zitadel/sdk-next 0.1.0
@zitadel/sdk-nuxt 0.1.0
@zitadel/sdk-react 0.1.0
@zitadel/sdk-vue 0.1.0
@zitadel/sdk-angular 0.1.0
@zitadel/sdk-solid 0.1.0
@zitadel/sdk-svelte 0.1.0
@zitadel/sdk-qwik 0.1.0
@zitadel/sdk-sveltekit 0.1.0
@zitadel/sdk-solid-start 0.1.0
@zitadel/sdk-qwik-router 0.1.0
@zitadel/sdk-tanstack-start 0.1.0
@zitadel/testing 0.1.0

Package Changes

@zitadel/cli

Minor Changes

  • #2187 114c32c Thanks @fforootd! - Add zitadel api, which calls any operation of the Zitadel API with your project's server and secret, including the ones no command covers yet. Name an operation by its operationId (zitadel api queryUsers) or its path (zitadel api /users/query), set query parameters and body fields with -F name=value, typed by the operation's schema, pass a whole body with --input, follow every page with --paginate, and preview the request as cURL with --dry-run. zitadel api ls lists the operations, and --json returns the response body as data. @zitadel/api exports the operations as data from @zitadel/api/generated/operations: each one's method, path, parameters, authentication and paging.

  • #2215 ab19e1e Thanks @fforootd! - Releases now publish to npm's latest tag as 0.x preview versions, starting at 0.1.0, instead of 1.0.0-alpha.N under alpha: run the CLI as npx @zitadel/cli@latest and install the SDKs with @latest. The 1.0.0-alpha.N versions are deprecated on npm. Until 1.0.0, a breaking change ships in a minor version, and its release note marks it Breaking:. zitadel setup pins the @zitadel/* packages it adds, and the commands it suggests, to the CLI's exact version on every release, and zitadel start --runtime docker runs the server image of that version.

Patch Changes

  • #2190 43b20ea Thanks @mridang! - zitadel setup now patches an existing SvelteKit, SolidStart, Qwik City or TanStack Start ...
Read more

Zitadel NextGen v0.1.0-alpha.28

Pre-release

Choose a tag to compare

@github-actions github-actions released this 20 Oct 20:15
5983d4b

Published to npm and ghcr.io as 1.0.0-alpha.28.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: 5983d4b581e6

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:1.0.0-alpha.28
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 1.0.0-alpha.28
@zitadel/server 1.0.0-alpha.28
@zitadel/server-linux-x64 1.0.0-alpha.28
@zitadel/server-linux-arm64 1.0.0-alpha.28
@zitadel/server-darwin-x64 1.0.0-alpha.28
@zitadel/server-darwin-arm64 1.0.0-alpha.28
@zitadel/server-win32-x64 1.0.0-alpha.28
@zitadel/api 1.0.0-alpha.28
@zitadel/config 1.0.0-alpha.28
@zitadel/components 1.0.0-alpha.28
@zitadel/sdk-core 1.0.0-alpha.28
@zitadel/sdk-next 1.0.0-alpha.28
@zitadel/sdk-nuxt 1.0.0-alpha.28
@zitadel/sdk-react 1.0.0-alpha.28
@zitadel/sdk-vue 1.0.0-alpha.28
@zitadel/sdk-angular 1.0.0-alpha.28
@zitadel/sdk-solid 1.0.0-alpha.28
@zitadel/sdk-svelte 1.0.0-alpha.28
@zitadel/sdk-qwik 1.0.0-alpha.28
@zitadel/sdk-sveltekit 1.0.0-alpha.28
@zitadel/sdk-solid-start 1.0.0-alpha.28
@zitadel/sdk-qwik-router 1.0.0-alpha.28
@zitadel/sdk-tanstack-start 1.0.0-alpha.28
@zitadel/testing 1.0.0-alpha.28

Package Changes

@zitadel/cli

Minor Changes

  • #2157 adf6453 Thanks @fforootd! - zitadel setup --dev-port <port> now moves an app that's already set up to another port instead of skipping it. It allows the new origin on the server, then updates the dev script or dev-server config, ZITADEL_ISSUER in .env.local and zitadel.json together, so an app whose port is taken (EADDRINUSE) signs in on the new port after one command. The README and AGENTS.md sections setup writes name this command.

  • #2071 fa301b9 Thanks @fforootd! - The dev proxies zitadel setup writes for React, Vue, Angular, Solid, Svelte
    and Qwik apps now keep the app's session in a cookie named after its project,
    __nextgen_session_<project id>, as the server SDKs do. On localhost, signing
    in to such an app no longer signs you out of the Console of zitadel start, and
    signing in to the Console no longer signs you out of the app. The project comes
    from ZITADEL_PROJECT_ID in .env.local; without it the proxy passes cookies
    through as before.

    For an app set up with an earlier CLI, run zitadel doctor --fix: it adds this
    to the dev proxy the CLI wrote, and zitadel doctor warns until then. (Running
    zitadel setup again leaves an app that is already set up alone.) A dev proxy
    changed by hand since is left as it is, and zitadel doctor says the hooks must
    be added by hand. A dev session from before the change is not carried over, so
    sign in to the app once more.

Patch Changes

  • #2056 d04f94b Thanks @fforootd! - Built-in schemas are now named under https://zitadel.com/schemas/v1, for example https://zitadel.com/schemas/v1/user-schema.json, instead of https://nextgen.com/api/schemas, a domain Zitadel does not own. The base is an identifier, not an address: the server never fetches a URL in either namespace. Existing projects need no change: a built-in schema's id resolves under either base everywhere the API reads one, including GET /schemas/{id}, a flow definition's user_schema, a release's schema pointer, the users list's schema filter, and bootstrap user documents. A server still configured with the previous base accepts the new ids too. Projects created by zitadel setup from now on reference the new URLs, so pair this CLI with a server from this release or later.

  • #2056 d04f94b Thanks @fforootd! - zitadel setup without --server, and the setup wizard's Zitadel Cloud choice, now target the hosted preview at https://preview.zitadel.com instead of https://api.zitadel.cloud. A project whose zitadel.json names a server keeps using that server.

  • #2144 122864a Thanks @fforootd! - A server zitadel start runs can now sign users in through an identity provider on this machine, such as a test provider on http://localhost:9400. start passes NEXTGEN_HTTPCLIENT_ALLOW_LIST=localhost,127.0.0.0/8,::1/128 to the server unless .env.local, .env or the shell sets it; set it empty to turn it off. auth-method sso enable no longer warns about a localhost issuer on such a server, and on a --runtime docker server it warns that the container cannot reach this machine's localhost.

  • #2153 21ac783 Thanks @fforootd! - zitadel plan shows an edit inside a list as the lines that changed. A flow's
    steps and a step's actions are matched by name, so adding a field to one step
    prints that one line under the step, with the untouched steps summarized as
    hidden, instead of the whole steps list removed and added again. Lists of
    values such as fields mark the items added or removed.

    zitadel apply and zitadel setup no longer rewrite your .zitadel/ files
    with what the server stored: after applying a connection, .zitadel/idps/*.json
    no longer gains pkce_enabled, token_endpoint_auth_method and
    id_token_mapping. A field you leave out reads as the server's default, so
    plan reports no change after an apply. The one file apply still rewrites,
    and lists in files_updated, is a flow whose user_schema pins a schema
    revision id the apply superseded.

  • #2145 4d63c44 Thanks @fforootd! - A Next.js app created by zitadel setup --framework next no longer logs Could not validate \instant`errors innext devon every request to/. The home page setup writes still redirects to /login, and now opts out of Next.js's instant-navigation check, which Cache Components (on by default in new Next.js apps) runs on every page. The @zitadel/sdk-nextREADME'sauth()examples now render the component that callsauth()insideand import it from@zitadel/sdk-next/server`, so they build with Cache Components on.

  • #2148 3d80fcb Thanks @fforootd! - The /login, /register and /profile pages that zitadel setup writes for a new Next.js app paint the sign-in page's dark background on the first paint, so they no longer show a white page before the sign-in form loads.

  • #2151 b53ef49 Thanks @fforootd! - Editors no longer flag zitadel.json for an unreachable schema. zitadel setup now writes the schema of zitadel.json to .zitadel/meta/project.json, next to the flow and user-schema dialects, and points the file's $schema at it, so editors validate the project configuration offline instead of trying to load https://schemas.zitadel.com/v2/project.schema.json, which never existed. In a project set up earlier, delete the $schema line from zitadel.json to silence the warning; only editors read it.

  • #2077 7c3d3dc Thanks @fforootd! - The Qwik meta-framework SDK is @zitadel/sdk-qwik-router, named after Qwik Router, which Qwik 2 renamed from Qwik City; it was never published as @zitadel/sdk-qwik-city. The CLI calls the framework qwik-router too (zitadel setup --framework qwik-router), and its docs page moved to /docs/sdks/qwik-router.

  • #2076 12b3226 Thanks @fforootd! - The server SDKs now count a session as signed in only when it belongs to the
    app's own project. A session of another project on the same server, such as a
    second app on the same host or the console of a local zitadel start, reads
    as signed out in protectedRoutes, auth() and getAuth(), and its cookie is
    left in place for the app it belongs to.

    The project comes from the new projectId middleware option, else
    ZITADEL_PROJECT_ID, else the framework's public project id variable
    (NEXT_PUBLIC_,...

Read more

Zitadel NextGen v0.1.0-alpha.25

Pre-release

Choose a tag to compare

@github-actions github-actions released this 13 Oct 20:44
3fa9a3b

Published to npm and ghcr.io as 1.0.0-alpha.25.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: 3fa9a3bdff9e

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:1.0.0-alpha.25
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 1.0.0-alpha.25
@zitadel/server 1.0.0-alpha.25
@zitadel/server-linux-x64 1.0.0-alpha.25
@zitadel/server-linux-arm64 1.0.0-alpha.25
@zitadel/server-darwin-x64 1.0.0-alpha.25
@zitadel/server-darwin-arm64 1.0.0-alpha.25
@zitadel/server-win32-x64 1.0.0-alpha.25
@zitadel/api 1.0.0-alpha.25
@zitadel/config 1.0.0-alpha.25
@zitadel/components 1.0.0-alpha.25
@zitadel/sdk-core 1.0.0-alpha.25
@zitadel/sdk-next 1.0.0-alpha.25
@zitadel/sdk-nuxt 1.0.0-alpha.25
@zitadel/sdk-react 1.0.0-alpha.25
@zitadel/sdk-vue 1.0.0-alpha.25
@zitadel/sdk-angular 1.0.0-alpha.25
@zitadel/sdk-solid 1.0.0-alpha.25
@zitadel/sdk-svelte 1.0.0-alpha.25
@zitadel/sdk-qwik 1.0.0-alpha.25
@zitadel/testing 1.0.0-alpha.25

Package Changes

@zitadel/cli

Minor Changes

  • #1406 46a366f Thanks @mridang! - Distribute the CLI's agent guidance as an installable Agent Skill. Any skills-compatible coding agent — Claude Code, Cursor, Copilot, Codex, and more — can now add it with npx skills add zitadel/nextgen --full-depth, giving the agent guided, always-current instructions for scaffolding and managing Zitadel auth with the zitadel CLI. The skill also ships inside the @zitadel/cli package.

  • #1366 025acc6 Thanks @mridang! - zitadel setup no longer limits onboarding to one social provider. The onboarding question is a multi-select rather than one choice, and declining is an empty selection rather than a "not now" option beside the providers. Each chosen provider is asked for its own client id and secret, gets its own connection file, and has its slug added to the schema and the login flow — which already carried sso_providers as a list. The summary and the --json payload report one entry per provider, so a publish that did not land names the provider it belongs to. --sso still takes a single provider: a scripted run pipes one secret on stdin, and sso enable adds the rest. The catalog ships one provider today, so this changes what the CLI supports rather than what a developer can pick right now — a second catalog entry is what makes the multi-select visible.

  • #1281 79527ed Thanks @mridang! - Add social sign-in to the CLI. zitadel sso enable --provider google configures an identity provider on an existing Project: it says what to register with the vendor and at which redirect URI, takes the client id and secret, writes .zitadel/idps/<slug>.json, enables sso on the user schema, and adds the provider button plus the steps and routes a provider round trip needs to every login flow that runs against that schema. The client secret is never a flag — it is prompted for, or piped in on stdin for a scripted run — and never written to disk: only its ${{ NAME }} reference reaches the connection file, and the value is published to the Project as an encrypted variable, which is where the engine resolves it from. zitadel setup asks the same question during onboarding, so a Project can start with Google rather than adding it afterwards, with --sso and --sso-client-id for scripted runs. Everything so far is local: publishing the connection needs identity provider support on the server, which is not in this release, so apply cannot upload a connection file yet and deleting one is not supported either. Enable the provider once that support ships.

  • #1358 67461ef Thanks @mridang! - @zitadel/sdk-qwik now targets Qwik 2: it declares a peer dependency on @qwik.dev/core (^2.0.0-beta.45) in place of @builder.io/qwik, so your app must be on Qwik 2 to use it. Qwik 2 runs on Vite 8. The widgets stay reactive to their props, mirroring the other framework SDKs.

    The CLI's Qwik support follows suit. zitadel setup now scaffolds and detects Qwik 2 apps: a new app is created on @qwik.dev/core and Vite 8 (no Vite 7 pin), and a Qwik 1 project is no longer auto-detected, since it cannot use the Qwik 2 SDK.

  • #1406 46a366f Thanks @mridang! - setup now decides where to scaffold with a plain rule instead of a maintained allowlist. A directory with a detected framework is integrated in place; an empty directory gets a fresh app; a non-empty directory with no framework stops and asks for --force. setup --force scaffolds a fresh app into a non-empty directory, moving the existing files aside and restoring everything the scaffold does not create. This removes the treadmill of allowlisting each tool's metadata (.gitignore, .zitadel, .claude, …) and lets you install the agent skill into a project directory and then scaffold there with an explicit --force.

  • #1371 0269f56 Thanks @IAM-marco! - zitadel setup and zitadel sso enable write the renamed SSO outcomes into the login flow: sso_authenticated and sso_user_not_found. user_already_exists keeps its name and is shared with the typed collision. On a flow an earlier version wrote, zitadel sso enable renames callback and identity_unknown to the new keys, so enabling another provider keeps the flow valid. If one of those old keys declares purpose or action, which the new keys refuse, the command stops with a validation error naming the step and the key, so you can remove them first. If a step the command edits already has an action named like an outcome it writes there (sso_authenticated, sso_user_not_found or user_already_exists), whether or not the flow still uses the old keys, the command stops with a validation error naming the step and the action, so you can rename that action first.

Patch Changes

  • #1383 4c07937 Thanks @mridang! - Human output can now be turned colourless with --no-color, and the NO_COLOR and FORCE_COLOR environment variables are honoured. This covers both the step logging and the highlighted commands, paths and ids, so piped and CI runs read cleanly; --color forces colour on.

  • #1456 3937a77 Thanks @mridang! - A platform request that gets no response is now reported reliably and can be cancelled.

    • @zitadel/api: the client throws a typed NetworkError (reason unreachable or timeout) when
      a request gets no response, alongside ApiError for a failing status. createZitadelClient
      takes an optional signal and timeoutMs; an aborted request rejects with the signal's reason.
    • @zitadel/cli: a refused, unresolvable or silent server reports E_NETWORK (exit 4) on every
      command, the same as a server answering 5xx; before, a failure worded differently by the fetch
      runtime fell through to E_VALIDATION (exit 3). Each request has a 30-second deadline, and
      Ctrl-C while one is waiting cancels it with the new E_CANCELLED (exit 130) instead of leaving
      the command hung behind a spinner.
  • #1383 4c07937 Thanks @mridang! - Every product command now accepts -v as the short form of --verbose, matching the convention agents already expect from curl, ssh, and wget. The long --verbose is unchanged, and the root --version keeps no short form, so nothing collides.

  • #1495 8c08f48 Thanks @mridang! - Show CLI warnings in both terminal and JSON output. --json results from claim, start, sso enable, setup, plan and apply now include warnings that were only printed to the terminal before.

  • #1429 7f95a7b Thanks @bastionstack! - Make the local journey work when the app lives inside the directory zitadel start ran in, and say how to cont...

Read more

Zitadel NextGen v0.1.0-alpha.24

Pre-release

Choose a tag to compare

@github-actions github-actions released this 07 Oct 23:08
e5074ac

Published to npm and ghcr.io as 1.0.0-alpha.24.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: e5074ac29917

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:1.0.0-alpha.24
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 1.0.0-alpha.24
@zitadel/server 1.0.0-alpha.24
@zitadel/server-linux-x64 1.0.0-alpha.24
@zitadel/server-linux-arm64 1.0.0-alpha.24
@zitadel/server-darwin-x64 1.0.0-alpha.24
@zitadel/server-darwin-arm64 1.0.0-alpha.24
@zitadel/server-win32-x64 1.0.0-alpha.24
@zitadel/api 1.0.0-alpha.24
@zitadel/config 1.0.0-alpha.24
@zitadel/components 1.0.0-alpha.24
@zitadel/sdk-core 1.0.0-alpha.24
@zitadel/sdk-next 1.0.0-alpha.24
@zitadel/sdk-nuxt 1.0.0-alpha.24
@zitadel/sdk-react 1.0.0-alpha.24
@zitadel/sdk-vue 1.0.0-alpha.24
@zitadel/sdk-angular 1.0.0-alpha.24
@zitadel/sdk-solid 1.0.0-alpha.24
@zitadel/sdk-svelte 1.0.0-alpha.24
@zitadel/sdk-qwik 1.0.0-alpha.24
@zitadel/testing 1.0.0-alpha.24

Package Changes

@zitadel/cli

Minor Changes

  • #1286 b633a22 Thanks @mridang! - Breaking: remove --environment (-e) from plan, apply and the resource commands (users, teams, sessions, events, grants, idps, projects, schemas, environments, releases, flow-definitions, branding). It accepted only development, preview or production — none of them a name the platform uses — and never reached the platform: its one effect was to read a server URL from environments.<name>.server in zitadel.json, a key nothing writes. Passing it now fails as an unknown flag; drop it from scripts. --server, ZITADEL_API_BASE and the top-level server in zitadel.json still choose the server, and environments list / environments get still read the platform's environments.

    The CLI therefore has no per-environment flag at all until the platform's environments settle, which is also why the new variables commands address the project level only. Their own --environment / --env never shipped.

  • #1297 7165d73 Thanks @peintnermax! - Setup no longer applies a login template, and the template catalog keeps
    only widget structure.

    • zitadel setup drops the "How should the login look?" question and the
      --design flag; passing --design now fails with E_VALIDATION and a
      hint pointing at app-side theming and branding eject. It embeds the
      maintained login component (a starting page for a new app, a drop-in for an
      existing one), writes nothing under .zitadel/branding/, and publishes no
      branding revision. The JSON envelope
      drops data.design, the summary drops the "Login design" row, and the next
      actions point at theming the component from your app, with
      branding eject as the opt-in for owning its template.
    • zitadel branding eject --design now offers centered (the default card)
      and minimal (the same form without card chrome). split, split-right
      and hero are removed: they were page layout around the same card, which
      belongs in your application, and asking for one fails with E_VALIDATION
      and a hint saying so. BRANDING_DESIGNS in @zitadel/config
      shrinks accordingly.
    • Revisions already published from split, split-right or hero keep
      rendering; the login still ships their chrome. The API reference for
      Branding.layout no longer lists the retired designs.

Patch Changes

  • #1296 1a05521 Thanks @IAM-marco! - The CLI documentation now explains the local admin admin@zitadel.localhost
    that zitadel start creates by default, the one-time console sign-in link it
    prints, the zitadel console command that prints a fresh link, and that on the
    default local runtime zitadel setup attaches the project to that admin's
    team, so zitadel claim reports it as already owned.

  • #1288 4bea70a Thanks @mridang! - Encode path parameters in the generated API client, so any id the API accepts can be fetched. Schema ids are the case that hit today: a schema's id is its $id, usually a URL such as https://nextgen.com/api/schemas/default-human-user.json. Sent raw, the // collapsed on a redirect and the request 404'd, so zitadel schemas get <id> failed for every URL id and the console's user list silently dropped its schema columns. zitadel schemas get also stops guessing what an id looks like: it used to read anything without sch_ or :// as an object type, which sent ids like urn:example:human down the wrong path. It now asks the server, and falls back to the object-type lookup only on a 404. Setup reconciliation and apply/plan schema fetches used to encode the id themselves to work around the same bug; that is gone, so the client encodes exactly once rather than sending %25 for every delimiter.

  • #1292 0a82bb1 Thanks @mridang! - Correct the grants command reference. The README still documented --principal-type and --principal-id on grants create, and principal_type / principal_id as filter fields on grants list, which the user and team locators replaced: grants create takes --relation as its only required field flag and names the principal through --data / --file, and grants list filters on user_id and team_id.

    grants create --help also no longer suggests grants create --relation viewer. A grant needs exactly one of user or team, which are nested objects no flag can carry, so that run was never a complete body. Any write command whose body needs a nested object or an array now offers only its --data and --file examples.

@zitadel/server

Minor Changes

  • #1319 5bac207 Thanks @IAM-marco! - Add the identity provider connection endpoints: POST /idps creates a
    connection for a new slug (201) or appends a revision to the existing one
    (200), with the document validated against idp-connection.json before it
    is stored and the identity fields (protocol, subject_claim, OIDC
    issuer, OAuth2 token_endpoint and userinfo_endpoint) fixed for the
    life of the connection. GET /idps/{id}, POST /idps/query (filter and
    sort by slug and created_at), GET /idps/{id}/revisions and
    GET /idps/revisions/{revision_id} read them. Writes emit idp.created
    and idp.updated audit events.

  • #1299 d05fa4c Thanks @peintnermax! - Choose the project you are working on in the console's project switcher. Teams, users, user schemas, login flows, branding and the project's own settings all follow the selected project, and the selection is part of the URL, so it survives a refresh and a shared link. With a single project the console selects it for you; with several, it opens the Projects overview so you can pick one.

    The sidebar lists Projects first, then the selected project's screens; the switcher's "All projects" link opens Projects too. A project's name and admins are under "Project settings" in the sidebar. Links to /projects/{id} still work: they open that project's settings with it selected.

  • #1319 5bac207 Thanks @IAM-marco! - Request decode errors keep the normalized req.invalid message and now
    carry details.fields: the dotted paths of the fields the request
    validation rejected, names only, never values or decoder text. For map
    fields the last path element is the client's own key.

  • #1215 91b1eb6 Thanks @vitorbari! - Releases can now be deployed to environments over the API.

    POST /deployments makes a release live on an environment, atomically: when the call returns, the environment runs the named release and an immutable record of the act exists; on any failure nothing changes. Deploying, promoting and rolling back are all this call — reason says which, defaulting to deploy, and a promotion records the environment it came from. The record keeps ids and timestamp top-level; the why-and-who (reason, a free-form message, `source_environment...

Read more

Zitadel NextGen v0.1.0-alpha.23

Pre-release

Choose a tag to compare

@github-actions github-actions released this 07 Oct 23:08
221ac81

Published to npm and ghcr.io as 1.0.0-alpha.23.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: 221ac815478e

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:1.0.0-alpha.23
container ghcr.io/zitadel/nextgen:latest

npm Packages

Package Version
@zitadel/cli 1.0.0-alpha.23
@zitadel/server 1.0.0-alpha.23
@zitadel/server-linux-x64 1.0.0-alpha.23
@zitadel/server-linux-arm64 1.0.0-alpha.23
@zitadel/server-darwin-x64 1.0.0-alpha.23
@zitadel/server-darwin-arm64 1.0.0-alpha.23
@zitadel/server-win32-x64 1.0.0-alpha.23
@zitadel/api 1.0.0-alpha.23
@zitadel/config 1.0.0-alpha.23
@zitadel/components 1.0.0-alpha.23
@zitadel/sdk-core 1.0.0-alpha.23
@zitadel/sdk-next 1.0.0-alpha.23
@zitadel/sdk-nuxt 1.0.0-alpha.23
@zitadel/sdk-react 1.0.0-alpha.23
@zitadel/sdk-vue 1.0.0-alpha.23
@zitadel/sdk-angular 1.0.0-alpha.23
@zitadel/sdk-solid 1.0.0-alpha.23
@zitadel/sdk-svelte 1.0.0-alpha.23
@zitadel/sdk-qwik 1.0.0-alpha.23
@zitadel/testing 1.0.0-alpha.23

Package Changes

@zitadel/cli

Minor Changes

  • #1210 48351c4 Thanks @mridang! - Add resource commands to the CLI. users, teams, sessions, events, grants, and projects each gain the operations their API supports — users the full set, teams the same with deactivate in place of delete, sessions list, get and revoke, grants list, get, create and delete, projects list, get and update, and events list and get. idps gains list, get and create, and schemas, environments, releases, flow-definitions and branding gain list and get only: they are authored as files and shipped through a release, so the CLI reads them and never writes them. Every list shares one --filter field=operation:value grammar regardless of whether the endpoint takes a query body or query parameters, with each field declaring the operations it accepts so an unsupported one is refused locally rather than as a server error. Cursor pagination, --fields to choose columns, per-field flags on writes, local schema validation, --dry-run, and a --force guard on destructive verbs are the same everywhere. schemas list and flow-definitions list show the current revision of each rather than the full history, with --filter revisions=all for the history, and schemas get and flow-definitions get accept the object type or flow name as well as a revision id. zitadel resources reports the whole surface in one call.

    Breaking: schemas list is now generated from the same registry as every other list. Its --json envelope changes from { object_type, revisions, count } to the standard { items, count, next_page_token }; --object-type becomes an optional --filter object_type=<value> rather than a required flag; and the interactive revision picker is gone, since schemas get <id> reads one revision. A bare schemas list still returns the complete revision history.

  • #1224 1162dc9 Thanks @mridang! - A branding descriptor now points at its login template with "liquid_template": { "$file": "./login.liquid" } instead of a separate liquid_template_file key. The CLI replaces any $file reference with the file's content before publishing and writes the published value back into the file afterwards. branding eject and setup --design scaffold the new form, and a descriptor that still carries liquid_template_file fails zitadel plan with a hint showing the replacement.

  • #1187 a41c594 Thanks @mridang! - The project's env files now configure the local server.

    zitadel start reads .env.local, then .env, and hands every NEXTGEN_* variable to the server it launches: through the process environment on the binary backend and as bare --env NAME on Docker. No value ever reaches the command line, .zitadel/local/runtime.json, logs, or --json output; only the names are recorded, as env.injected, and zitadel status reports them. The address, data directory and public base the CLI sets itself always win. A running runtime is not updated in place, so after changing a value run zitadel stop and zitadel start.

    setup now writes a comment at the top of the scaffolded .env.example and .env.local saying so.

  • #1249 116e037 Thanks @mridang! - Group the root help by purpose. zitadel, zitadel --help, and zitadel help now list commands under "Project commands", "Local server commands", and "Configuration commands" in journey order, with oclif's own utilities under "Additional commands", followed by flags, examples, and where to learn more, in the layout of gh --help. Nested commands such as schemas list and branding eject are listed inline; the uninstall alias and help are not. Per-command help and --json output are unchanged.

  • #1274 1feea7d Thanks @mridang! - Identify the CLI in the User-Agent of its HTTP requests — Zitadel API calls, local-server health checks and branding asset probes — so server logs and session records can tell CLI traffic and CLI versions apart. Requests used to carry Node's bare node; they now send zitadel-cli/<version> node/<version> <os>/<release> arch/<arch>, followed by ci/<provider> when running in CI and host/<name> when running under a detected host such as Claude Code, Cursor or VS Code, e.g. zitadel-cli/1.0.0 node/v24.12.0 darwin/24.6.0 arch/arm64 host/claude_code. The ci/ and host/ tokens are left out when telemetry is opted out with --no-telemetry, DO_NOT_TRACK or ZITADEL_TELEMETRY=0.

  • #1259 a5a9046 Thanks @mridang! - Manage per-environment variables and secrets from the CLI with zitadel variables list|get|set|delete. Each command names its owner with --environment (alias --env) or --project-level, and a non-interactive run that names neither is refused rather than defaulted.

  • #1224 1162dc9 Thanks @mridang! - The branding and flow definition editor schemas now flag what the server rejects: asset URLs that carry user:password@, typography.font_url without typography.font_family, a terminal step that also collects or acts, a step that does nothing, sso_providers without a callback transition, and a transition that sets both purpose and action. The API client's Zod schemas reject credentials in branding asset URLs, and zitadel plan measures asset URL length in bytes, as the server does.

  • #1116 f118796 Thanks @grvijayan! - Flow definitions sync as revisions. An edited flow file plans as a revise and apply publishes a new immutable revision instead of updating in place. A schema revise re-publishes the flows pinned to it with the new user_schema in the same run. Removing a flow file no longer deletes the flow on the platform; apply fails with E_NOT_IMPLEMENTED instead.

  • #1156 84d1c4b Thanks @grvijayan! - Social login gets its configuration contracts. zitadel setup now copies two more dialect files into .zitadel/meta/: idp-connection.json, the schema for a provider connection file, and sso-auth-method.json, the shape of the sso slot in a user schema. A user schema with sso.enabled: true must now list the connection slugs its users may sign in with under sso.providers, and a disabled slot must not carry the list. In a flow definition, identity_unknown is a reserved transition outcome that switches a login flow to register when a provider returns an unknown user.

  • #1225 b0e0f02 Thanks @mridang! - zitadel start now boots the local server with the platform project and a local admin, so you exist on your own server without signing up, and prints a one-time link that signs you in to the console. The new zitadel console command mints a fresh link whenever you need one; the console honours such a link only when it is served from loopback. A local zitadel setup attaches the new project to the admin's ...

Read more

Zitadel NextGen v0.1.0-alpha.22

Pre-release

Choose a tag to compare

@github-actions github-actions released this 09 Sep 14:31
009f19d

Published to npm and ghcr.io as 1.0.0-alpha.22.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: 009f19dda49e

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:1.0.0-alpha.22

npm Packages

Package Version
@zitadel/cli 1.0.0-alpha.22
@zitadel/server 1.0.0-alpha.22
@zitadel/server-linux-x64 1.0.0-alpha.22
@zitadel/server-linux-arm64 1.0.0-alpha.22
@zitadel/server-darwin-x64 1.0.0-alpha.22
@zitadel/server-darwin-arm64 1.0.0-alpha.22
@zitadel/server-win32-x64 1.0.0-alpha.22
@zitadel/api 1.0.0-alpha.22
@zitadel/config 1.0.0-alpha.22
@zitadel/components 1.0.0-alpha.22
@zitadel/sdk-core 1.0.0-alpha.22
@zitadel/sdk-next 1.0.0-alpha.22
@zitadel/sdk-nuxt 1.0.0-alpha.22
@zitadel/sdk-react 1.0.0-alpha.22
@zitadel/sdk-vue 1.0.0-alpha.22
@zitadel/sdk-angular 1.0.0-alpha.22
@zitadel/sdk-solid 1.0.0-alpha.22
@zitadel/sdk-svelte 1.0.0-alpha.22
@zitadel/sdk-qwik 1.0.0-alpha.22
@zitadel/testing 1.0.0-alpha.22

Package Changes

@zitadel/cli

Minor Changes

  • #1147 893364c Thanks @IAM-marco! - Clearer claim journey output: commands now sit on their own styled line in the setup box, separated from the prose so they can be copied without surrounding words, the end-of-setup notice states the concrete deadline (date, time, and zone) until which the temporary project can be claimed, terminal boxes wrap to the window width instead of breaking their frame below 80 columns, and zitadel claim explains a closed 14-day claim window instead of suggesting a futile retry. zitadel setup now also nudges against a local server when that server hosts the platform plane (probed via its runtime document), where the claim can actually complete; the offline surfaces (status, doctor) keep their cloud-only nudges.

@zitadel/server

Minor Changes

  • #1169 c7c737a Thanks @bastionstack! - Land the claim page on sign-up with a claim-window countdown, drop passkeys from the shipped default login flow, and fix three sign-in surface defects found in design QA.

    A developer opening a claim link from zitadel claim normally has no account on the deployment yet, so the claim page now enters the flow with purpose="register"; the register step's own sign_in action carries the returning developer back. Beside every state of that page it shows how long the project can still be claimed, read from the new unauthenticated GET /projects/{project_id}/claim/window?challenge_id=..., so an expired claim link no longer reads as an expired project. The sign-in widget grows an attribution-trailing slot for it: the design has always drawn a badge beside the "Secured with Zitadel" trustmark, and the widget could not fill it because nothing on a flow response carries a duration — a host that has one can now put it there, and an embed that ignores the slot renders exactly as before.

    The shipped password-first login flow no longer offers passkey on identifier/password or passkey_register on register — the passkey legs proved unreliable in testing, and the passkey-first preset remains the way to offer them.

    Three fixes to the sign-in surface itself: the alert's error icon keeps its 16px size and centres on the first line of text instead of shrinking under a long message and floating above a short one; a terminal step that is about to navigate no longer paints a "you are signed in" screen the host immediately replaces, so one sign-in produces one confirmation; and the sign-up card gains the subtitle every other step already had.

  • #1093 82186ce Thanks @grvijayan! - Flow definitions are revisioned: POST /flow_definitions publishes a new
    revision on every call, so a repeated name no longer returns 409, and
    GET /flow_definitions accepts a name filter that lists one flow's
    revisions newest first.

  • #1118 c3fbdee Thanks @adlerhurst! - Add POST /grants/query to list a project's collaboration grants, with always-on user-ref or team-ref labels and an opt-in expand: ["principal"] that embeds the GET user or GET team body.

  • #1155 af21963 Thanks @vitorbari! - The events API defines the release.created event type and its payload.

    The payload carries the release's content_hash, its audit metadata (message, git_sha, git_dirty) and the (kind, handle, revision_id) tuples the release pins, so an audit stream answers what a release changed without reading the releases table. Nothing emits the event until POST /releases is implemented.

  • #1115 472a182 Thanks @vitorbari! - Adds persistence support for releases — immutable, project-scoped configuration snapshots that pin one revision of each resource they include.

    Release records store their pinned revisions and assembly metadata. A project-scoped content-hash index prevents duplicate snapshots and provides the storage contract needed for idempotent release orchestration in a follow-up.

  • #1146 e04e3ce Thanks @IAM-marco! - Unclaimed projects can now only be claimed within 14 days of creation. After that, claim init and complete return 410 proj.claim_window_expired (distinct from the retryable proj.claim_expired challenge error), and claim status reports the same final 410 for a pending challenge, taking precedence over challenge expiry so polling clients stop suggesting a futile retry. The claim grant is the status route's source of truth: a project claimed through another concurrent challenge reports completed with its owning team, never a false expiry verdict. Nothing is deleted when the window closes.

    Separately, default-project resolution (the console runtime document and the bare hosted login) now skips the built-in platform project in its first-created heuristic: a deployment that once ran with platform.bootstrap_project and later disabled it resolves its first real project instead of the leftover platform row. Explicit platform.project_id configuration is unchanged.

Patch Changes

  • #1134 c0bef04 Thanks @muhlemmer! - createProject response now includes the project name field.

  • #1150 fce5a75 Thanks @vitorbari! - Fix three sign-in dead ends. Choosing "sign in with a passkey" on a password
    step no longer treats the password box the browser posts alongside it as a
    submission, so the WebAuthn prompt appears instead of a required-field or
    invalid-credentials error. Going back to the identifier step now releases the
    user resolved by the abandoned attempt, so re-entering an address signs in
    normally instead of failing with "The user was already authenticated". And
    signing up with an address that already has an account now completes: that
    sign-in reached the final step without a handoff token, leaving the user
    unable to exchange it for a session.

  • #1136 1f5e7b9 Thanks @muhlemmer! - Flow submit endpoint now rejects requests with unrecognized top-level properties instead of silently ignoring them.

  • #1135 4a637a3 Thanks @muhlemmer! - instrumentation.log.level, instrumentation.log.format, and instrumentation.log.streams now accept string names (e.g. debug, json, request) in addition to numeric values.

@zitadel/api

Minor Changes

  • #1093 82186ce Thanks @grvijayan! - Flow definitions are revisioned: POST /flow_definitions publishes a new
    revision on every call, so a repeated name no longer returns 409, and
    GET /flow_definitions accepts a name filter that lists one flow's
    revisions newest first.
    ...
Read more

Zitadel NextGen v0.1.0-alpha.21

Pre-release

Choose a tag to compare

@github-actions github-actions released this 09 Sep 14:31
fa28cb9

Published to npm and ghcr.io as 1.0.0-alpha.21.

Generated Release Facts

This section is maintained by release automation. Edit product notes outside this block.

Release commit: fa28cb9632df

Container Images

Image Reference
container ghcr.io/zitadel/nextgen:1.0.0-alpha.21

npm Packages

Package Version
@zitadel/cli 1.0.0-alpha.21
@zitadel/server 1.0.0-alpha.21
@zitadel/server-linux-x64 1.0.0-alpha.21
@zitadel/server-linux-arm64 1.0.0-alpha.21
@zitadel/server-darwin-x64 1.0.0-alpha.21
@zitadel/server-darwin-arm64 1.0.0-alpha.21
@zitadel/server-win32-x64 1.0.0-alpha.21
@zitadel/api 1.0.0-alpha.21
@zitadel/config 1.0.0-alpha.21
@zitadel/components 1.0.0-alpha.21
@zitadel/sdk-core 1.0.0-alpha.21
@zitadel/sdk-next 1.0.0-alpha.21
@zitadel/sdk-nuxt 1.0.0-alpha.21
@zitadel/sdk-react 1.0.0-alpha.21
@zitadel/sdk-vue 1.0.0-alpha.21
@zitadel/sdk-angular 1.0.0-alpha.21
@zitadel/sdk-solid 1.0.0-alpha.21
@zitadel/sdk-svelte 1.0.0-alpha.21
@zitadel/sdk-qwik 1.0.0-alpha.21
@zitadel/testing 1.0.0-alpha.21

Package Changes

@zitadel/cli

Patch Changes

  • #1127 a24ec4d Thanks @IAM-marco! - zitadel claim against a CLI-launched local server (--server local) now opens the claim page on the local server itself instead of a remote default: the CLI passes the server's public base when it starts the binary or docker runtime. When a manually started loopback server still advertises a remote claim page, claim warns and names the NEXTGEN_SERVER_PUBLIC_BASE setting to fix it.

  • #1085 a59b288 Thanks @livio-a! - Session responses identify their user through a resolved user ref derived
    from the user schema's own x-identifier/x-display designations (ADR 058),
    replacing the convention-resolved flat name/email fields this supersedes
    (see the earlier GET /sessions/me identity changeset). Rendering follows one
    chain everywhere: display, falling back to identifier, then user_id.

    • @zitadel/server: GET /sessions/me, session get, and query sessions embed
      user ({user_id, identifier, identifier_property, display}), the list
      path hydrated with one batch resolution per page — listed sessions now carry
      user identity at all. The conventional attribute-name resolver
      (name/givenName+familyName/email) is removed.
    • @zitadel/api: the regenerated client types the new user ref component.
    • @zitadel/components: <zitadel-session>/<zitadel-logout> render from
      the ref; the zitadel-signout detail is now {display, identifier};
      logout templates substitute {{display}}/{{identifier}} (the old
      {{name}}/{{email}} tokens keep filling as aliases).
    • @zitadel/sdk-core (and every SPA SDK via the shared contract):
      NextgenSession/ClientSession become {userId, identifier, identifierProperty, display}; JWT-claim identities map name → display
      and email → identifier.
    • @zitadel/sdk-next / @zitadel/sdk-nuxt: server and client session reads
      return the new shape.
    • @zitadel/cli: scaffolded Nuxt auth plugins emit the new fields.

    Breaking: the flat name/email session fields and the old SDK session
    shape are gone. An unknown property is dropped rather than rejected, so a
    client left on the old fields reads silently empty values instead of failing
    loudly — update server, SDKs, and app chrome together.

@zitadel/server

Minor Changes

  • #1124 6b59d5a Thanks @bastionstack! - Show each user's teams in the console users list. The memberships ride along on
    POST /users/query with expand: ["teams"], so the column costs no request per
    row, and a user on more teams than the embedded list carries says so rather than
    presenting the cap as the whole roster. A credential that may not read
    memberships keeps the list and loses the column.

  • #1085 a59b288 Thanks @livio-a! - Session responses identify their user through a resolved user ref derived
    from the user schema's own x-identifier/x-display designations (ADR 058),
    replacing the convention-resolved flat name/email fields this supersedes
    (see the earlier GET /sessions/me identity changeset). Rendering follows one
    chain everywhere: display, falling back to identifier, then user_id.

    • @zitadel/server: GET /sessions/me, session get, and query sessions embed
      user ({user_id, identifier, identifier_property, display}), the list
      path hydrated with one batch resolution per page — listed sessions now carry
      user identity at all. The conventional attribute-name resolver
      (name/givenName+familyName/email) is removed.
    • @zitadel/api: the regenerated client types the new user ref component.
    • @zitadel/components: <zitadel-session>/<zitadel-logout> render from
      the ref; the zitadel-signout detail is now {display, identifier};
      logout templates substitute {{display}}/{{identifier}} (the old
      {{name}}/{{email}} tokens keep filling as aliases).
    • @zitadel/sdk-core (and every SPA SDK via the shared contract):
      NextgenSession/ClientSession become {userId, identifier, identifierProperty, display}; JWT-claim identities map name → display
      and email → identifier.
    • @zitadel/sdk-next / @zitadel/sdk-nuxt: server and client session reads
      return the new shape.
    • @zitadel/cli: scaffolded Nuxt auth plugins emit the new fields.

    Breaking: the flat name/email session fields and the old SDK session
    shape are gone. An unknown property is dropped rather than rejected, so a
    client left on the old fields reads silently empty values instead of failing
    loudly — update server, SDKs, and app chrome together.

  • #1092 7a06425 Thanks @livio-a! - User responses carry the derived identity of ADR 058 §3a: the envelope
    gains read-only identifier, identifier_property, and display,
    resolved live from each user's own schema designations
    (x-identifier/x-display) on every read path — query users (one batch
    resolution per page), get by id, users/me, and the create read-back.
    Clients render display, falling back to identifier, then id, with
    zero designation logic of their own. The embedded console (shipped inside
    @zitadel/server) renders them: the users list gains a leading User
    identity column on exactly that chain plus a dedicated role-named
    Identifier column (platform-derived, outside the schema-driven column
    set), the user detail heads with the identity, and the console's
    convention-based display-name guesser is removed.

Patch Changes

  • #1126 21beee0 Thanks @IAM-marco! - The server now mints claim and dashboard URLs from a dedicated server.public_base setting (env NEXTGEN_SERVER_PUBLIC_BASE, default https://nextgen.zitadel.cloud) instead of deriving them from the schema identity namespace. Deployments reachable at another origin — a local server most of all — set the new key and zitadel claim opens the right console instead of a dead nextgen.com address. A misconfigured base (query, fragment, userinfo, or a non-http(s) scheme) now fails at startup instead of leaking into every minted URL.

  • #1090 941645e Thanks @livio-a! - Internal plumbing for ADR 058 §3/§4: the user-ref resolution primitives
    (designation readers, domain.ResolveUserRef, and the batched
    (project_id, user_ids) → refs resolution port) and the inert user-ref
    wire component. No endpoint behavior changes yet — session adoption ships
    separately.

@zitadel/api

Minor Changes

  • #1085 a59b288 Thanks @livio-a! - Session responses identify their user through a resolved user ref derived
    from the user schema's own x-identifier/x-display designations (ADR 058),
    replacing the convention-resolved flat name/email fields this supersedes
    (see the earlier GET /sessions/me identity changeset). Rendering follows one
    chain everywhere: display, falling back to identifier, then user_id.
    • @zitadel/server: GET /sessions/me, session get, and query sessions embed
      user (`{user_id, identifier, identifier_property, dis...
Read more