Login V2 + self-hosted: is the login container mandatory, and how does the console log in?
š¬Self-hostedāQuestionā
Solved
Setup
- Zitadel v4.16.0 via docker compose, single
No
- Config managed with Terraform (zitadel/zitadel provider v3.3.0).
- We have our own login UI inside our Next.js app. It drives the Session API
and links with POST /v2/oidc/auth_requests/{id}. We do not want a hosted UI
for our end users.
What we found
1. Setting
the V1 URL
POST /v2/oidc/auth_requests with 404.
2. Only the instance feature
flow works.
3. But the flag is instance-wide, so the management console also routes to
/ui/v2/login ā which 404s, because nothing serves that path. The console
becomes unreachable once the existing session cookie lapses.
Questions
- Is the
purely so the console has a login page ā even if our own apps never use a
hosted UI?
- Is there a supported way to keep the console on V1 while our apps get V2
auth requests? Per-app
but had no effect without the instance flag.
- If the container is required, is running it on a separate port (with
baseUri pointing there) supported, or is a single-origin reverse proxy
expected?
- Zitadel v4.16.0 via docker compose, single
zitadelzitadel container + Postgres.No
zitadel-loginzitadel-login container, no reverse proxy. API on http://localhost:8080.- Config managed with Terraform (zitadel/zitadel provider v3.3.0).
- We have our own login UI inside our Next.js app. It drives the Session API
and links with POST /v2/oidc/auth_requests/{id}. We do not want a hosted UI
for our end users.
What we found
1. Setting
login_version { login_v2 {} }login_version { login_v2 {} } per OIDC app (Terraformzitadel_application_oidczitadel_application_oidc) alone does nothing ā /authorize still returnsthe V1 URL
/ui/login/login?authRequestID=.../ui/login/login?authRequestID=..., and that id is rejected byPOST /v2/oidc/auth_requests with 404.
2. Only the instance feature
login_v2.required = truelogin_v2.required = true (Terraformzitadel_instance_featureszitadel_instance_features) switches it. Then /authorize returns/ui/v2/login/login?authRequest=V2_.../ui/v2/login/login?authRequest=V2_... and the v2 API resolves it. Our BFFflow works.
3. But the flag is instance-wide, so the management console also routes to
/ui/v2/login ā which 404s, because nothing serves that path. The console
becomes unreachable once the existing session cookie lapses.
Questions
- Is the
zitadel-loginzitadel-login container mandatory whenever loginV2.required = true,purely so the console has a login page ā even if our own apps never use a
hosted UI?
- Is there a supported way to keep the console on V1 while our apps get V2
auth requests? Per-app
login_versionlogin_version looked like it should do exactly that,but had no effect without the instance flag.
- If the container is required, is running it on a separate port (with
baseUri pointing there) supported, or is a single-origin reverse proxy
expected?
