Env variable doesn't get applied to default organization
I have an issue: I have applied this env variable in the compose file of zitadel --> ZITADEL_DEFAULTINSTANCE_LOGINPOLICY_ALLOWREGISTER: false. To exclude any "influence" of other files I just have in the command: "start-from-setup --config /secrets.yaml --masterkey ${MASTER_KEY} --tlsMode external" where secrets.yaml only contains username for DB. But as you can see in the screenshot, it is still set to true. I am onkly using the default organization called Zitadel, so I think this env variable applies to default organization, right?
15 Replies
Any idea?
Can anyone please help me with this?
the default variable is on the instance settings, and all organizations use per those per default. but you can overwrite them for a specific organization. did you check the default settings in the instance?
Hi @happyHyppo! Following up to see if you were able to check out the default settings?
@fabienne @Raccine Hi thanks for the response 🙂 If I am not mistaken, I sent the screenshot of the default organization because I am only using the default one (ZITADEL). I will confirm you later and provide you with more data when I finish working 🙂
@Raccine @fabienne For example: I have applied the following settings for password complexity as env variables
But this is what I see in the UI, it seeems like the env variable is not applied
I have many examples likes this, also for other env variables that are not set correctly
Did you change that after you have setuped the instance?
Good question: There a couple of settings that I needed to change so I changed them manually but for example, I have setup SMTP with env variables but I can't see any "client" under the SMTP settings
@fabienne @Raccine I can confirm that this behaviour applies to SMTP (where I did not manually set any setting). I've added the env variables for SMTP in the docker compose, restarted the compose but the settings are not applied to the default as you can see from the second screenshot
as zitadel can do multiple instances in one system, the default instance referees to the default that is triggered as settings when you setup a new instance. the first instance you setup is defined in the firstinstance --> steps.yaml, do you maybe have something else there?
Thanks for the explanation. So It means that if I only use the default instance aka Zitadel organization, then I need to defines the settings I want in the steps.yaml?
@fabienne Can you please confirm this?
default instance is not the zitadel organization. as zitadel is build to have multiple instances. e.g a prod, dev and test instance. it means when start the first instance, for example dev it triggers the steps.yaml, when you create new instances through the system api, the defaults yaml triggers tos setup your instance
@fabienne How can I know what instance am I running? Should I define it somewhere? To be honest I don't remember what files I used when I first started using Zitadel, but I modified the docker compose since then and I now I ended up with the following startup command:
@fabienne By instance: do you mean, running zitadel server?
ZITADEL is capable of running multiple virtual instances, usually you only run one. https://zitadel.com/docs/concepts/structure/instance#multiple-virtual-instances