Self Hosted Azure Container Apps - "Database "zitadel" already exists"
Hey folks, i'm currently trying to deploy both Zitadel and Postgres out to an Azure Container App Environment as part of a PoC. I am able to deploy both containers to the environment using Terraform, however, when the Zitadel container executes the defined
start-init command, I get logs stating that the Zitadel database already exists. I also get logs stating that certain aspects of Zitadels config exist too (roles for example) before the container ultimately hangs. As I am just proving out elements of deployment, I'm deploying both to the same container app environment, both are freshly deployed each time, and i'm using env vars instead of config files. There are no volumes being mounted for the db container, as well as no sidecars or init containers. Initial thinking was maybe two zitadel containers where triggering the same init process on my single postgres instance, but after forcing just a single replica with a single container across both I still see the same issue. I have attached the terraform i'm using (obfuscating anything relating to my azure subscription) for reference, as well as the logs messages i'm seeing for both the postgres container and zitadel container. Fully anticipate I'm doing something daft, so any help is greatly appreciated!
(I'm also able to run the stack locally using compose, its just when I deploy to Azure its giving me errors.)
5 Replies
just adding to this. Zitadel ran its migration steps to completion and failed on the with the following error:
caller="/home/runner/work/zitadel/zitadel/internal/migration/migration.go:130" migration step=03_default_instance
2025-05-21T15:03:41.320888397Z time="2025-05-21T15:03:41Z" level=warning msg="migration already started, will check again in 5 seconds" caller="/home/runner/work/zitadel/zitadel/internal/migration/migration.go:130" migration step=03_default_instance
2025-05-21T15:03:46.337929022Z time="2025-05-21T15:03:46Z" level=warning msg="migration already started, will check again in 5 seconds" caller="/home/runner/work/zitadel/zitadel/internal/migration/migration.go:130" migration step=03_default_instance
2025-05-21T15:03:51.352744665Z time="2025-05-21T15:03:51Z" level=warning msg="migration already started, will check again in 5 seconds" caller="/home/runner/work/zitadel/zitadel/internal/migration/migration.go:130" migration step=03_default_instance
2025-05-21T15:03:56.366716725Z time="2025-05-21T15:03:56Z" level=warning msg="migration already started, will check again in 5 seconds" caller="/home/runner/work/zitadel/zitadel/internal/migration/migration.go:130" migration step=03_default_instance
2025-05-21T15:04:00.659689460Z time="2025-05-21T15:04:00Z" level=error msg="migration failed" caller="/home/runner/work/zitadel/zitadel/cmd/setup/setup.go:345" error="ID=MIGR-as3f7 Message=Errors.Internal" name=03_default_instance
2025-05-21T15:04:00.659782133Z time="2025-05-21T15:04:00Z" level=fatal msg="setup failed, skipping cleanup" caller="/home/runner/work/zitadel/zitadel/cmd/setup/setup.go:124" error="migration failed: ID=MIGR-as3f7 Message=Errors.Internal"
I have looked through https://github.com/zitadel/zitadel/blob/main/internal/migration/migration.go to see what was causing the MIGR-as3f7 error code but not sure exactly where the implementation for this step is. Any help is greatly appreciated!GitHub
zitadel/internal/migration/migration.go at main · zitadel/zitadel
ZITADEL - Identity infrastructure, simplified for you. - zitadel/zitadel
For anyone that happens to stumble across this in the future, got there in the end! Turns out that the
EXTERNAL_DOMAIN i was using was incorrect n the container app. I think the zitadel 03 migration that runs on start up to configure the default instance was just timing out due to being unable to resolve the DNS I was using. Pure hypothesis and no evidence however! When I set this env var to localhost in the CAE, it made the replica go green. There was a log message within Zitadel which showed the origin of the request i made though the ingress and that it didnt match what was configured. Using this log, i set the env var to be container_name.cae_default_domain in my terraform and I can now navigate successfully to the deployed console.Hey there @Andy! Thanks for being so transparent with your process here in your thread - This will be extremely helpful for anyone else who encounters this issue. Is there anything that could have been done on our end via our documentation to make this a bit easier for you to navigate?
No worries @Raccine! A terraform template would've helped a lot here I think. The container app environment within azure wasn't really the problem, it was more just me fumbling the terraform and zitadel configuration trying to collate configuration from other docs for a deployed environment as the configuration is slightly different than running locally. The Zitadel docs are great as they are btw as I was able to use the other articles to piece something together here, but having tf example would've expedited things. I'm more than happy to contribute to anything around this if it helps too!