As you, the reader, found this article, it is likely that you want to manually migrate the ZITADEL PostgreSQL database to a new version.

Now, normally this step is being done by the zitadel setup command with the --init-projections=true flag but, as we all know since “2001: A Space Odyssey”, computers can’t be trusted - so you are either paranoid or something went terribly wrong.

For manually updating the database, we should first understand the structure a bit. So far, the Zitadel Team seems to use versioning for their tables - meaning they create a new table for every change instead of just altering the current table. This leads to some beautifully structured schemas full of tables like users6, users7 and users8 up to users10.

In the last days I tried to integrate multiple OpenID Connect Providers into my Applications (currently mostly Alphalerts and some dev projects)

So far, I only got Google to work, and even this is currently limited to 100 Users. In this blog post, I want to explain why the integration of OpenID Connect Providers is such a struggle by showing multiple examples.

But before I show the examples, you should know that there are not so many big OpenID Connect Providers compared to the big OAuth2 Providers. E.g. GitHub offers OAuth2, but is not a OpenID Connect Provider yet.

In this Guide, I want to cover installing ZITADEL with PostgreSQL on a Linux system. Please be aware that PostgreSQL support is still in Beta at the time of this writing, and you will need a PostgreSQL installation with Version 14 or higher.

NGINX Proxy

Create a new subdomain and point it to your server. Use certbot -d domain.name for creating a new SSL Cert. Create a new file in /etc/nginx/sites-available/domainname

Imagine you run a company and provide multiple web applications for your customers. In the beginning, you probably created a user table and the authentication methods yourself, but from the second application onwards, you will think about using already made open source solutions.

That’s the situation I am in right now. I run multiple web applications, which each have their own auth mechanisms and user tables. This means, a user from App1 can’t use App2 unless he creates a new account.