2026-02-08-how-to-run-zitadel-in-docker-for-iam - where is the zitadel-login service

[mooncaptain108]

How does this work without the login service?
Please explain.

[simlarsen]

Good catch - you're right that a login service is missing, and on current Zitadel it matters.

Since Zitadel v4 (GA mid-2025), the login UI is no longer bundled in the main ghcr.io/zitadel/zitadel image. It was rewritten as Login V2, a standalone Next.js application shipped as its own image, ghcr.io/zitadel/zitadel-login (listens on port 3000, served under /ui/v2/login). It runs as its own container, talks to the core over the API, and authenticates as a machine user (login-client) holding the IAM_LOGIN_CLIENT role using a PAT that the core auto-generates on first startup.

The important part: new v4 instances default to LoginV2 Required=true, so the core redirects every sign-in to /ui/v2/login. In the single-container setup this post used, nothing was serving that path, so the interactive console login broke (the API itself still works). And because ghcr.io/zitadel/zitadel:latest now points to v4.x, anyone following the post today hits this. In Zitadel v2/v3 the login was rendered by the core at /ui/login, so a single container was enough - that's the era the post was written for.

Two ways to get a working login:

1. Run the separate zitadel-login container alongside the core, behind a reverse proxy that serves both under one origin. This is the supported v4 architecture (it's what Zitadel's official deploy/compose/docker-compose.yml does).
2. Stay on the legacy bundled login by setting ZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIRED=false, which makes the core serve Login V1 at /ui/login again. Handy for quick local evaluation. (Login V1 still ships in v4 but is on a deprecation path for a future major.)

I've updated the post to cover both - the quick start uses option 2 for a simple single-container eval, and the production section now shows the full v4 architecture with the zitadel-login container and a Traefik proxy. Fix is in #152. Thanks for flagging it!

[simlarsen]

This is now fixed and merged in #152.

The post explains the change and shows both setups:

• Quick start (single container) uses ZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIRED=false so the bundled legacy login works at /ui/login for quick evaluation.
• Production runs the proper Zitadel v4 architecture: the core, the separate ghcr.io/zitadel/zitadel-login (Login V2) container, and a Traefik reverse proxy, with the login-client PAT auto-bootstrapped.

Images are also pinned to v4.15.3 so :latest rolling to a new major won't silently break it again. Thanks for reporting!