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.

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.

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.