Initial User not supported

Hi Zitadel team

I'm self-hosting Zitadel (latest image from

ghcr.io/zitadel/zitadel:latest

ghcr.io/zitadel/zitadel:latest

ghcr.io/zitadel/zitadel:latest

ghcr.io/zitadel/zitadel:latest) using the

start-from-init

start-from-init

start-from-init

start-from-init command and setting all relevant

ZITADEL_FIRSTINSTANCE_*

ZITADEL_FIRSTINSTANCE_*

ZITADEL_FIRSTINSTANCE_*

ZITADEL_FIRSTINSTANCE_* environment variables.

Here’s what works:

Zitadel starts successfully behind Caddy reverse proxy (HTTP internally, TLS terminated externally).
Login UI v2 is working and shows the user selection screen.
I can register and log in with new users just fine.
I verified that the initial admin user was created — confirmed via:

```sql
SELECT * FROM projections.login_names3;
But here’s the problem:
When I enter the correct login name (admin@companyx.auth.companyx.com) in the login v2 UI, I get:

"Initial User not supported"

If I disable login v2 (ZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIRED=false), I get redirected to a password reset page that attempts to send a verification email instead — not what I expect for the first admin.

ZITADEL_FIRSTINSTANCE_ORG_NAME=companyx
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_USERNAME=admin
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORD=SuperSecurePW123!
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_EMAIL=admin@companyx.com
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_FIRSTNAME=Super
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_LASTNAME=User
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORDCHANGEREQUIRED=false
ZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIRED=true

What am I missing to make the initial admin login work with login v2?

Do I need to mark the human user as initialized, verified, or do something else via CLI/API after startup?

Or is there a required flag/env for login-v2 support for the first instance user?

Any help is appreciated

Ask Inkeep•10/13/25, 3:26 PM

Hi @Blazespectre, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•10/13/25, 3:26 PM

Answer

I wasn't able to find a direct answer, here are some relevant sources:

Self-Hosted: {"code":5, "message":"Not Found"} : This GitHub issue discusses similar problems with Login V2 on self-hosted instances and suggests disabling Login V2 as a workaround by setting ZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIREDZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIRED to
```
false
```
```
false
```
.
Set up Zitadel with Docker Compose : This documentation shows the proper environment variable configuration for Docker Compose setup including Login V2 settings.

Ask Inkeep•10/13/25, 3:26 PM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep Empty message

Ask InkeepAPP•10/13/25, 3:32 PM

Got it. Tagging @Rajat for additional help.

BlazespectreOP•10/13/25, 4:20 PM

I configured the initial admin user via environment variables. However, I was only able to log in successfully after removing the following variables from my .env file:

ZITADEL_FIRSTINSTANCE_ORG_HUMAN_EMAIL
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_FIRSTNAME
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_LASTNAME
ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORDCHANGEREQUIRED=false

With these variables included, the login screen (Login V2) would show the user account selection, but after clicking the user, it would not ask for a password. It would simply fail with a message saying "Initial User not supported."

Once I commented out the four variables above and re-deployed, the login worked correctly. I was prompted to change the initial password, and everything proceeded as expected.

So my question is:
Is this behavior intentional? Or is this a known issue/bug when combining Login V2 with the extended initial user fields?

Would be great to get official clarification or guidance. Thanks.

Rajat•12/15/25, 4:30 PM

hey @Blazespectre does this issue still persists?. We made few updtaes to Login V2 so curious to see if yiou tried again?. Thanks