Keycloak vs authentik vs Zitadel di Satu VPS

Server SSO mana yang cocok untuk satu VPS

Keycloak, authentik, dan Zitadel adalah server single sign-on (SSO) self-hosted yang biasanya dipertimbangkan ketika satu login diperlukan untuk semua aplikasi pada server. Pada satu VPS kecil, ketiganya tidak dapat saling menggantikan. authentik adalah pilihan default yang aman untuk server yang menjalankan tiga atau empat aplikasi self-hosted, karena hanya authentik dari ketiganya yang dapat menampilkan layar login di depan aplikasi yang tidak memiliki fitur login sendiri. Keycloak adalah pilihan yang tepat jika semua aplikasi yang dilindungi sudah mendukung protokol standar dan Anda dapat menyediakan memori untuk Java virtual machine (JVM). Zitadel dibuat untuk developer yang merilis produk melalui API, dan saya tidak akan mencoba menjalankannya dengan memori di bawah 4 GB.

Tentukan pilihan terlebih dahulu, lalu lakukan instalasi. Setelah menentukan pilihan, panduan instalasi authentik secara langsung pada VPS menjelaskan proses penyiapan langkah demi langkah.

Berapa RAM yang benar-benar diperlukan masing-masing?

Mulailah dari batas minimum sumber daya, karena faktor ini menentukan daftar pilihan sebelum fitur apa pun dipertimbangkan. Angka di bawah ini berasal dari angka yang dipublikasikan oleh masing-masing proyek, sebagaimana dibaca pada Agustus 2026. Angka tersebut merupakan panduan vendor, bukan hasil pengujian beban.

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

Halaman instalasi Docker Compose authentik meminta “host dengan setidaknya 2 core CPU dan 2 GB RAM”, yaitu 2048 MB, dan file compose yang dipublikasikannya menjalankan 3 container: PostgreSQL, server, dan worker.

Keycloak memublikasikan angka paling spesifik dari 3 angka tersebut. Panduan sizing-nya menyatakan bahwa “penggunaan memori dasar untuk sebuah Pod, termasuk cache data Realm dan 10.000 sesi yang disimpan dalam cache, adalah 1250 MB RAM”. 1250 MB tersebut hanya mencakup proses Java, sebelum database diperhitungkan. Halaman yang sama menjelaskan mengapa batas container sangat penting: Keycloak menggunakan 70% dari batas memori sebagai heap dan membutuhkan sekitar 300 MB memori non-heap tambahan. Jika container diberi 1 GB, Keycloak menghitung heap sekitar 717 MB, tetapi tetap membutuhkan 300 MB memori non-heap. Dengan demikian, batas tersebut sudah habis sebelum data sesi apa pun masuk ke cache.

Halaman compose Zitadel juga meminta 2 GB, yaitu 2048 MB yang sama, tetapi angka tersebut berlaku untuk proses pertama. Halaman produksinya adalah rujukan yang perlu dibaca. Proses Zitadel sendiri membutuhkan “sekitar 512MB RAM dan dapat berjalan dengan kurang dari satu core CPU”. Database adalah bagian yang paling banyak menggunakan sumber daya: “sekitar satu core CPU per 100 permintaan per detik (req/s) dan 4GB RAM per core”. Password hashing kemudian membutuhkan “4 core CPU yang tersedia untuk keperluan ini”, karena lonjakan login dapat menyebabkan lonjakan penggunaan CPU. Compose resmi v4 menjalankan 4 container sebelum Anda menambahkan komponen lain: Traefik sebagai proxy, API Zitadel, container Login UI terpisah, dan PostgreSQL. Redis dan collector OpenTelemetry berada di balik compose profile opsional.

Dengan demikian, Keycloak dan authentik dapat berjalan pada VPS 4 GB dengan sisa sumber daya untuk aplikasi yang Anda lindungi. Zitadel dapat start pada 2 GB, tetapi kemudian harus berbagi memori dengan PostgreSQL miliknya sendiri setiap kali terjadi login. Saya tidak akan menjalankan Zitadel dengan RAM di bawah 4 GB. Pada server yang juga meng-host aplikasi, saya akan memilih RAM 8 GB.

Apa yang sebenarnya dijalankan masing-masing pada server Anda

authentik terdiri atas PostgreSQL dan dua salinan dari satu image, yaitu server dan worker. Server menangani HTTP dan menjalankan outpost tertanam. Worker menjalankan tugas latar belakang seperti sinkronisasi direktori dan email. Konfigurasi instalasinya singkat.

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

Server memublikasikan port 9000 dan 9443. Kunjungan pertama ke port 9000 menjalankan alur penyiapan awal, tempat Anda menetapkan kata sandi untuk pengguna default akadmin. Tempatkan reverse proxy dengan sertifikat yang valid di depannya sebelum port tersebut dapat dijangkau dari Internet.

Keycloak terdiri atas satu proses dan database yang Anda sediakan. Panduan quickstart menggunakan satu container.

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 digunakan untuk eksplorasi. Konfigurasi ini berjalan dengan database pengembangan lokal dan tanpa TLS (transport layer security), sehingga container yang dijalankan dengan cara ini lalu dihapus akan menghapus realm Anda. Untuk produksi, gunakan start, dengan PostgreSQL yang sebenarnya melalui KC_DB dan hostname publik melalui KC_HOSTNAME. Panduan produksi Keycloak juga menyatakan bahwa semua komunikasi ke dan dari server memerlukan saluran yang aman, sehingga HTTPS wajib digunakan.

Zitadel adalah stack empat container yang dijelaskan di atas.

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

Tetapkan ZITADEL_MASTERKEY dalam .env sebelum menjalankan untuk pertama kali. Ini adalah key 32 karakter yang digunakan Zitadel untuk mengenkripsi secret dalam database. Jika key tersebut hilang, akses ke secret tersebut juga hilang. Jika Anda baru menjalankan stack seperti ini, dasar-dasar Docker Compose untuk VPS menjelaskan pilihan volume dan restart policy yang menentukan apakah identity provider Anda tetap tersedia setelah reboot.

Protokol apa yang digunakan masing-masing?

Ketiganya menggunakan OpenID Connect (OIDC), yaitu lapisan login di atas OAuth 2.0 yang digunakan aplikasi modern. Ketiganya juga menggunakan SAML 2.0 (security assertion markup language), yaitu standar lama yang masih dirilis oleh perangkat lunak enterprise. Perbedaan utamanya adalah LDAP (lightweight directory access protocol), yang mencakup dua fungsi yang berlawanan.

Membaca dari LDAP berarti server SSO memeriksa password terhadap directory yang sudah Anda jalankan. Keycloak melakukan ini melalui user federation. Zitadel juga mendukungnya: dokumentasinya menjelaskan cara "connect an LDAP server as an identity provider in ZITADEL".

Menyediakan LDAP berarti aplikasi yang hanya mendukung LDAP dapat melakukan bind ke server SSO seolah-olah server tersebut adalah directory. Hanya authentik yang mendukung fungsi ini. LDAP provider-nya membuat "all users and groups in authentik's database searchable via the LDAP directory" melalui LDAP outpost khusus, dengan LDAPS tersedia pada port 636. Provider ini bersifat hanya-baca, sehingga bind dan pencarian dapat dilakukan, tetapi penulisan tidak dapat dilakukan. Kode satu kali pakai ditambahkan ke password dengan tanda titik koma, seperti pada password;123456, dan SMS authenticator tidak didukung selama bind.

Jika salah satu aplikasi dalam daftar Anda hanya mendukung LDAP, perbandingan berhenti di situ. Keycloak dan Zitadel tidak dapat merespons bind tersebut, sehingga Anda harus menjalankan directory kedua di samping keduanya dan menyinkronkan dua daftar pengguna.

Bagaimana dengan aplikasi yang sama sekali tidak memiliki login?

Forward auth adalah jawabannya. Ini merupakan kasus yang sering ditemui pada server self-hosted. Reverse proxy menanyakan kepada server SSO apakah suatu request diizinkan sebelum meneruskannya ke upstream. Aplikasi di belakangnya tidak mengetahui apa pun tentang SSO. Aplikasi hanya menerima request yang sudah diperiksa oleh proxy, biasanya dengan username di dalam header.

Proxy provider authentik mendukung hal ini dalam tiga mode yang terdokumentasi. "Proxy" membuat authentik outpost meneruskan trafik ke aplikasi upstream secara langsung. "Forward auth (single application)" mempertahankan trafik pada reverse proxy yang sudah ada dan menggunakan authentik hanya untuk pemeriksaan autentikasi. "Forward auth (domain level)" melindungi semua aplikasi di bawah satu parent domain dengan satu provider. Mode domain level lebih praktis, tetapi memiliki batasan yang terdokumentasi: mode ini "tidak dapat menerapkan aturan otorisasi tingkat aplikasi yang berbeda untuk setiap aplikasi yang dilindungi", sehingga semua aplikasi di bawah domain tersebut menggunakan satu set kebijakan yang sama.

Keycloak tidak menyediakan fitur ini. Proxy pendampingnya, Keycloak Gatekeeper, berganti nama menjadi Louketo Proxy dan kemudian diarsipkan di GitHub, dengan commit terakhir pada August 2023. Untuk melindungi aplikasi yang tidak mendukung OIDC, Anda harus menjalankan komponen terpisah di depannya, biasanya oauth2-proxy, yang diarahkan ke client Keycloak. Zitadel juga tidak memiliki mode forward auth sendiri. Jadi, solusinya sama: instal, monitor, dan upgrade komponen tambahan tersebut.

Hop tambahan inilah yang membuat konfigurasi reverse proxy tidak lagi sederhana. Baca cara Traefik meneruskan trafik ke beberapa aplikasi Docker Compose sebelum menambahkan auth middleware ke dalamnya.

Seberapa rumit jalur upgrade?

Per Agustus 2026, rilis terbaru adalah Keycloak 26.7.1, authentik 2026.5.6, dan Zitadel v4.16.3. Ketiganya menjalankan migrasi skema pada PostgreSQL. Artinya, setiap upgrade mengubah database. Selalu buat cadangan database terlebih dahulu. Kebiasaan ini lebih berharga daripada fitur apa pun dalam perbandingan ini.

authentik memiliki aturan paling ketat dan menyatakannya dengan jelas: "Upgrade harus mengikuti urutan rilis major; jangan langsung melewati beberapa versi dari versi major yang lebih lama ke versi terbaru." Anda harus beralih ke patch terbaru dalam setiap versi sebelum melanjutkan ke versi berikutnya, dan "authentik tidak mendukung downgrade". Jika Anda tertinggal selama setahun pada proyek dengan versi berdasarkan kalender, satu upgrade akan berubah menjadi rangkaian upgrade. Masing-masing memiliki migrasi database sendiri.

Panduan upgrade Keycloak menetapkan urutan yang harus diikuti: tinjau perubahan migrasi dari versi sebelumnya, upgrade server, lalu upgrade adapter. Migrasi database berjalan otomatis. Anda juga dapat mengekspornya dan menerapkannya secara manual. Ini berguna jika Anda ingin membaca perubahan tersebut sebelum diterapkan. Biaya menggunakan Keycloak terletak pada proses membaca itu. Catatan rilisnya memuat fitur yang tidak lagi direkomendasikan dan perubahan perilaku yang mudah dilewati, tetapi mahal jika terlewat.

Zitadel memisahkan fase init dan setup dari server yang sedang berjalan. Panduan produksinya menyarankan agar keduanya tetap dipisahkan sehingga scaling tidak mengulangi pekerjaan setup. Pada satu VPS, hal ini terutama berarti langkah setup harus selesai sebelum API melaporkan status sehat. Karena itu, file compose menyediakan health check dan perintah start menggunakan --wait.

Untuk siapa setiap proyek dibuat, dan di bagian mana masing-masing memiliki keterbatasan

Keycloak adalah server identitas dari Red Hat yang dibuat untuk organisasi dengan realm, grup, pemetaan peran, dan direktori korporat yang sudah tersedia. Keycloak memiliki implementasi standar yang paling lengkap di antara ketiganya. Namun, Keycloak kurang sesuai untuk VPS 2 GB yang menjalankan empat aplikasi self-hosted, ketika separuh aplikasi tersebut tidak mendukung OIDC. Anda menggunakan 1250 MB untuk JVM, harus mempelajari model realm yang dirancang untuk perusahaan, dan tetap perlu memasang oauth2-proxy untuk aplikasi yang sebenarnya ingin Anda lindungi.

authentik dibuat untuk pengguna self-hosting, dan daftar fiturnya mencerminkan tujuan tersebut. authenik menyediakan forward auth dan LDAP provider, serta memungkinkan Anda membuat alur login melalui editor visual. Namun, authentik kurang sesuai ketika Anda memerlukan kontrak dukungan vendor atau release train yang tidak berubah setiap beberapa minggu. Versioning berbasis kalender tanpa jalur downgrade dan tanpa opsi melewati versi memerlukan pekerjaan operasional yang nyata. Editor alurnya juga merupakan model tersendiri yang harus dipelajari, padahal masalah Anda sebenarnya hanya satu OIDC client.

Zitadel dibuat untuk developer yang menanamkan autentikasi ke dalam produk yang mereka rilis, dengan API yang kuat dan multi-tenancy sebagai fitur utama. Dalam kasus ini, Zitadel justru kurang sesuai. Empat container, tidak adanya forward auth, serta database berukuran 4 GB per core merupakan arsitektur yang tidak tepat untuk satu VPS yang menjalankan password manager dan wiki di belakangnya.

Apa yang akan saya jalankan pada satu VPS, dan caranya

Untuk satu VPS dengan tiga atau empat aplikasi self-hosted, jalankan authentik. Ketiganya menyediakan layar login. Faktor penentunya adalah bahwa beberapa aplikasi Anda mungkin tidak akan pernah mendukung OIDC, sedangkan authentik menanganinya dengan forward auth bawaan, tanpa memerlukan komponen tambahan di sampingnya.

Jika memungkinkan, alokasikan 4 GB untuk authentik. Gunakan 2 GB hanya jika aplikasi lain di VPS tersebut berukuran kecil. Jangan ekspos port 9000 ke Internet publik, dan lakukan terminasi TLS pada reverse proxy di depannya. Buat dump PostgreSQL setiap malam dan simpan di luar server, karena identity provider tanpa backup menjadi single point of failure bagi setiap aplikasi di belakangnya. Jalankan stack menggunakan akun khusus tanpa hak istimewa, bukan sebagai root: menyiapkan pengguna dengan hak istimewa minimum pada VPS membahas akun dan kepemilikan file yang diperlukan.

Pilih Keycloak jika semua aplikasi yang Anda lindungi sudah mendukung OIDC atau SAML, atau jika Anda memerlukan model peran terperinci yang disediakan oleh realm Keycloak. Pilih Zitadel jika Anda sedang membuat aplikasi yang digunakan orang lain untuk mendaftar dan Anda memerlukan API serta model tenant yang disediakannya. Keduanya bukan pilihan untuk kasus tiga aplikasi pada satu server yang dibahas dalam artikel ini.

Mode kegagalan yang akan Anda temui terlebih dahulu

Keycloak tidak memiliki data setelah restart. Anda menjalankannya dengan start-dev, yang menggunakan database pengembangan lokal. Pada container tanpa volume, penghapusan container juga menghapus realm. Beralihlah ke start dengan KC_DB=postgres yang diarahkan ke database sebenarnya.

Container worker authentik menghilang pada host dengan sumber daya terbatas. Worker dan server menggunakan image yang sama, dan keduanya menjalankan proses Python. PostgreSQL juga membutuhkan bagiannya dari host 2 GB. Jalankan docker compose ps untuk memastikan service yang berhenti, lalu periksa dmesg untuk mengetahui apakah proses dihentikan karena kehabisan memori sebelum mencari bug pada aplikasi.

Console Zitadel tidak berfungsi di belakang proxy Anda. API Zitadel menggunakan gRPC, yang memerlukan HTTP/2 hingga ke upstream. Halaman persyaratan meminta reverse proxy yang mendukung koneksi HTTP/2 ke upstream dan mencantumkan versi Traefik v3.x, NGINX v1.x, Caddy v2.x, serta Apache httpd 2.4.x yang telah diuji. Proxy yang menurunkan koneksi upstream ke HTTP/1.1 akan menampilkan halaman login yang dapat dimuat, tetapi Console gagal digunakan.

Setiap aplikasi mengembalikan Anda ke halaman login. URL publik server SSO dan URL yang dikonfigurasi dalam aplikasi harus sama persis, termasuk scheme dan port. Keycloak menyebutnya pengaturan hostname, sedangkan Zitadel menyebutnya external domain. Jika keduanya berbeda, aplikasi mengarahkan Anda ke halaman login yang tidak dikenali server sebagai URL miliknya, sehingga browser terus berpindah di antara keduanya.

FAQ

Manakah yang cocok untuk VPS 2 GB?

authentik dan Keycloak. Persyaratan yang dinyatakan authentik adalah host dengan setidaknya 2 inti CPU dan 2 GB RAM, sedangkan panduan sizing Keycloak menetapkan memori dasar server sebesar 1250 MB, belum termasuk databasenya. Keduanya akan kekurangan sumber daya pada 2 GB setelah aplikasi yang dilindungi ditambahkan, jadi anggap 4 GB sebagai kapasitas minimum yang nyaman. Zitadel mencantumkan 2 GB untuk pengoperasian pertama, tetapi panduan produksinya meminta 4 inti CPU untuk hashing kata sandi dan 4 GB RAM per inti database, sehingga 2 GB bukan deployment yang realistis.

Apakah Keycloak atau Zitadel dapat melindungi aplikasi yang tidak memiliki login sendiri?

Tidak tanpa komponen tambahan. Keduanya tidak menyediakan komponen forward auth. Proxy pendamping lama milik Keycloak, Louketo Proxy, telah diarsipkan di GitHub dengan commit terakhir pada August 2023, sehingga tidak layak dijadikan dasar. Letakkan oauth2-proxy atau komponen serupa di antara reverse proxy dan aplikasi, lalu arahkan komponen tersebut ke klien OIDC pada server SSO. authentik menyediakan fungsi ini secara native melalui proxy provider dalam mode "Forward auth (single application)" atau "Forward auth (domain level)".

Manakah yang dapat berfungsi sebagai server LDAP untuk aplikasi yang hanya mendukung LDAP?

authentik. LDAP provider miliknya berjalan pada outpost dan membuat pengguna serta grup di authentik dapat dicari melalui LDAP, dengan LDAPS tersedia pada port 636. Provider ini bersifat read-only, sehingga bind dan search dapat dilakukan, sedangkan operasi write tidak dapat dilakukan. Keycloak dan Zitadel bekerja sebaliknya: keduanya membaca dari direktori LDAP yang sudah ada sebagai sumber pengguna, dan tidak ada yang menerima LDAP bind dari aplikasi.

Apakah saya dapat melewati versi saat meng-upgrade authentik?

Tidak. Dokumentasi menyatakan bahwa upgrade harus mengikuti urutan major release dan Anda tidak boleh langsung beralih dari major version lama ke versi terbaru. Perbarui terlebih dahulu ke patch release terbaru dalam setiap versi, lalu naikkan satu versi setiap kali. Cadangkan PostgreSQL sebelum setiap langkah, karena authentik tidak mendukung downgrade dan migration hanya berjalan maju.