Keycloak vs authentik vs Zitadel: Tek VPS İçin Hangisi?

Tek bir VPS için hangi SSO sunucusu uygundur

Keycloak, authentik ve Zitadel, sunucularındaki tüm uygulamalar için tek bir giriş noktası arayanların karşısına çıkan self-hosted single sign-on (SSO) sunucularıdır. Küçük bir VPS üzerinde bu yazılımlar birbirinin yerine kullanılamaz. authentik, üç veya dört adet self-hosted uygulama çalıştıran bir sunucu için güvenli varsayılan seçenektir; çünkü bu üç seçenek arasında, kendi giriş ekranı olmayan bir uygulamanın önüne giriş ekranı koyabilen tek yazılımdır. Keycloak, koruduğunuz her uygulama halihazırda standart bir protokolü destekliyorsa ve Java sanal makinesi (JVM) için gereken bellek miktarını ayırabiliyorsanız doğru tercihtir. Zitadel, bir API aracılığıyla ürün sunan geliştiriciler için tasarlanmıştır ve 4 GB RAM altındaki sistemlerde denemeyeceğim bir seçenektir.

Önce seçiminizi yapın, ardından kurulumu gerçekleştirin. Seçiminizi yaptıktan sonra, bir VPS üzerinde uygulamalı authentik kurulumu rehberi kurulum adımlarını adım adım açıklar.

Her biri gerçekten ne kadar RAM'e ihtiyaç duyar?

Kaynak tabanından başlayın; çünkü herhangi bir özellikten önce kısa listeyi belirleyen budur. Aşağıdaki rakamlar, Ağustos 2026 itibarıyla her projenin kendi yayınladığı verilerdir. Bunlar yük testi sonuçları değil, üretici rehberleridir.

[
  {
    "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
  }
]

authentik'in Docker Compose kurulum sayfası "en az 2 CPU çekirdeği ve 2 GB RAM'e sahip bir sunucu" talep etmektedir; bu da 2048 MB eder. Yayınlanan compose dosyası 3 adet container çalıştırır: PostgreSQL, sunucu ve worker.

Keycloak, 3 ile en spesifik rakamı yayınlamaktadır. Boyutlandırma kılavuzunda, "Realm verilerinin önbellekleri ve 10.000 önbelleğe alınmış oturum dahil olmak üzere bir Pod için temel bellek kullanımının 1250 MB RAM olduğu" belirtilmektedir. Bu 1250 MB, veritabanı hariç sadece Java sürecini kapsar. Aynı sayfa, container limitinin neden bu kadar önemli olduğunu açıklar: Keycloak, bellek limitinin %70'ini heap olarak ayırır ve bunun üzerine yaklaşık 300 MB heap dışı bellek kullanır. Container'a 1 GB verirseniz, yaklaşık 717 MB'lık bir heap hesaplar ancak yine de 300 MB'lık heap dışı belleğe ihtiyaç duyar; dolayısıyla limit, herhangi bir oturum verisi önbelleğe girmeden önce tükenmiş olur.

Zitadel'in compose sayfası da 2 GB, yani aynı 2048 MB talep eder ancak bu rakam ilk çalıştırma içindir. Okunması gereken yer, üretim (production) sayfasıdır. Zitadel sürecinin kendisi "yaklaşık 512 MB RAM'e ihtiyaç duyar ve bir CPU çekirdeğinden daha azıyla çalışabilir". Veritabanı maliyetli kısımdır: "saniyede 100 istek (req/s) başına yaklaşık bir CPU çekirdeği ve çekirdek başına 4 GB RAM". Parola hashleme işlemi ise "bu amaç için 4 CPU çekirdeği" gerektirir, çünkü ani girişler CPU'da tepe noktası yaratır. Resmi v4 compose dosyası, siz hiçbir şey eklemeden önce 4 adet container çalıştırır: proxy olarak Traefik, Zitadel API, ayrı bir Login UI container'ı ve PostgreSQL. Redis ve OpenTelemetry toplayıcı, isteğe bağlı compose profillerinin arkasında yer alır.

Sonuç olarak Keycloak ve authentik, koruduğunuz uygulamalar için yer bırakacak şekilde 4 GB'lık bir VPS üzerinde çalışabilir. Zitadel 2 GB ile başlar ancak her girişte kendi PostgreSQL'i ile bellek için yarışır. Zitadel'i 4 GB'ın altında çalıştırmazdım; uygulamaları da barındıran bir sunucuda ise 8 GB tercih ederdim.

Her birinin sunucunuzda gerçekte ne çalıştırdığı

authentik, bir PostgreSQL veritabanı ile biri sunucu, diğeri işçi (worker) olmak üzere aynı imajın iki kopyasından oluşur. Sunucu, HTTP isteklerini yanıtlar ve gömülü bir outpost barındırır. İşçi ise dizin eşitlemeleri ve e-posta gönderimi gibi arka plan görevlerini yürütür. Yayınlanan kurulum oldukça kısadır.

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

Sunucu, 9000 ve 9443 numaralı portları dışarıya açar. 9000 numaralı porta ilk erişim, varsayılan akadmin kullanıcısı için parola belirlediğiniz ilk kurulum akışını başlatır. Bu port internete açılmadan önce, önüne gerçek bir sertifikaya sahip bir reverse proxy yerleştirin.

Keycloak, tek bir süreç ve sizin sağladığınız bir veritabanından oluşur. Hızlı başlangıç için tek bir container yeterlidir.

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

start-dev, sistemi incelemek içindir. Yerel bir geliştirme veritabanı ile çalışır ve TLS (transport layer security) içermez; bu şekilde başlatılan ve daha sonra kaldırılan bir container, realm verilerinizi de beraberinde siler. Üretim ortamı, KC_DB üzerinden gerçek bir PostgreSQL ve KC_HOSTNAME üzerinden genel bir ana makine adı ile start kullanılması anlamına gelir. Keycloak'un üretim kılavuzu, sunucuya gelen ve sunucudan giden tüm iletişimin güvenli bir kanal gerektirdiğini belirtir; bu nedenle HTTPS kullanımı isteğe bağlı değildir.

Zitadel, yukarıda açıklanan dört container'lı bir yığındır.

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

İlk başlatmadan önce .env dosyasında ZITADEL_MASTERKEY değerini ayarlayın. Bu, Zitadel'in veritabanındaki gizli verileri şifrelemek için kullandığı 32 karakterlik anahtardır; bu anahtarın kaybedilmesi, söz konusu verilere erişimin kaybedilmesi anlamına gelir. Bu tür yığınları çalıştırmada yeniyseniz, VPS için Docker Compose temelleri rehberi, kimlik sağlayıcınızın yeniden başlatma sonrasında hayatta kalmasını sağlayan volume ve restart-policy seçeneklerini kapsar.

Her biri hangi protokolleri destekler?

Üçü de modern uygulamaların kullandığı OAuth 2.0 üzerindeki oturum açma katmanı olan OpenID Connect (OIDC) protokolünü ve kurumsal yazılımların hala kullandığı eski standart olan SAML 2.0 (security assertion markup language) protokolünü destekler. Asıl ayrım, tek bir kelimenin iki zıt işlevi kapsadığı LDAP (lightweight directory access protocol) tarafında ortaya çıkar.

LDAP üzerinden okuma yapmak, SSO sunucusunun parolaları halihazırda çalıştırdığınız bir dizin üzerinden denetlemesi anlamına gelir. Keycloak bunu kullanıcı federasyonu aracılığıyla yapar. Zitadel de bunu destekler; belgelerinde "ZITADEL içinde bir LDAP sunucusunu kimlik sağlayıcı olarak bağlama" yöntemi açıklanmıştır.

LDAP sunmak ise, yalnızca LDAP konuşabilen bir uygulamanın, SSO sunucunuzu sanki bir dizinmiş gibi kullanabilmesi (bind) anlamına gelir. Bunu yalnızca authentik yapar. authentik'in LDAP sağlayıcısı, 636 numaralı portta LDAPS üzerinden "authentik veritabanındaki tüm kullanıcı ve grupların LDAP dizini aracılığıyla aranabilir" olmasını sağlayan özel bir LDAP outpost kullanır. Bu yapı salt okunurdur; dolayısıyla bind ve arama işlemleri çalışırken yazma işlemleri desteklenmez. Parolaya noktalı virgül ile tek kullanımlık bir kod eklenir (password;123456 örneğindeki gibi) ve bind sırasında SMS doğrulayıcıları desteklenmez.

Eğer listenizdeki bir uygulama yalnızca LDAP konuşuyorsa, karşılaştırma burada sona erer. Keycloak ve Zitadel bu bind isteğine yanıt veremeyeceği için, yanlarında ikinci bir dizin çalıştırmanız ve iki kullanıcı listesini eşitlemeniz gerekir.

Peki ya hiçbir giriş mekanizması olmayan uygulamalar?

Forward auth bu sorunun cevabıdır ve self-hosted sunucularda sürekli karşılaşılan bir durumdur. Reverse proxy'niz, bir isteği upstream'e iletmeden önce SSO sunucusuna isteğin izinli olup olmadığını sorar. Arkadaki uygulama SSO hakkında hiçbir şey öğrenmez. Uygulama, proxy tarafından zaten kontrol edilmiş ve genellikle kullanıcı adının bir başlıkta (header) belirtildiği istekleri alır.

authentik'in proxy sağlayıcısı, bunu belgelenmiş üç mod ile karşılar. "Proxy" modu, authentik outpost'un trafiği doğrudan upstream uygulamaya iletmesini sağlar. "Forward auth (single application)" modu, trafiği mevcut reverse proxy'nizde tutar ve authentik'i yalnızca kimlik doğrulama kontrolü için kullanır. "Forward auth (domain level)" modu ise bir ana alan adı altındaki her uygulamayı tek bir sağlayıcı ile korur. Domain level modu kullanışlıdır ancak belgelenmiş bir sınırı vardır: "korunan her uygulama için farklı uygulama düzeyi yetkilendirme kuralları uygulayamaz", bu nedenle o alan adı altındaki her uygulama aynı politika kümesini paylaşır.

Keycloak'ta bunların hiçbiri yoktur. Yardımcı proxy'si olan Keycloak Gatekeeper, önce Louketo Proxy olarak yeniden adlandırılmış, ardından GitHub'da arşivlenmiştir; son commit işlemi Ağustos 2023 tarihlidir. OIDC desteği olmayan bir uygulamayı korumak için, genellikle bir Keycloak istemcisine yönlendirilmiş oauth2-proxy gibi ayrı bir bileşeni uygulamanın önüne kurmanız gerekir. Zitadel'in de kendine ait bir forward auth modu yoktur, bu nedenle çözüm yine kurulması, izlenmesi ve yükseltilmesi gereken fazladan bir bileşendir.

Bu fazladan adım, reverse proxy yapılandırmasının basitliğini yitirdiği noktadır; bu nedenle bir auth middleware entegre etmeden önce Traefik'in birden fazla Docker Compose uygulamasını nasıl karşıladığını okuyun.

Yükseltme süreci ne kadar zahmetli?

Ağustos 2026 itibarıyla güncel sürümler Keycloak 26.7.1, authentik 2026.5.6 ve Zitadel v4.16.3 şeklindedir. Her üç yazılım da PostgreSQL üzerinde şema migrasyonları çalıştırır; bu da her yükseltmenin bir veritabanı değişikliği olduğu anlamına gelir. Her seferinde, önce veritabanını yedekleyin. Bu alışkanlık, bu karşılaştırmadaki tüm özelliklerden daha değerlidir.

authentik en katı kurala sahiptir ve bunu açıkça belirtir: "Yükseltmeler ana sürüm sırasını takip etmelidir; eski bir ana sürümden doğrudan en son sürüme atlamayın." Her sürüm içinde en son yamaya geçiş yapmalı, ardından bir sonraki sürüme ilerlemelisiniz; ayrıca "authentik sürüm düşürmeyi desteklemez". Takvim tabanlı sürümlendirme kullanan bir projede bir yıl geride kalmak, her biri kendi veritabanı migrasyonuna sahip bir yükseltme zinciriyle uğraşmanıza neden olur.

Keycloak yükseltme kılavuzu izlenmesi gereken bir sıra sunar: önceki sürümden gelen migrasyon değişikliklerini inceleyin, sunucuyu yükseltin ve ardından adaptörleri yükseltin. Veritabanı migrasyonu otomatik olarak çalışır veya bunu dışa aktarıp manuel olarak uygulayabilirsiniz; bu yöntem, değişiklikleri veritabanına işlemeden önce okumak istediğinizde faydalıdır. Keycloak ile ilgili maliyet, bu okuma sürecidir. Sürüm notları, gözden kaçırılması kolay ancak atlanması durumunda maliyetli olan kullanımdan kaldırmaları ve davranış değişikliklerini içerir.

Zitadel, init ve setup aşamalarını çalışan sunucudan ayırır ve üretim ortamı kılavuzu, ölçeklendirme sırasında kurulum işlemlerinin tekrarlanmaması için bu aşamaların ayrı tutulmasını önerir. Tek bir VPS üzerinde bu durum, kurulum adımının API sağlıklı olduğunu bildirmeden önce tamamlanması gerektiği anlamına gelir; bu nedenle compose dosyası sağlık kontrolleri içerir ve başlatma komutu --wait kullanır.

Her projenin hedef kitlesi ve zayıf kaldığı noktalar

Keycloak, Red Hat tarafından geliştirilen ve realm, grup, rol eşlemeleri ile mevcut kurumsal dizin yapılarına sahip organizasyonlar için tasarlanmış bir kimlik sunucusudur. Bu üç seçenek arasında standartlara en uygun ve eksiksiz uygulamadır. Dört farklı self-hosted uygulamanın çalıştığı ve yarısının OIDC desteğinin bulunmadığı 2 GB RAM kapasiteli bir VPS üzerinde verimsiz kalır. JVM için 1250 MB bellek harcar, şirketler için tasarlanmış bir realm modelini öğrenmek zorunda kalırsınız ve sonuçta asıl ihtiyaç duyduğunuz uygulamalar için yine de oauth2-proxy kurmanız gerekir.

authentik, self-hosting kullanıcıları için geliştirilmiştir ve özellik listesi bunu yansıtır. Forward auth ve LDAP sağlayıcısı ile gelir, giriş akışlarını görsel bir düzenleyici üzerinden oluşturmanıza olanak tanır. Kurumsal bir destek sözleşmesine veya birkaç haftada bir değişmeyen bir sürüm döngüsüne ihtiyaç duyduğunuzda yetersiz kalır. Sürüm düşürme yolu olmayan ve sürümlerin atlanamadığı takvim tabanlı sürümleme, operasyonel açıdan ciddi bir yük oluşturur; ayrıca asıl sorununuz tek bir OIDC istemcisi iken akış düzenleyiciyi öğrenmek gereksiz bir karmaşıklıktır.

Zitadel, kimlik doğrulama mekanizmasını sundukları bir ürünün içine entegre eden geliştiriciler için tasarlanmıştır; güçlü bir API ve çoklu kiracılık (multi-tenancy) temel özellikleridir. Tam olarak bu kullanım senaryosu dışında zayıf kalır. Dört container, forward auth desteğinin olmaması ve çekirdek başına 4 GB veritabanı boyutu gereksinimi, arkasında bir parola yöneticisi ve wiki bulunan tek bir VPS için uygun bir yapı değildir.

Tek bir VPS üzerinde ne çalıştırılmalı ve nasıl

Üç veya dört adet self-hosted uygulama barındıran tek bir VPS için authentik çalıştırın. Her üç seçenek de size bir giriş ekranı sunar. Karar verici faktör, bazı uygulamalarınızın hiçbir zaman OIDC desteklemeyecek olmasıdır; authentik, bunu yanına başka bir bileşen eklemek yerine yerleşik "forward auth" özelliği ile çözer.

Mümkünse 4 GB bellek ayırın, yalnızca yanındaki uygulamalar küçükse 2 GB ile yetinin. 9000 numaralı portu genel internete kapatın ve TLS sonlandırmasını ön taraftaki bir reverse proxy üzerinde yapın. Her gece PostgreSQL yedekleri alın ve bunları sunucu dışında saklayın; çünkü yedeği olmayan bir kimlik sağlayıcı, arkasındaki her uygulama için tek bir hata noktasıdır. Stack'i root yerine özel ve yetkisiz bir kullanıcı hesabı ile çalıştırın: VPS üzerinde en düşük yetkili kullanıcıları yapılandırma rehberi, bunun için gereken hesap ve dosya sahipliği ayarlarını kapsar.

Koruduğunuz her uygulama halihazırda OIDC veya SAML destekliyorsa ya da Keycloak realm yapısının sunduğu detaylı rol modeline ihtiyaç duyuyorsanız Keycloak'u tercih edin. Başka insanların kaydolacağı bir uygulama geliştiriyorsanız ve bunun API'sine veya kiracı (tenant) modeline ihtiyaç duyuyorsanız Zitadel'i seçin. Bu seçeneklerin hiçbiri, bu yazının konusu olan tek sunucuda üç uygulama senaryosu için uygun değildir.

İlk karşılaşacağınız hata modları

Yeniden başlatma sonrasında Keycloak verisi yok. Keycloak'u yerel geliştirme veritabanı kullanan start-dev ile başlattınız. Bir volume tanımlanmamış container yapısında, container'ı kaldırmak realm verisini de siler. KC_DB=postgres ile gerçek bir veritabanına işaret eden start yapısına geçin.

Küçük bir sunucuda authentik worker container'ı kayboluyor. Worker ve server aynı imajı kullanır ve her ikisi de Python süreçlerini barındırır; PostgreSQL ise 2 GB belleğe sahip bir sunucuda kendi payını ister. Hangi servisin kapandığını doğrulamak için docker compose ps komutunu çalıştırın, ardından uygulamada bir hata aramadan önce bellek yetersizliği (OOM kill) olup olmadığını görmek için dmesg kayıtlarını kontrol edin.

Zitadel Console proxy arkasında çalışmıyor. Zitadel API, upstream yönünde HTTP/2 gerektiren gRPC kullanır. Gereksinimler sayfası, HTTP/2 upstream bağlantılarını destekleyen bir reverse proxy ister ve test edilmiş sürümler olarak Traefik v3.x, NGINX v1.x, Caddy v2.x ve Apache httpd 2.4.x'i belirtir. Upstream bağlantısını HTTP/1.1'e düşüren bir proxy, giriş sayfasının yüklenmesini sağlar ancak Console'un çalışmamasına neden olur.

Her uygulama sizi tekrar giriş ekranına yönlendiriyor. SSO sunucusunun genel URL'si ile uygulamada yapılandırılan URL, şema ve port dahil olmak üzere tam olarak eşleşmelidir. Keycloak buna hostname ayarı, Zitadel ise external domain adını verir. Bu değerler uyuşmadığında, uygulama sunucunun kendisine ait olarak tanımadığı bir giriş sayfasına yönlendirme yapar ve tarayıcı iki adres arasında döngüye girer.

FAQ

2 GB RAM kapasiteli bir VPS için bu üçünden hangisi uygundur?

authentik ve Keycloak. authentik, en az 2 CPU çekirdeği ve 2 GB RAM içeren bir sunucu gereksinimi belirtmektedir; Keycloak boyutlandırma kılavuzu ise veritabanı hariç sunucu için temel bellek ihtiyacını 1250 MB olarak tanımlar. Koruduğunuz uygulamaları da eklediğinizde her iki seçenek için de 2 GB sınırda kalacaktır; bu nedenle 4 GB RAM'i güvenli bir alt sınır olarak kabul edin. Zitadel ilk kurulum için 2 GB değerini yayınlasa da, üretim ortamı kılavuzunda parola hashleme işlemleri için 4 CPU çekirdeği ve veritabanı çekirdeği başına 4 GB RAM önermektedir; dolayısıyla 2 GB gerçek bir dağıtım için yeterli değildir.

Keycloak veya Zitadel, kendi giriş sistemi olmayan bir uygulamayı koruyabilir mi?

Kendi başlarına hayır. İkisi de yerleşik bir "forward auth" bileşeni ile gelmez. Keycloak'un eski yardımcı proxy'si olan Louketo Proxy, GitHub üzerinde arşivlenmiş durumdadır ve son commit işlemi Ağustos 2023'te yapılmıştır; bu nedenle üzerine yeni bir yapı inşa edilmemelidir. Reverse proxy ile uygulamanız arasına oauth2-proxy veya benzeri bir bileşen yerleştirip, bunu SSO sunucusu üzerindeki bir OIDC istemcisine yönlendirmeniz gerekir. authentik ise bunu "Forward auth (single application)" veya "Forward auth (domain level)" modundaki proxy sağlayıcısı ile yerel olarak yapabilir.

Sadece LDAP protokolü ile konuşan bir uygulama için hangisi LDAP sunucusu görevi görebilir?

authentik. LDAP sağlayıcısı bir outpost üzerinde çalışır ve authentik içindeki kullanıcı ve grupların LDAP üzerinden sorgulanabilmesini sağlar; 636 numaralı port üzerinden LDAPS desteği mevcuttur. Bu yapı salt okunurdur; dolayısıyla bind ve arama işlemleri çalışırken yazma işlemleri desteklenmez. Keycloak ve Zitadel ise tam tersi yönde çalışır: her ikisi de mevcut bir LDAP dizinini kullanıcı kaynağı olarak okur, ancak hiçbir uygulama tarafından gelen LDAP bind isteğine yanıt veremezler.

authentik yükseltmelerinde sürümleri atlayabilir miyim?

Hayır. Dokümantasyon, yükseltmelerin ana sürüm sırasını takip etmesi gerektiğini ve eski bir ana sürümden doğrudan en güncel sürüme geçilmemesi gerektiğini belirtir. Öncelikle her sürüm içindeki en son yama (patch) sürümüne geçin, ardından her seferinde bir sürüm yükseltin. Her adımdan önce PostgreSQL yedeği alın; çünkü authentik sürüm düşürmeyi desteklemez ve veritabanı migrasyonları yalnızca ileriye doğru çalışır.