Keycloak vs Authentik vs Zitadel: Mana Sesuai untuk VPS?

Pelayan SSO mana yang sesuai untuk satu VPS

Keycloak, authentik dan Zitadel ialah pelayan single sign-on (SSO) layan diri yang sering menjadi pilihan apabila seseorang mahukan satu log masuk untuk semua aplikasi pada pelayan mereka. Pada satu VPS kecil, ia tidak boleh ditukar ganti. authentik ialah pilihan lalai yang selamat untuk pelayan yang menjalankan tiga atau empat aplikasi layan diri, kerana ia satu-satunya daripada ketiga-tiga pilihan tersebut yang boleh meletakkan skrin log masuk di hadapan aplikasi yang tidak mempunyai sistem log masuk sendiri. Keycloak adalah jawapan yang tepat apabila setiap aplikasi yang anda lindungi sudah menyokong protokol standard dan anda mempunyai memori yang mencukupi untuk Java virtual machine (JVM). Zitadel dibina untuk pembangun yang mengeluarkan produk melalui API, dan ia adalah pilihan yang saya tidak akan cuba gunakan dengan memori bawah 4 GB.

Pilih dahulu, kemudian pasang. Setelah anda membuat pilihan, pemasangan praktikal authentik pada VPS merangkumi langkah penyediaan secara terperinci.

Berapakah RAM yang sebenarnya diperlukan oleh setiap satu?

Mulakan dengan lantai sumber, kerana ia menentukan senarai pendek sebelum sebarang ciri diambil kira. Angka di bawah adalah angka yang diterbitkan oleh setiap projek sendiri, dibaca pada Ogos 2026. Ia merupakan panduan vendor, bukan hasil daripada ujian 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 pemasangan Docker Compose authentik meminta "hos dengan sekurang-kurangnya 2 teras CPU dan 2 GB RAM", iaitu 2048 MB, dan fail compose yang diterbitkan menjalankan 3 kontena: PostgreSQL, pelayan, dan pekerja.

Keycloak menerbitkan angka yang paling khusus bagi 3. Panduan saiznya menyatakan bahawa "penggunaan memori asas untuk Pod termasuk cache data Realm dan 10,000 sesi yang dicache ialah 1250 MB RAM". 1250 MB tersebut meliputi proses Java itu sendiri, sebelum pangkalan data. Halaman yang sama menjelaskan mengapa had kontena sangat penting: Keycloak mengambil 70% daripada had memori sebagai heap dan menggunakan kira-kira 300 MB memori bukan heap sebagai tambahan. Berikan kontena 1 GB dan ia mengira heap kira-kira 717 MB sementara masih memerlukan 300 MB memori bukan heap tersebut, jadi had tersebut sudah habis digunakan sebelum sebarang data sesi masuk ke dalam cache.

Halaman compose Zitadel juga meminta 2 GB, iaitu 2048 MB yang sama, tetapi angka itu adalah untuk permulaan kali pertama. Halaman pengeluarannya adalah yang perlu dibaca. Proses Zitadel itu sendiri memerlukan "kira-kira 512MB RAM dan boleh beroperasi dengan kurang daripada satu teras CPU". Pangkalan data adalah bahagian yang mahal: "kira-kira satu teras CPU bagi setiap 100 permintaan sesaat (req/s) dan 4GB RAM bagi setiap teras". Hashing kata laluan kemudiannya memerlukan "4 teras CPU tersedia untuk tujuan ini", kerana lonjakan log masuk akan menyebabkan lonjakan CPU. Fail compose v4 rasmi menjalankan 4 kontena sebelum anda menambah apa-apa: Traefik sebagai proksi, API Zitadel, kontena UI Log Masuk yang berasingan, dan PostgreSQL. Redis dan pengumpul OpenTelemetry berada di belakang profil compose pilihan.

Jadi, Keycloak dan authentik boleh dimuatkan pada VPS 4 GB dengan ruang yang masih ada untuk aplikasi yang anda lindungi. Zitadel akan bermula pada 2 GB, kemudian bersaing dengan PostgreSQL miliknya sendiri untuk mendapatkan memori pada setiap log masuk. Saya tidak akan menjalankan Zitadel di bawah 4 GB, dan pada mesin yang turut mengehoskan aplikasi lain, saya mahukan 8 GB.

Perkara yang sebenarnya dijalankan pada pelayan anda

authentik terdiri daripada PostgreSQL serta dua salinan imej yang sama, iaitu pelayan (server) dan pekerja (worker). Pelayan menjawab permintaan HTTP dan menempatkan outpost terbenam. Pekerja menjalankan tugas latar belakang seperti penyelarasan direktori dan e-mel. Pemasangan yang diterbitkan adalah ringkas.

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

Pelayan menerbitkan port 9000 dan 9443. Lawatan pertama ke port 9000 akan menjalankan aliran persediaan awal, di mana anda menetapkan kata laluan untuk pengguna lalai akadmin. Letakkan reverse proxy dengan sijil sebenar di hadapannya sebelum port tersebut boleh dicapai dari internet.

Keycloak ialah satu proses ditambah dengan pangkalan data yang anda sediakan. Permulaan pantas (quickstart) menggunakan satu kontena tunggal.

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 adalah untuk tujuan tinjauan. Ia berjalan dengan pangkalan data pembangunan tempatan dan tanpa TLS (transport layer security), jadi kontena yang dimulakan dengan cara ini dan kemudiannya dibuang akan turut menghapuskan realm anda. Pengeluaran (production) bermaksud menggunakan start sebaliknya, dengan PostgreSQL sebenar melalui KC_DB dan nama hos awam melalui KC_HOSTNAME. Panduan pengeluaran Keycloak juga menyatakan bahawa semua komunikasi ke dan dari pelayan memerlukan saluran selamat, jadi HTTPS bukanlah pilihan di situ.

Zitadel ialah tindanan (stack) empat kontena yang diterangkan 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 permulaan pertama. Ia merupakan kunci 32 aksara yang digunakan oleh Zitadel untuk menyulitkan rahsia dalam pangkalan data, jadi kehilangannya bermakna kehilangan akses kepada rahsia tersebut. Jika anda baru dalam menjalankan tindanan seperti ini, asas Docker Compose untuk VPS merangkumi pilihan volume dan dasar mulakan semula (restart-policy) yang menentukan sama ada penyedia identiti anda kekal selepas but semula.

Protokol manakah yang disokong oleh setiap satu?

Ketiga-tiganya menyokong OpenID Connect (OIDC), iaitu lapisan log masuk di atas OAuth 2.0 yang digunakan oleh aplikasi moden, dan ketiga-tiganya juga menyokong SAML 2.0 (security assertion markup language), standard lama yang masih digunakan oleh perisian perusahaan. Perbezaan sebenar terletak pada LDAP (lightweight directory access protocol), di mana satu istilah merangkumi dua tugas yang bertentangan.

Membaca daripada LDAP bermaksud pelayan SSO menyemak kata laluan berdasarkan direktori yang anda jalankan. Keycloak melakukan ini melalui user federation. Zitadel juga melakukannya: dokumentasinya menerangkan cara untuk "menyambungkan pelayan LDAP sebagai pembekal identiti dalam ZITADEL".

Menyediakan LDAP bermaksud aplikasi yang hanya menyokong LDAP boleh melakukan bind dengan pelayan SSO anda seolah-olah ia adalah direktori tersebut. Hanya authentik yang melakukan ini. Pembekal LDAP miliknya menjadikan "semua pengguna dan kumpulan dalam pangkalan data authentik boleh dicari melalui direktori LDAP" menerusi LDAP outpost khusus, dengan LDAPS tersedia pada port 636. Ia bersifat baca sahaja, jadi bind dan carian berfungsi manakala penulisan tidak. Kod sekali guna ditambah pada kata laluan dengan tanda koma bertitik, seperti dalam password;123456, dan pengesah SMS tidak disokong semasa proses bind.

Jika satu aplikasi dalam senarai anda hanya menyokong LDAP, perbandingan berakhir di situ. Keycloak dan Zitadel tidak dapat menjawab bind tersebut, jadi anda perlu menjalankan direktori kedua di sampingnya dan memastikan dua senarai pengguna sentiasa selari.

Bagaimana pula dengan aplikasi yang langsung tidak mempunyai log masuk?

Forward auth adalah jawapannya, dan ini merupakan situasi yang sering dihadapi oleh pelayan self-hosted. Reverse proxy anda akan bertanya kepada pelayan SSO sama ada sesuatu permintaan dibenarkan sebelum menghantarnya ke aplikasi hulu (upstream). Aplikasi di belakangnya tidak perlu tahu apa-apa tentang SSO. Ia menerima permintaan yang telah disemak oleh proksi, biasanya dengan nama pengguna disertakan dalam header.

Proxy provider dalam authentik merangkumi perkara ini dengan tiga mod yang didokumentasikan. "Proxy" membolehkan authentik outpost menghantar trafik terus kepada aplikasi hulu. "Forward auth (single application)" membiarkan trafik dikendalikan oleh reverse proxy sedia ada anda dan hanya menggunakan authentik untuk semakan pengesahan. "Forward auth (domain level)" melindungi setiap aplikasi di bawah satu domain induk dengan satu provider. Domain level adalah pilihan yang mudah, namun ia mempunyai had yang didokumentasikan: ia "tidak boleh menguatkuasakan peraturan kebenaran peringkat aplikasi yang berbeza bagi setiap aplikasi yang dilindungi", jadi setiap aplikasi di bawah domain tersebut berkongsi set polisi yang sama.

Keycloak tidak mempunyai ciri ini. Proksi pendampingnya, Keycloak Gatekeeper, telah dinamakan semula kepada Louketo Proxy dan kemudian diarkibkan di GitHub, dengan commit terakhir pada Ogos 2023. Untuk melindungi aplikasi yang tidak mempunyai sokongan OIDC, anda perlu menjalankan komponen berasingan di hadapannya, biasanya oauth2-proxy, yang dihalakan kepada klien Keycloak. Zitadel juga tidak mempunyai mod forward auth sendiri, jadi jawapannya tetap sama iaitu memasang komponen tambahan untuk diurus, dipantau dan dikemas kini.

Langkah tambahan tersebut adalah titik di mana konfigurasi reverse proxy mula menjadi rumit, jadi baca cara Traefik mengendalikan beberapa aplikasi Docker Compose sebelum menyambungkan middleware pengesahan ke dalamnya.

Sejauh manakah tahap kesukaran laluan naik taraf?

Sehingga Ogos 2026, keluaran semasa ialah Keycloak 26.7.1, authentik 2026.5.6, dan Zitadel v4.16.3. Ketiga-tiganya menjalankan migrasi skema terhadap PostgreSQL, yang bermaksud setiap naik taraf merupakan perubahan pangkalan data. Sandarkan pangkalan data terlebih dahulu, setiap kali anda melakukannya. Tabiat tunggal itu lebih bernilai daripada sebarang ciri dalam perbandingan ini.

authentik mempunyai peraturan paling ketat dan menyatakannya dengan jelas: "Naik taraf mesti mengikut urutan keluaran utama; jangan melangkau terus daripada versi utama yang lama ke versi yang paling terkini." Anda perlu beralih ke patch terkini dalam setiap versi sebelum melangkah ke versi seterusnya, dan "authentik tidak menyokong penurunan taraf". Ketinggalan setahun pada projek yang menggunakan versi kalendar akan menjadikan satu naik taraf sebagai satu rantaian naik taraf, yang setiap satunya mempunyai migrasi pangkalan data tersendiri.

Panduan naik taraf Keycloak memberikan urutan untuk diikuti: semak perubahan migrasi daripada versi sebelumnya, naik taraf pelayan, kemudian naik taraf penyesuai (adapter). Migrasi pangkalan data berjalan secara automatik, atau anda boleh mengeksportnya dan melaksanakannya secara manual, yang berguna apabila anda ingin membaca perubahan tersebut sebelum ia digunakan. Kos bagi Keycloak ialah proses pembacaan tersebut. Nota keluarannya mengandungi penamatan fungsi (deprecations) dan perubahan tingkah laku yang mudah terlepas pandang dan mahal akibatnya jika terlepas.

Zitadel memisahkan fasa init dan setup daripada pelayan yang sedang berjalan, dan panduan pengeluarannya mengesyorkan agar ia diasingkan supaya penskalaan tidak mengulangi kerja penyediaan. Pada satu VPS tunggal, ini bermakna langkah penyediaan mesti selesai sebelum API melaporkan status sihat, itulah sebabnya fail compose menyertakan pemeriksaan kesihatan dan arahan mula menggunakan --wait.

Sasaran pengguna setiap projek dan kelemahan masing-masing

Keycloak ialah pelayan identiti daripada Red Hat, dibina untuk organisasi yang memerlukan realm, kumpulan, pemetaan peranan dan direktori korporat sedia ada. Ia merupakan implementasi standard yang paling lengkap antara ketiga-tiganya. Ia menjadi pilihan yang kurang sesuai pada VPS 2 GB yang menjalankan empat aplikasi self-hosted, di mana separuh daripadanya tidak menyokong OIDC. Anda akan menggunakan 1250 MB untuk JVM, perlu mempelajari model realm yang direka untuk syarikat, dan masih perlu memasang oauth2-proxy untuk aplikasi yang sebenarnya anda perlukan.

authentik dibina untuk komuniti self-hosting, dan senarai cirinya membuktikan perkara tersebut. Ia menyertakan forward auth dan penyedia LDAP, serta membina aliran log masuk dalam editor visual. Ia menjadi pilihan yang kurang sesuai apabila anda memerlukan kontrak sokongan vendor atau kitaran keluaran (release train) yang tidak berubah setiap beberapa minggu. Versi kalendar tanpa laluan untuk downgrade dan tanpa keupayaan melangkau versi merupakan beban operasi yang nyata, dan editor aliran tersebut memerlukan pembelajaran model baharu sedangkan masalah sebenar anda hanyalah satu klien OIDC.

Zitadel dibina untuk pembangun yang menyertakan pengesahan ke dalam produk yang mereka pasarkan, dengan API yang mantap dan multi-tenancy sebagai ciri utama. Ia menjadi pilihan yang kurang sesuai dalam situasi ini. Empat kontena, tiada forward auth, dan pangkalan data yang bersaiz 4 GB setiap teras adalah konfigurasi yang tidak tepat untuk satu VPS yang hanya menjalankan pengurus kata laluan dan wiki.

Apa yang perlu dijalankan pada satu VPS, dan caranya

Untuk satu VPS dengan tiga atau empat aplikasi yang dihoskan sendiri, jalankan authentik. Ketiga-tiga pilihan ini memberikan anda skrin log masuk. Faktor penentu ialah sesetengah aplikasi anda tidak akan menyokong OIDC, dan authentik menyelesaikan masalah ini dengan ciri forward auth terbina dalam, bukannya menambah komponen lain di sampingnya.

Berikan 4 GB RAM jika boleh, dan 2 GB hanya jika aplikasi di sampingnya bersaiz kecil. Pastikan port 9000 tidak terdedah kepada internet awam dan tamatkan TLS pada reverse proxy di hadapan. Lakukan dump PostgreSQL setiap malam dan simpan di luar pelayan, kerana penyedia identiti tanpa sandaran merupakan titik kegagalan tunggal bagi setiap aplikasi di belakangnya. Jalankan stack tersebut sebagai akaun tanpa keistimewaan (unprivileged) yang khusus dan bukannya sebagai root: menyediakan pengguna dengan keistimewaan minimum pada VPS merangkumi akaun dan pemilikan fail yang diperlukan untuk ini.

Pilih Keycloak sebaliknya apabila setiap aplikasi yang anda lindungi sudah menyokong OIDC atau SAML, atau apabila anda memerlukan model peranan terperinci yang disediakan oleh realm Keycloak. Pilih Zitadel apabila anda sedang membina aplikasi untuk orang lain mendaftar dan anda mahukan API serta model penyewa (tenant) daripadanya. Kedua-duanya bukan kes tiga-aplikasi-dalam-satu-pelayan yang dibincangkan dalam catatan ini.

Mod kegagalan yang akan anda temui terlebih dahulu

Keycloak tiada data selepas dimulakan semula. Anda memulakannya dengan start-dev, yang menggunakan pangkalan data pembangunan setempat. Dalam kontena tanpa volum, memadamkan kontena akan memadamkan realm tersebut. Beralih kepada start dengan KC_DB=postgres dihalakan kepada pangkalan data sebenar.

Kontena pekerja authentik hilang pada pelayan kecil. Pekerja dan pelayan menjalankan imej yang sama dan kedua-duanya mengandungi proses Python, manakala PostgreSQL memerlukan bahagiannya daripada 2 GB hos. Jalankan docker compose ps untuk mengesahkan servis mana yang keluar, kemudian semak dmesg untuk melihat sama ada ia ditamatkan akibat kehabisan memori (out-of-memory kill) sebelum anda mencari pepijat dalam aplikasi.

Konsol Zitadel tidak berfungsi di sebalik proksi anda. API Zitadel menggunakan gRPC, yang memerlukan HTTP/2 sehingga ke hulu (upstream). Halaman keperluan meminta proksi terbalik yang menyokong sambungan hulu HTTP/2 dan menamakan versi yang diuji bagi Traefik v3.x, NGINX v1.x, Caddy v2.x dan Apache httpd 2.4.x. Proksi yang menurunkan sambungan hulu kepada HTTP/1.1 akan menyebabkan halaman log masuk dimuatkan tetapi Konsol gagal berfungsi.

Setiap aplikasi menghantar anda kembali ke skrin log masuk. URL awam pelayan SSO dan URL yang dikonfigurasikan dalam aplikasi mestilah sepadan dengan tepat, termasuk skema dan port. Keycloak memanggil ini sebagai tetapan hostname, Zitadel memanggilnya sebagai domain luaran. Apabila ia tidak sepadan, aplikasi akan mengubah hala ke log masuk yang tidak dikenali oleh pelayan sebagai miliknya, dan pelayar akan melantun antara kedua-duanya.

FAQ

Antara ketiga-tiga pilihan tersebut, yang manakah sesuai untuk VPS 2 GB?

authentik dan Keycloak. Keperluan yang dinyatakan oleh authentik ialah hos dengan sekurang-kurangnya 2 teras CPU dan 2 GB RAM, manakala panduan saiz Keycloak menetapkan memori asas sebanyak 1250 MB untuk pelayan sebelum mengambil kira pangkalan datanya. Kedua-duanya akan menjadi sesak pada 2 GB sebaik sahaja anda menambah aplikasi yang ingin dilindungi, jadi anggap 4 GB sebagai tahap minimum yang selesa. Zitadel menyatakan 2 GB untuk permulaan, tetapi panduan pengeluaran (production) mereka mengesyorkan 4 teras CPU untuk hashing kata laluan dan 4 GB RAM bagi setiap teras pangkalan data, jadi 2 GB bukanlah spesifikasi untuk penggunaan sebenar.

Bolehkah Keycloak atau Zitadel melindungi aplikasi yang tidak mempunyai sistem log masuk sendiri?

Tidak secara sendirian. Kedua-duanya tidak membekalkan komponen forward auth. Proksi pendamping lama Keycloak, iaitu Louketo Proxy, telah diarkibkan di GitHub dengan commit terakhir pada Ogos 2023, jadi ia bukan sesuatu yang boleh dijadikan asas binaan. Anda perlu meletakkan oauth2-proxy atau komponen serupa di antara reverse proxy anda dengan aplikasi tersebut, kemudian halakan ia kepada klien OIDC pada pelayan SSO. authentik melakukan perkara ini secara natif dengan pembekal proksi (proxy provider) dalam mod "Forward auth (single application)" atau "Forward auth (domain level)".

Yang manakah boleh bertindak sebagai pelayan LDAP untuk aplikasi yang hanya menyokong LDAP?

authentik. Pembekal LDAP miliknya berjalan pada outpost dan membolehkan pengguna serta kumpulan dalam authentik dicari melalui LDAP, dengan LDAPS tersedia pada port 636. Ia bersifat baca sahaja (read-only), jadi fungsi bind dan carian berfungsi manakala fungsi tulis tidak. Keycloak dan Zitadel berfungsi sebaliknya: kedua-duanya membaca daripada direktori LDAP sedia ada sebagai sumber pengguna, dan tiada satu pun yang menjawab bind LDAP daripada aplikasi.

Bolehkah saya melangkau versi semasa menaik taraf authentik?

Tidak. Dokumentasi menyatakan bahawa naik taraf mesti mengikut urutan keluaran utama (major releases), dan anda tidak sepatutnya melangkau daripada versi utama yang lama terus ke versi yang paling baharu. Beralih kepada keluaran patch terkini dalam setiap versi terlebih dahulu, kemudian naik satu versi pada satu masa. Lakukan sandaran (backup) PostgreSQL sebelum setiap langkah, kerana authentik tidak menyokong penurunan versi (downgrading) dan migrasi hanya berjalan ke hadapan.