Keycloak, authentik czy Zitadel na jednym VPS

Który serwer SSO wybrać na jeden VPS

Keycloak, authentik oraz Zitadel to serwery typu self-hosted single sign-on (SSO), które pojawiają się w każdej dyskusji o ujednoliceniu logowania do wszystkich aplikacji na serwerze. Na pojedynczym, małym VPS nie są one 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ł stworzony z myślą o programistach dostarczających produkt przez API i jest rozwiązaniem, którego nie zaleca się uruchamiać przy mniej niż 4 GB pamięci RAM.

Najpierw wybierz rozwiązanie, a następnie przystąp do instalacji. Po dokonaniu wyboru, praktyczna instalacja authentik na VPS zawiera szczegółowy opis konfiguracji krok po kroku.

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

Należy zacząć od minimalnych zasobów, ponieważ to one determinują listę kandydatów jeszcze przed analizą funkcji. Poniższe liczby to oficjalne dane publikowane przez twórców projektów, odczytane 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 dla 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 doboru zasobów wskazuje, że „podstawowe zużycie pamięci dla poda, wliczając pamięć podręczną danych Realm i 10 000 sesji, wynosi 1250 MB RAM”. Te 1250 MB obejmują sam proces Java, 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 zużywa dodatkowo około 300 MB pamięci poza stertą (non-heap). Przydzielenie kontenerowi 1 GB skutkuje obliczeniem sterty na około 717 MB, przy jednoczesnym zapotrzebowaniu na 300 MB pamięci non-heap, więc limit zostaje wyczerpany, zanim jakiekolwiek dane sesji trafią do pamięci podręcznej.

Strona compose dla Zitadel 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) oraz 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 przed dodaniem jakichkolwiek dodatków: Traefik jako proxy, API Zitadel, osobny kontener Login UI 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 zapas dla chronionych aplikacji. Zitadel uruchomi się na 2 GB, ale przy każdym logowaniu będzie rywalizować o pamięć z własną bazą PostgreSQL. Nie zaleca się uruchamiania Zitadel przy mniej niż 4 GB, a na serwerze hostującym również inne aplikacje, wskazane jest 8 GB.

Co faktycznie uruchamia się na serwerze

authentik składa się z bazy danych 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 procedurę wstępnej konfiguracji, w której 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 opiera się na pojedynczym kontenerze.

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

Tryb start-dev służy do wstępnego zapoznania się z oprogramowaniem. Działa on z lokalną bazą danych typu development i bez TLS (transport layer security), dlatego kontener uruchomiony w ten sposób i później usunięty spowoduje utratę całego realm. Wdrożenie produkcyjne wymaga użycia start, zewnętrznej bazy PostgreSQL poprzez KC_DB oraz publicznej nazwy hosta skonfigurowanej w KC_HOSTNAME. Dokumentacja produkcyjna 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ą wybory dotyczące wolumenów i 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 wciąż stosowany w oprogramowaniu klasy enterprise. Różnica pojawia się w przypadku LDAP (Lightweight Directory Access Protocol), gdzie jedno określenie odnosi się do dwóch odmiennych funkcji.

Odczyt z LDAP oznacza, że serwer SSO weryfikuje hasła w oparciu o istniejący katalog użytkowników. Keycloak realizuje to poprzez federację użytkowników. Zitadel również oferuje taką funkcjonalność: 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 uwierzytelniać się w serwerze SSO tak, jakby był on katalogiem. Tylko authentik posiada tę funkcję. Jego dostawca LDAP sprawia, że „wszyscy użytkownicy i grupy w bazie danych authentik są przeszukiwalni przez katalog LDAP” za pośrednictwem dedykowanego punktu dostępowego (outpost), z LDAPS dostępnym na porcie 636. Jest to rozwiązanie typu read-only, więc operacje bind i search działają, natomiast zapis nie jest możliwy. Kod jednorazowy należy dopisać do hasła po średniku, zgodnie z password;123456, a uwierzytelnianie przez 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 odpowiedzą na takie zapytanie 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 którym 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 backendowej. "Forward auth (single application)" pozostawia obsługę ruchu w gestii istniejącego 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 najwygodniejszy, ale posiada udokumentowane ograniczenie: "nie pozwala na egzekwowanie różnych reguł autoryzacji na poziomie aplikacji dla każdej z chronionych usług", co oznacza, że wszystkie aplikacje w danej domenie współdzielą jeden zestaw polityk.

Keycloak nie posiada wbudowanych takich mechanizmów. Jego towarzyszące proxy, Keycloak Gatekeeper, zostało przemianowane na Louketo Proxy, a następnie zarchiwizowane 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 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. Zawsze należy najpierw wykonać kopię zapasową bazy danych. Ten jeden nawyk jest cenniejszy niż jakakolwiek funkcja opisana w tym porównaniu.

authentik posiada najbardziej rygorystyczne zasady i jasno je określa: „Aktualizacje muszą przebiegać 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”. Pozostanie w tyle o rok w projekcie z wersjonowaniem kalendarzowym zamienia jedną aktualizację w cały ich łańcuch, z których każda wymaga własnej migracji bazy danych.

Przewodnik aktualizacji Keycloak wskazuje wymaganą kolejność: należy przejść przez 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 chce się zapoznać ze zmianami przed ich wprowadzeniem. Kosztem w przypadku Keycloak jest właśnie ta analiza. Informacje o wydaniu zawierają opisy wycofywanych funkcji i zmiany w zachowaniu, które łatwo pominąć, a których przeoczenie może być kosztowne.

Zitadel rozdziela fazy inicjalizacji i konfiguracji od działającego serwera, a wytyczne produkcyjne zalecają utrzymywanie ich w oddzieleniu, aby skalowanie nie powtarzało procesu konfiguracji. Na pojedynczym VPS oznacza to zazwyczaj, ż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 projekt i gdzie traci na znaczeniu

Keycloak to serwer tożsamości firmy Red Hat, stworzony z myślą o organizacjach 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 uruchomiono cztery własne aplikacje, z których połowa nie obsługuje OIDC. Użytkownik płaci 1250 MB pamięci RAM za JVM, uczy się modelu realmów zaprojektowanego dla przedsiębiorstwa, a mimo to musi zainstalować oauth2-proxy dla aplikacji, na których faktycznie mu zależało.

authentik został stworzony dla użytkowników hostujących własne usługi, co widać po liście jego funkcji. Dostarcza mechanizm forward auth oraz provider LDAP, a przepływy logowania buduje się w edytorze wizualnym. Traci na znaczeniu, gdy wymagana jest umowa wsparcia technicznego od dostawcy lub cykl wydawniczy, który nie zmienia się co kilka tygodni. Wersjonowanie oparte na dacie bez ścieżki powrotnej (downgrade) i możliwości pomijania wersji generuje realne obciążenie operacyjne, a edytor przepływów to cały model do opanowania w sytuacji, 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 funkcje priorytetowe. 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 działa jedynie menedżer haseł i wiki.

Co i jak uruchomić na jednym VPS

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 wtedy, gdy towarzyszące aplikacje są niewielkie. Port 9000 musi pozostać niedostępny z publicznego Internetu, a terminację TLS należy przeprowadzić na reverse proxy znajdującym się przed aplikacją. 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 aplikacji, którą zabezpiecza. Cały stos należy uruchomić na dedykowanym koncie z ograniczonymi uprawnieniami, zamiast jako root: konfiguracja użytkowników z minimalnymi uprawnieniami na VPS opisuje wymagania dotyczące konta i własności plików.

Należy wybrać Keycloak, gdy każda zabezpieczana aplikacja obsługuje już OIDC lub SAML, albo gdy wymagany jest szczegółowy model ról oferowany przez realm w Keycloak. Należy wybrać Zitadel w przypadku tworzenia aplikacji, do której rejestrują się inni użytkownicy, oraz gdy wymagane jest użycie API i modelu tenantów. Żaden z tych przypadków nie dotyczy scenariusza trzech aplikacji na jednym serwerze, który jest tematem tego wpisu.

Najczęstsze tryby awarii

Keycloak nie posiada danych po restarcie. Uruchomiono go za pomocą start-dev, co wykorzystuje lokalną bazę danych typu development. W kontenerze bez podpiętego 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 z 2 GB pamięci RAM. Należy wykonać docker compose ps, aby potwierdzić, która usługa została zatrzymana, a następnie sprawdzić dmesg pod kątem zdarzeń out-of-memory kill, zanim rozpocznie się poszukiwanie błędów w samej aplikacji.

Konsola Zitadel nie działa za proxy. API Zitadel wykorzystuje 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 obniża wersję połączenia do HTTP/1.1, powoduje, że strona logowania ładuje się poprawnie, ale Konsola przestaje działać.

Każda aplikacja przekierowuje z powrotem do ekranu logowania. Publiczny adres URL serwera SSO oraz adres skonfigurowany w aplikacji muszą być identyczne, wliczając w to schemat oraz port. 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 procesora oraz 2 GB pamięci RAM, natomiast przewodnik doboru rozmiaru dla Keycloak wskazuje bazowe zapotrzebowanie na poziomie 1250 MB dla samego serwera, przed uwzględnieniem bazy danych. W obu przypadkach 2 GB to wartość graniczna po dodaniu chronionych aplikacji, dlatego 4 GB należy traktować jako komfortowe minimum. Zitadel podaje 2 GB jako wartość dla pierwszego uruchomienia, jednak wytyczne produkcyjne zalecają 4 rdzenie procesora dla operacji haszowania haseł oraz 4 GB RAM na rdzeń bazy danych, co oznacza, że 2 GB nie jest realną konfiguracją dla środowiska produkcyjnego.

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

Nie samodzielnie. Żadne z tych rozwiązań nie zawiera wbudowanego komponentu typu forward auth. Starszy serwer proxy dla 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ć nowych wdrożeń. W takiej sytuacji należy umieścić oauth2-proxy lub podobny komponent pomiędzy reverse proxy a aplikacją i wskazać 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 protokół LDAP?

authentik. Jego dostawca LDAP działa w ramach outpost i umożliwia przeszukiwanie użytkowników oraz grup z authentik za pomocą protokołu 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 sekwencją wydań głównych (major releases) i nie należy przechodzić ze starszej wersji głównej bezpośrednio do najnowszej. Należy najpierw zaktualizować system do najnowszego wydania poprawkowego (patch release) w ramach bieżącej wersji, a następnie przechodzić o jedną wersję w górę. Przed każdym krokiem należy wykonać kopię zapasową PostgreSQL, ponieważ authentik nie wspiera procedury przywracania starszej wersji (downgrade), a migracje bazy danych są wykonywane wyłącznie w jednym kierunku.