Keycloak vs authentik vs Zitadel na jednym VPS

Który serwer SSO wybrać dla jednego VPS

Keycloak, authentik oraz Zitadel to serwery typu single sign-on (SSO) do samodzielnego hostowania, które pojawiają się w każdej dyskusji o ujednoliceniu logowania do wszystkich aplikacji na serwerze. Na pojedynczym, małym VPS nie są one jednak zamienne. authentik stanowi bezpieczny wybór domyślny dla serwera z trzema lub czterema aplikacjami, ponieważ jako jedyny z tej trójki potrafi wyświetlić ekran logowania przed aplikacją, która nie posiada własnego mechanizmu uwierzytelniania. Keycloak jest właściwym rozwiązaniem, gdy każda chroniona aplikacja obsługuje standardowy protokół, a zasoby pamięci pozwalają na uruchomienie maszyny wirtualnej Java (JVM). Zitadel został zaprojektowany z myślą o programistach dostarczających produkt przez API i jest rozwiązaniem, którego nie zaleca się uruchamiać na serwerze z mniej niż 4 GB pamięci RAM.

Najpierw dokonaj wyboru, a następnie przystąp do instalacji. Po wybraniu odpowiedniego narzędzia, praktyczna instalacja authentik na VPS opisuje proces konfiguracji krok po kroku.

Ile pamięci RAM faktycznie wymaga każda z nich?

Należy zacząć od minimalnych zasobów, ponieważ to one decydują o krótkiej liście kandydatów, zanim jeszcze weźmie się pod uwagę funkcje. Poniższe liczby to oficjalne dane opublikowane przez twórców projektów w sierpniu 2026 roku. Są to wytyczne producenta, a nie wyniki testów obciążeniowych.

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

Strona instalacji authentik przy użyciu Docker Compose wymaga „hosta z co najmniej 2 rdzeniami CPU i 2 GB pamięci RAM”, co daje 2048 MB, a opublikowany plik compose uruchamia 3 kontenery: PostgreSQL, serwer oraz worker.

Keycloak podaje najbardziej precyzyjną wartość 3. Przewodnik dotyczący doboru zasobów wskazuje, że „podstawowe zużycie pamięci przez Pod, wliczając pamięć podręczną danych Realm i 10 000 sesji, wynosi 1250 MB RAM”. Te 1250 MB obejmują sam proces Java, jeszcze przed uwzględnieniem bazy danych. Ta sama strona wyjaśnia, dlaczego limit kontenera ma tak duże znaczenie: Keycloak rezerwuje 70% limitu pamięci na stertę (heap) i wykorzystuje dodatkowo około 300 MB pamięci poza stertą. Jeśli przydzielisz kontenerowi 1 GB, obliczy on stertę o wielkości około 717 MB, nadal wymagając 300 MB pamięci poza stertą, więc limit zostanie wyczerpany, zanim jakiekolwiek dane sesji trafią do pamięci podręcznej.

Strona projektu Zitadel dotycząca compose również wymaga 2 GB, czyli tych samych 2048 MB, jednak jest to wartość dla pierwszego uruchomienia. Należy zapoznać się ze stroną dotyczącą środowiska produkcyjnego. Sam proces Zitadel wymaga „około 512 MB RAM i może działać przy mniej niż jednym rdzeniu CPU”. Baza danych jest najbardziej kosztownym elementem: „około jeden rdzeń CPU na 100 żądań na sekundę (req/s) i 4 GB RAM na rdzeń”. Haszowanie haseł wymaga „4 rdzeni CPU dostępnych do tego celu”, ponieważ nagły wzrost liczby logowań powoduje skok obciążenia procesora. Oficjalny plik compose w wersji v4 uruchamia 4 kontenery, zanim dodasz cokolwiek innego: Traefik jako proxy, API Zitadel, oddzielny kontener interfejsu logowania oraz PostgreSQL. Redis i kolektor OpenTelemetry znajdują się w opcjonalnych profilach compose.

Zatem Keycloak i authentik zmieszczą się na VPS z 4 GB RAM, pozostawiając miejsce na chronione aplikacje. Zitadel uruchomi się na 2 GB, ale przy każdym logowaniu będzie konkurował o pamięć z własną bazą PostgreSQL. Nie uruchamiałbym Zitadel na maszynie z mniej niż 4 GB RAM, a na serwerze hostującym również inne aplikacje zalecałbym 8 GB.

Co faktycznie działa na serwerze

authentik składa się z bazy PostgreSQL oraz dwóch kopii tego samego obrazu: serwera i procesu roboczego (worker). Serwer obsługuje ruch HTTP i zawiera wbudowany outpost. Proces roboczy wykonuje zadania w tle, takie jak synchronizacja katalogów czy wysyłka wiadomości e-mail. Opublikowana instrukcja instalacji jest zwięzła.

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

Serwer udostępnia porty 9000 oraz 9443. Pierwsze połączenie z portem 9000 uruchamia proces wstępnej konfiguracji, w którym ustawia się hasło dla domyślnego użytkownika akadmin. Przed udostępnieniem tego portu w Internecie należy umieścić przed nim reverse proxy z poprawnym certyfikatem.

Keycloak to jeden proces oraz zewnętrzna baza danych. Szybki start wymaga pojedynczego kontenera.

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.7.1 start-dev

Opcja start-dev służy do testów. Uruchamia się ona z lokalną bazą danych typu development i bez TLS (transport layer security), więc kontener uruchomiony w ten sposób i później usunięty spowoduje utratę konfiguracji realm. Środowisko produkcyjne wymaga użycia start, z rzeczywistą bazą PostgreSQL poprzez KC_DB oraz publiczną nazwą hosta przez KC_HOSTNAME. Przewodnik produkcyjny Keycloak wskazuje również, że cała komunikacja z serwerem wymaga bezpiecznego kanału, więc HTTPS nie jest tam opcjonalny.

Zitadel to stos czterech kontenerów opisany powyżej.

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

Przed pierwszym uruchomieniem należy ustawić ZITADEL_MASTERKEY w pliku .env. Jest to 32-znakowy klucz, którego Zitadel używa do szyfrowania danych w bazie, więc jego utrata oznacza brak dostępu do tych informacji. Jeśli obsługa takich stosów jest nowym zagadnieniem, podstawy Docker Compose na VPS wyjaśniają wybór wolumenów oraz polityki restartu, które decydują o tym, czy dostawca tożsamości przetrwa restart systemu.

Jakie protokoły obsługuje każde z rozwiązań?

Wszystkie trzy obsługują OpenID Connect (OIDC), warstwę logowania opartą na OAuth 2.0, wykorzystywaną przez nowoczesne aplikacje, oraz SAML 2.0 (Security Assertion Markup Language), starszy standard, w którym nadal dostarczane jest oprogramowanie klasy enterprise. Różnica pojawia się w przypadku LDAP (Lightweight Directory Access Protocol), gdzie jedno określenie obejmuje dwa przeciwstawne zadania.

Odczyt z LDAP oznacza, że serwer SSO weryfikuje hasła w katalogu, który już jest utrzymywany. Keycloak realizuje to poprzez federację użytkowników. Zitadel również to umożliwia: dokumentacja opisuje sposób „podłączenia serwera LDAP jako dostawcy tożsamości w ZITADEL”.

Obsługa LDAP (jako serwer) oznacza, że aplikacja komunikująca się wyłącznie przez LDAP może uwierzytelnić się w serwerze SSO tak, jakby był on katalogiem. Tylko authentik oferuje taką funkcjonalność. Jego dostawca LDAP sprawia, że „wszyscy użytkownicy i grupy w bazie danych authentik są przeszukiwalni przez katalog LDAP” za pośrednictwem dedykowanego outpostu LDAP, z dostępnym LDAPS na porcie 636. Jest to rozwiązanie tylko do odczytu, więc operacje bind i search działają, natomiast zapis nie jest możliwy. Kod jednorazowy jest dołączany do hasła za pomocą średnika, jak w password;123456, a uwierzytelnianie SMS nie jest wspierane podczas operacji bind.

Jeśli jedna z aplikacji na liście obsługuje wyłącznie LDAP, porównanie kończy się w tym miejscu. Keycloak i Zitadel nie obsłużą takiego zapytania bind, więc konieczne byłoby uruchomienie drugiego katalogu obok nich i utrzymywanie synchronizacji dwóch list użytkowników.

Co z aplikacjami, które w ogóle nie posiadają logowania?

Rozwiązaniem jest forward auth, z czym serwery self-hosted stykają się nieustannie. Reverse proxy pyta serwer SSO, czy żądanie jest dozwolone, zanim przekaże je do backendu. Aplikacja znajdująca się za proxy nie otrzymuje żadnych informacji o SSO. Odbiera ona żądania już zweryfikowane przez proxy, zazwyczaj z nazwą użytkownika przekazaną w nagłówku.

Dostawca proxy w authentik obsługuje ten scenariusz w trzech udokumentowanych trybach. Tryb "Proxy" sprawia, że outpost authentik samodzielnie przekazuje ruch do aplikacji nadrzędnej. "Forward auth (single application)" pozostawia obsługę ruchu w istniejącym reverse proxy, wykorzystując authentik wyłącznie do weryfikacji uwierzytelnienia. "Forward auth (domain level)" chroni wszystkie aplikacje w ramach jednej domeny nadrzędnej za pomocą pojedynczego dostawcy. Tryb domenowy jest wygodny, ale posiada udokumentowane ograniczenie: "nie pozwala na egzekwowanie różnych reguł autoryzacji na poziomie aplikacji dla każdej z nich", więc wszystkie aplikacje w tej domenie współdzielą jeden zestaw polityk.

Keycloak nie posiada takich funkcji. Jego towarzyszący komponent, Keycloak Gatekeeper, został przemianowany na Louketo Proxy, a następnie zarchiwizowany w serwisie GitHub; ostatni commit pochodzi z sierpnia 2023 roku. Aby zabezpieczyć aplikację bez wsparcia OIDC, należy uruchomić przed nią oddzielny komponent, zazwyczaj oauth2-proxy, wskazujący na klienta Keycloak. Zitadel również nie posiada własnego trybu forward auth, więc rozwiązaniem jest instalacja, monitorowanie i aktualizacja tego samego dodatkowego komponentu.

Ten dodatkowy krok sprawia, że konfiguracja reverse proxy przestaje być prosta, dlatego przed wpięciem middleware uwierzytelniającego warto przeczytać jak Traefik obsługuje kilka aplikacji Docker Compose.

Jak trudna jest ścieżka aktualizacji?

Według stanu na sierpień 2026 r. aktualne wydania to Keycloak 26.7.1, authentik 2026.5.6 oraz Zitadel v4.16.3. Wszystkie trzy wykonują migracje schematu w bazie PostgreSQL, co oznacza, że każda aktualizacja wiąże się ze zmianą struktury bazy danych. Przed każdą operacją należy wykonać kopię zapasową bazy danych. Ten jeden nawyk jest cenniejszy niż jakakolwiek funkcja opisana w tym porównaniu.

authentik stosuje najbardziej rygorystyczne zasady i jasno je komunikuje: „Aktualizacje muszą odbywać się zgodnie z kolejnością wydań głównych; nie należy przechodzić bezpośrednio ze starszej wersji głównej do najnowszej”. Należy przejść do najnowszej poprawki w ramach każdej wersji przed przejściem do kolejnej, a „authentik nie wspiera procedury przywracania starszej wersji”. Pozostawienie projektu z wersjonowaniem kalendarzowym o rok w tyle zamienia jedną aktualizację w cały łańcuch operacji, z których każda wymaga własnej migracji bazy danych.

Przewodnik aktualizacji Keycloak określa wymaganą kolejność: należy przejrzeć zmiany migracyjne z poprzedniej wersji, zaktualizować serwer, a następnie zaktualizować adaptery. Migracja bazy danych przebiega automatycznie, można ją również wyeksportować i zastosować ręcznie, co jest przydatne, gdy użytkownik chce zapoznać się ze zmianami przed ich wprowadzeniem. Kosztem w przypadku Keycloak jest właśnie ta konieczność lektury. Informacje o wydaniu zawierają opisy wycofywania funkcji i zmiany w zachowaniu, które łatwo przeoczyć, a których pominięcie może być kosztowne.

Zitadel oddziela fazy inicjalizacji i konfiguracji od działającego serwera, a wytyczne produkcyjne zalecają utrzymywanie ich w rozdzielności, aby skalowanie nie powtarzało procesu konfiguracji. Na pojedynczym VPS oznacza to głównie, że krok konfiguracji musi zakończyć się przed zgłoszeniem przez API stanu gotowości, dlatego plik compose zawiera testy kondycji (health checks), a polecenie startowe wykorzystuje --wait.

Dla kogo przeznaczony jest każdy z projektów i gdzie traci na znaczeniu

Keycloak to serwer tożsamości firmy Red Hat, stworzony dla organizacji korzystających z realmów, grup, mapowania ról oraz istniejących katalogów korporacyjnych. Jest to najbardziej kompletna implementacja standardów spośród całej trójki. Traci na znaczeniu w przypadku VPS o pojemności 2 GB, na którym działa kilka usług self-hosted, z których połowa nie obsługuje OIDC. Użytkownik zużywa 1250 MB pamięci RAM na JVM, uczy się modelu realmów zaprojektowanego dla przedsiębiorstw, a i tak musi zainstalować oauth2-proxy dla aplikacji, na których faktycznie mu zależy.

authentik został stworzony z myślą o użytkownikach self-hosting, co widać po liście funkcji. Oferuje forward auth, dostawcę LDAP oraz wizualny edytor przepływów logowania. Traci na znaczeniu, gdy wymagane jest wsparcie techniczne producenta lub cykl wydawniczy, który nie zmienia się co kilka tygodni. Wersjonowanie oparte na dacie, brak ścieżki downgrade'u oraz brak możliwości pomijania wersji generują realne obciążenie operacyjne, a edytor przepływów stanowi cały model do opanowania, podczas gdy rzeczywistym problemem jest obsługa jednego klienta OIDC.

Zitadel został stworzony dla programistów wdrażających uwierzytelnianie w produktach, które dostarczają swoim klientom. Posiada rozbudowane API oraz wielodostępność (multi-tenancy) jako kluczowe funkcje. Traci na znaczeniu dokładnie w tym scenariuszu. Cztery kontenery, brak forward auth oraz baza danych wymagająca 4 GB na rdzeń to niewłaściwa konfiguracja dla pojedynczego serwera VPS, na którym uruchomiono menedżer haseł i wiki.

Co uruchomić na jednym VPS i w jaki sposób

W przypadku jednego serwera VPS z trzema lub czterema własnymi aplikacjami, należy uruchomić authentik. Wszystkie trzy rozwiązania zapewniają ekran logowania. Czynnikiem decydującym jest fakt, że niektóre aplikacje nie obsługują protokołu OIDC, a authentik rozwiązuje ten problem za pomocą wbudowanego mechanizmu forward auth, zamiast wymagać dodatkowego komponentu.

Należy przydzielić 4 GB pamięci RAM, jeśli to możliwe, a 2 GB tylko w przypadku, gdy towarzyszące aplikacje są niewielkie. Port 9000 powinien być niedostępny z publicznego Internetu, a terminację TLS należy przeprowadzić na reverse proxy znajdującym się przed usługą. Należy wykonywać nocne zrzuty bazy PostgreSQL i przechowywać je poza serwerem, ponieważ dostawca tożsamości bez kopii zapasowej stanowi pojedynczy punkt awarii dla każdej chronionej aplikacji. Cały stos należy uruchamiać na dedykowanym koncie z ograniczonymi uprawnieniami, zamiast jako root: konfiguracja użytkowników z minimalnymi uprawnieniami na VPS zawiera informacje o wymaganej konfiguracji konta i własności plików.

Keycloak należy wybrać, gdy każda chroniona aplikacja obsługuje już OIDC lub SAML, albo gdy wymagany jest szczegółowy model ról oferowany przez realms w Keycloak. Zitadel należy wybrać w przypadku tworzenia aplikacji dla użytkowników zewnętrznych, gdzie istotny jest model API oraz obsługa wielu najemców (tenant model). Żadne z tych rozwiązań nie pasuje do scenariusza trzech aplikacji na jednym serwerze, który jest przedmiotem tego artykułu.

Najczęstsze przyczyny awarii

Keycloak nie posiada danych po restarcie. Uruchomiono go za pomocą start-dev, co wykorzystuje lokalną bazę danych typu development. W kontenerze bez podmontowanego wolumenu usunięcie kontenera powoduje utratę realm. Należy przejść na start z parametrem KC_DB=postgres wskazującym na właściwą bazę danych.

Kontener worker aplikacji authentik znika na małym serwerze. Kontener worker oraz server korzystają z tego samego obrazu i oba uruchamiają procesy Python, podczas gdy PostgreSQL wymaga zasobów na hoście o pojemności 2 GB. Należy wykonać docker compose ps, aby potwierdzić, która usługa została zatrzymana, a następnie sprawdzić dmesg pod kątem zdarzeń typu out-of-memory kill, zanim rozpocznie się poszukiwanie błędu w samej aplikacji.

Konsola Zitadel nie działa za proxy. API Zitadel korzysta z gRPC, co wymaga obsługi HTTP/2 aż do backendu. Dokumentacja wymaga użycia reverse proxy wspierającego połączenia HTTP/2 upstream i wymienia przetestowane wersje: Traefik v3.x, NGINX v1.x, Caddy v2.x oraz Apache httpd 2.4.x. Proxy, które degraduje połączenie do HTTP/1.1, powoduje, że strona logowania ładuje się poprawnie, natomiast sama Konsola przestaje działać.

Każda aplikacja przekierowuje z powrotem do ekranu logowania. Publiczny adres URL serwera SSO oraz adres URL skonfigurowany w aplikacji muszą być identyczne, włącznie ze schematem i portem. Keycloak określa to jako ustawienie hostname, a Zitadel jako external domain. W przypadku rozbieżności aplikacja przekierowuje do logowania, którego serwer nie rozpoznaje jako własnego, co powoduje zapętlenie przeglądarki między tymi dwoma adresami.

FAQ

Które z tych trzech rozwiązań pasuje na VPS z 2 GB RAM?

authentik oraz Keycloak. Wymagania systemowe dla authentik określają minimum 2 rdzenie CPU oraz 2 GB pamięci RAM, natomiast przewodnik doboru rozmiaru dla Keycloak wskazuje bazowe zapotrzebowanie serwera na poziomie 1250 MB, nie wliczając bazy danych. Oba rozwiązania działają w sposób ograniczony na 2 GB RAM po dodaniu chronionych aplikacji, dlatego 4 GB należy traktować jako bezpieczne minimum. Zitadel podaje 2 GB jako wartość dla pierwszego uruchomienia, jednak wytyczne produkcyjne zalecają 4 rdzenie CPU do haszowania haseł oraz 4 GB RAM na rdzeń bazy danych, co oznacza, że 2 GB nie jest realną konfiguracją wdrożeniową.

Czy Keycloak lub Zitadel mogą chronić aplikację, która nie posiada własnego mechanizmu logowania?

Nie samodzielnie. Żadne z tych rozwiązań nie dostarcza wbudowanego komponentu forward auth. Starszy towarzyszący projekt Keycloak, Louketo Proxy, został zarchiwizowany w serwisie GitHub, a jego ostatni commit pochodzi z sierpnia 2023 roku, więc nie należy na nim opierać infrastruktury. W takim przypadku należy umieścić oauth2-proxy lub podobny komponent pomiędzy reverse proxy a aplikacją, wskazując go na klienta OIDC na serwerze SSO. authentik realizuje to natywnie za pomocą dostawcy proxy w trybie "Forward auth (single application)" lub "Forward auth (domain level)".

Które z nich może pełnić rolę serwera LDAP dla aplikacji obsługującej wyłącznie ten protokół?

authentik. Jego dostawca LDAP działa w ramach outpost i umożliwia przeszukiwanie użytkowników oraz grup z authentik za pośrednictwem LDAP, z obsługą LDAPS na porcie 636. Jest to rozwiązanie typu read-only, co oznacza, że operacje bind i search działają, natomiast zapis nie jest możliwy. Keycloak i Zitadel działają w przeciwnym kierunku: oba odczytują dane z istniejącego katalogu LDAP jako źródło użytkowników i żaden z nich nie odpowiada na zapytania LDAP bind pochodzące z aplikacji.

Czy podczas aktualizacji authentik można pomijać wersje?

Nie. Dokumentacja stanowi, że aktualizacje muszą odbywać się zgodnie z kolejnością wydań głównych (major releases) i nie należy przechodzić bezpośrednio ze starszej wersji głównej do najnowszej. Należy najpierw przejść do najnowszego wydania poprawkowego (patch release) w ramach każdej wersji, a następnie aktualizować o jeden poziom wzwyż. Przed każdym krokiem należy wykonać kopię zapasową PostgreSQL, ponieważ authentik nie wspiera procedury przywracania starszej wersji (downgrade), a migracje bazy danych są jednokierunkowe.