CIAM Self-Hosted Terbaik untuk Pembangun SaaS B2B

Kalau Anda pernah melihat harga beberapa platform CIAM berbasis SaaS, Anda mungkin sudah menyadari betapa mahalnya biaya itu bisa membengkak dan kemungkinan besar sempat mempertimbangkan opsi self-hosted.

Artikel ini membahas empat platform CIAM self-hosted yang benar-benar bisa dijalankan tim SaaS B2B kecil tanpa berubah menjadi pekerjaan penuh waktu kedua: ZITADEL, FusionAuth, Logto, dan Ory Hydra. Bentuknya tidak sama semua, dan mana yang tepat untuk Anda lebih ditentukan oleh jenis produk B2B yang Anda bangun ketimbang daftar fitur. Saya menjalankan keempatnya berdampingan di satu VPS selama seminggu untuk menyusun perbandingan ini, dan berikut adalah versi yang akan saya kirim ke seorang founder yang menghubungi saya soal CIAM.

Satu hal di awal: ini soal CIAM sebagai fitur produk, bukan SSO internal untuk tim Anda sendiri.

Versi Singkat

Empat platform CIAM self-hosted, masing-masing satu baris:

• ZITADEL kalau Anda ingin multi-tenancy dan organisasi B2B langsung tersedia.
• FusionAuth kalau Anda ingin UI admin yang rapi dan riwayat rilis yang panjang serta dapat diprediksi.
• Logto kalau Anda ingin pengalaman developer paling bersih di hari pertama.
• Ory Hydra kalau Anda membangun di level protokol dan menginginkan mesin OAuth 2.0, bukan aplikasi login yang sudah dipaketkan.

Intinya: ZITADEL adalah taruhan pertama paling aman untuk SaaS B2B pada umumnya, dan sisa artikel ini menguraikan alasannya.

Kenapa CIAM Adalah Keputusan yang Berbeda dari SSO Internal

Kalau SSO untuk tim internal Anda tumbang, kerusakannya biasanya terbatas. Para engineer mungkin kehilangan akses ke Grafana atau perkakas internal lain selama satu jam. Kalau CIAM yang tumbang, pelanggan berbayar Anda sama sekali tidak bisa masuk ke produk. Itu mengubah pertanyaannya dari "perkakas autentikasi mana yang nyaman untuk tim kami?" menjadi "sistem autentikasi mana yang bisa kami percaya sebagai bagian dari produk itu sendiri?"

CIAM, jenis infrastruktur identitas yang dibutuhkan SaaS B2B, juga memerlukan primitif yang tidak ditonjolkan banyak perkakas SSO internal. Pelanggan Anda bukan satu pengguna; ia adalah sebuah organisasi (tenant) dengan pengguna, peran, branding sendiri, dan mungkin koneksi SAML sendiri ke IdP korporat. Anda bukan sekadar mengautentikasi orang; Anda mengisolasi pengguna satu perusahaan dari pengguna perusahaan lain di dalam produk yang sama. Inilah bentuk B2B yang dibidik keempat perkakas di bawah, masing-masing dengan caranya sendiri. Keycloak kini punya Organizations kelas satu, jadi menganggapnya hanya untuk karyawan internal sudah ketinggalan zaman; alasan ia tidak masuk daftar saya jelaskan di FAQ.

Segitiga bangun sendiri, beli, atau self-host juga terlihat berbeda di sini. Menulis OAuth dari nol adalah kesalahan yang tidak perlu. Anda merilis produk SaaS, bukan penyedia identitas. Membeli layanan terkelola (Auth0, Clerk, WorkOS) adalah pilihan tepat ketika tim Anda tidak punya kapasitas ops sama sekali dan anggarannya masuk akal. Saya tidak akan pernah menyuruh startup dua orang menjalankan autentikasi sendiri di hari pertama. Self-hosting jadi masuk akal ketika harga per MAU dari CIAM terkelola melampaui biaya infrastruktur plus waktu engineering yang terus berjalan, atau ketika Anda butuh kendali langsung atas deployment dan data plane. Di tim-tim yang pernah saya dampingi, titik itu biasanya jatuh di antara "kami sudah punya produk sungguhan" dan "kami sudah punya fungsi customer success sungguhan".

Kalau yang Anda cari adalah SSO untuk aplikasi Anda sendiri, bukan aplikasi pelanggan, itu perbandingan yang lain, bukan yang ini. Mari lanjut ke pilihan utama kami.

Empat Perkakas, Satu per Satu

Saya memilih keempatnya karena bentuknya cukup CIAM untuk dinilai sebagai infrastruktur produk, bukan sekadar SSO internal. ZITADEL, FusionAuth, Logto, dan Ory sama-sama memberi jalur self-hosted yang nyata dan cukup traksi untuk dipertimbangkan serius. Opsi yang hanya berupa pustaka, yang berfokus pada SSO karyawan, dan yang belum matang lebih pas dibahas di FAQ.

ZITADEL

ZITADEL adalah platform identitas buatan Swiss yang ditulis dengan Go, memakai arsitektur event-sourced dan backend PostgreSQL. Per 27 Juli 2026, rilis GitHub terbarunya adalah the 4.16 series, current as of July 2026. ZITADEL berpindah dari Apache 2.0 ke AGPL-3.0 mulai v3; untuk pemakaian SaaS biasa, dampak praktisnya umumnya tidak seseram kedengarannya, dan detailnya saya bahas di FAQ.

Yang membedakan ZITADEL untuk SaaS B2B: organisasi dan multi-tenancy adalah primitif kelas satu, bukan fitur yang Anda rakit dari objek generik. Anda membuat sebuah Organization, ia mendapat pengguna, kebijakan, branding, dan pengaturan akses sendiri, dan Anda bisa memberikan proyek kepadanya sehingga adminnya mengelola penetapan peran untuk pengguna mereka sendiri. Anda tidak perlu mengarang konsep "tenant" di atas pengguna generik. Anda sudah mulai dari sana.

Pengalaman developernya API-first, dengan API sumber daya REST v2 saat ini plus akses gRPC dan REST ke layanan v1 lama. SDK resmi dan komunitas mencakup stack server yang umum. Konsol admin-nya fungsional tapi lebih polos ketimbang milik FusionAuth.

Pandangan saya: Kalau Anda membangun SaaS B2B dan tahu akan punya tenant, saya akan mulai dari ZITADEL. Di antara opsi self-hosted, inilah yang paling jelas dibentuk di sekitar persoalan login B2B.

FusionAuth

FusionAuth adalah platform asal Amerika Serikat dari Inversoft, LLC (sebuah LLC Delaware yang beroperasi sebagai FusionAuth) yang sudah ada lebih lama dari tiga lainnya, dan itu terasa, dalam arti bagus. Antarmuka adminnya terasa jauh lebih dirancang ketimbang yang lain, dokumentasinya matang, dan irama rilisnya mantap alih-alih ngebut. Kalau Anda pernah mewarisi integrasi autentikasi berumur empat tahun dan diam-diam berterima kasih kepada engineer sebelumnya karena memilih opsi yang membosankan, FusionAuth adalah versi CIAM yang pantas menerima terima kasih itu.

Yang bikin orang tersandung adalah lisensinya: FusionAuth Community gratis untuk di-self-host, tapi produk intinya bukan open source. Produk ini tunduk pada lisensi milik FusionAuth sendiri, dan batasannya penting kalau Anda berencana mendistribusikan ulang, menyematkan, mengganti merek, menjual kembali, atau meng-hosting FusionAuth untuk pelanggan Anda sendiri. Community yang di-self-host sudah menutup kasus inti SaaS B2B; paket berbayar menambah fitur seperti SAML yang diinisiasi IdP, MFA lanjutan, dan tema khusus per aplikasi, sementara SCIM, Tenant Manager, dan kebijakan MFA di level aplikasi ada di Enterprise.

Soal bentuk B2B: FusionAuth memodelkan tenant dan aplikasi, tapi abstraksinya lebih ke "autentikasi terkontainerisasi per tenant" ketimbang "organisasi B2B sebagai objek domain". Ini berfungsi (saya pernah merilis produk di atasnya), tapi multi-tenancy-nya terasa lebih seperti primitif isolasi daripada model B2B kelas satu. SDK resmi dan pustaka kliennya luas:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Pustaka sisi servernya adalah klien API tipis. Konsol adminnya relatif lebih mudah diserahkan ke orang ops non-engineer dibanding yang lain.

Pandangan saya: Kalau tim Anda lebih menghargai kerapian antarmuka dan riwayat panjang yang bisa diprediksi ketimbang primitif asli B2B, pilih FusionAuth. Ini pilihan paling "membosankan" di sini, dan itu pujian.

Logto

Logto adalah yang termuda dari keempatnya, dikembangkan oleh Silverhand Inc. dan berlisensi MPL-2.0, dan dialah yang paling kelihatan peduli pada dasbornya. Penyiapan hari pertama relatif cepat. Anda melakukan provisioning, mengeklik wizard, dan dalam kira-kira lima belas menit sudah punya penyedia OIDC yang jalan dengan UI login bawaan yang layak (saya menghitungnya di minggu ketika menjalankan keempatnya berdampingan). Panduan cepat resminya mencakup framework dan stack server modern, jadi kalau stack Anda "Next.js + Postgres + sesuatu", Anda akan langsung nyaman.

Jawaban B2B-nya disebut Logto Organizations. Ia menutup primitif B2B inti: keanggotaan organisasi, peran dengan cakupan organisasi, undangan anggota, provisioning just-in-time, dan integrasi SSO enterprise. Model organisasinya lebih muda dibanding milik ZITADEL, jadi saya akan menguji alur SAML, SCIM, atau federasi yang tidak lazim terhadap calon pelanggan Anda sebelum berkomitmen.

Trade-off-nya adalah kematangan: Logto adalah opsi termuda di sini. Roadmap-nya bergerak cepat, yang menyenangkan saat fitur yang Anda butuhkan mendarat dan tidak nyaman saat perubahan yang merusak kompatibilitas yang mendarat. Kalau SaaS B2B Anda berada di ujung yang lebih sederhana dari spektrum multi-tenancy (segelintir organisasi dan tanpa kebutuhan federasi yang aneh-aneh), pengalaman developer Logto membuat sisa keputusannya jadi lebih mudah.

Pandangan saya: Kalau Anda mau hari pertama tercepat dan kebutuhan B2B Anda masih relatif sederhana, pilih Logto.

Ory Hydra (dan Stack Ory)

Ory Hydra adalah server OAuth 2.0 / OpenID Connect dari ekosistem Ory, berlisensi Apache-2.0. Stack Ory lengkap memasangkan Hydra dengan Ory Kratos (identitas dan manajemen pengguna, login swalayan, registrasi, MFA, dan pemulihan akun), Ory Keto (server otorisasi bergaya Zanzibar yang berperan sebagai policy decision point), dan Ory Oathkeeper (proxy identitas dan akses yang mengautentikasi, mengotorisasi, serta memodifikasi permintaan HTTP yang masuk). Anda merakit apa yang Anda butuhkan. Semuanya ditulis dengan Go dan API-nya rapi.

Tangkapannya (dan ini bukan cacat; bagi tim yang tepat justru keunggulan) adalah bahwa Hydra itu mesinnya, bukan aplikasinya. Secara desain, Hydra terhubung ke aplikasi login dan consent yang terpisah yang Anda sediakan sendiri. Kalau Anda ingin layar login siap pakai, ini bukan perkakasnya. Kalau Anda membangun sesuatu yang alur autentikasinya adalah bagian dari produk (platform developer, portal B2B khusus, atau produk API-first dengan onboarding buatan sendiri), ketiadaan UI yang memaksakan justru persis yang Anda mau.

Cerita B2B-nya bersifat komposabel, bukan siap pakai. Anda bisa memodelkan multi-tenancy dengan menyambungkan skema Kratos dan relasi Keto ke lapisan organisasi Anda sendiri, dan itu berhasil, tapi penyambungannya Anda yang kerjakan. Biayanya lebih banyak pekerjaan pipa; imbalannya kendali atas pengalaman. Dokumentasi Ory membahas permukaan protokol secara mendalam, tapi model komposabel mengandaikan Anda nyaman mengambil keputusan di level protokol. Kalau "audience claim" atau "PKCE" tidak berarti apa-apa bagi Anda, mulailah dari salah satu dari tiga yang lain.

Pandangan saya: Kalau Anda membangun sesuatu di level protokol (gateway autentikasi, alur kustom, platform developer) dan aplikasi standar terasa mengekang, Ory adalah jawaban yang tepat. Untuk SaaS B2B biasa yang ingin login jalan hari ini, bukan.

Perbandingannya Sekilas

Berikut ringkasan keempat perkakas dalam satu tabel, berguna untuk pembacaan kedua, bukan pengganti profil di atas.

Mulai dari yang Mana?

Empat skenario singkat yang mencakup sebagian besar tim yang biasanya saya ajak bicara soal ini.

Anda membangun SaaS B2B dan tahu akan punya tenant. Mulailah dari ZITADEL. Primitif multi-tenancy dan organisasinya memang dirancang persis untuk ini, permukaan API-nya lengkap, dan Anda akan menghabiskan lebih sedikit waktu mengarang model tenant dibanding tiga lainnya. Perpindahan ke AGPL layak ditinjau dari sisi lisensi, tapi deployment yang tidak dimodifikasi dan diintegrasikan secara terpisah biasanya kasus SaaS yang lurus-lurus saja.

Anda ingin UI admin yang rapi dan platform yang stabil serta bisa diprediksi. FusionAuth. Paket Community menutup kebutuhan inti banyak tim; sediakan waktu untuk membaca lisensi dan matriks fiturnya dengan teliti. Fitur seperti SAML yang diinisiasi IdP, MFA lanjutan, dan tema khusus per aplikasi memerlukan paket berbayar, sedangkan SCIM, Tenant Manager, dan kebijakan MFA level aplikasi ada di Enterprise.

Kebutuhan B2B Anda hari ini sederhana dan Anda mau hari pertama tercepat. Logto. Pengalaman developer di hari pertamanya paling cepat dalam pengujian berdampingan saya. Terimalah bahwa Anda bertaruh pada ekosistem yang lebih muda, dan tinjau ulang pilihan itu kalau kebutuhan Anda tumbuh ke kasus tepi federasi yang belum Anda uji.

Anda membangun sesuatu yang alur autentikasinya adalah bagian dari pengalaman produk. Ory Hydra (ditambah Kratos, ditambah Keto kalau Anda butuh izin). Anda akan menulis lebih banyak kode. Anda akan punya lebih banyak kendali. Kalau pertukaran itu tidak terasa jelas bagi Anda, Anda bukan audiens Ory. Pilih saja salah satu dari tiga yang lain.

Kalau dua dari deskripsi ini terdengar seperti Anda, pilih ZITADEL sebagai default. Dialah yang paling luas kecocokannya dan yang akan saya serahkan ke tim pendiri kecil tanpa banyak pertanyaan lanjutan.

Apa yang Dituntut Self-Hosting dari Anda (Secara Operasional)

Ini bagian artikel yang tidak romantis.

Disiplin backup PostgreSQL Anda kini jadi sesuatu yang menopang bisnis. Di seluruh deployment ini, state identitas yang harus Anda lindungi bisa mencakup rekaman pengguna, kredensial ter-hash, rahasia MFA, kredensial klien OAuth, dan data sesi. Hilangkan state itu, dan pelanggan Anda bisa kehilangan kemampuan untuk masuk. Siapkan backup otomatis sebelum pengguna asli pertama Anda mendaftar, uji proses restore-nya, dan taruh kesehatan backup di kanal peringatan yang sama dengan uptime aplikasi.

Irama rilis berubah seiring waktu. ZITADEL v4.16.1 keluar pada 17 Juli 2026 setelah beberapa rilis di bulan Juni, sementara setiap proyek di sini punya irama dan kebijakan kompatibilitasnya sendiri. Perlakukan irama itu sebagai urusan pemeliharaan, bukan jalan pintas menilai kualitas. Baca catatan rilis sebelum menjalankan docker compose pull, dan jadwalkan jendela patch berkala. Melewatkan pembaruan penyedia identitas berbulan-bulan bisa membuat Anda tertinggal dari perbaikan keamanan dan kompatibilitas saat audit sungguhan pertama Anda.

Hal-hal sepele yang selalu menyergap dari belakang: perpanjangan sertifikat TLS (pakai reverse proxy dengan Let's Encrypt, otomatiskan perpanjangannya, dan pasang peringatan saat gagal), konfigurasi mailer keluar untuk email verifikasi dan reset kata sandi (SES, SendGrid, Postmark: pilih satu dan atur SPF/DKIM/DMARC dengan benar atau email reset Anda akan mendarat di spam), rotasi kredensial klien OAuth ketika ada engineer yang keluar, serta pembatasan laju pada endpoint login supaya serangan credential stuffing tidak memaku CPU Anda.

Tips: kalau Anda memakai Postgres terkelola, jangan berasumsi pengguna database saat runtime juga bisa membuat skema. Buat dulu database dan penggunanya, berikan hak kepemilikan atau hak setup yang diperlukan, lalu jalankan setup pertama dengan kredensial yang diharapkan masing-masing perkakas. Kalau tidak, run pertama Anda bisa gagal dengan pesan izin database yang samar, dan Anda akan membakar satu jam mengejar hal yang keliru.

Apa yang dihemat jalur self-hosted dalam dolar, ditagihnya dalam bentuk kepemilikan. Setelah pemasangan, anggarkan beberapa jam engineering per bulan untuk menjaga lapisan identitas tetap sehat. Tim yang mengalokasikan nol waktu biasanya baru menemukan biayanya belakangan: saat ada gangguan, pada kasus tepi SAML yang aneh, atau di audit keamanan pertama mereka.

Di Mana Sebaiknya Dipasang

VPS Linux yang menjalankan Docker Compose bisa jadi titik awal yang masuk akal untuk evaluasi dan beban kerja sedang, tapi sizing produksi dan ketersediaan tinggi bergantung pada trafik, kebutuhan keamanan, dan seberapa tahan Anda terhadap downtime. Begini posisi opsi deployment yang umum:

• Hosting bersama tidak bisa menjalankan satu pun dari mereka. Mereka butuh penyimpanan persisten, port khusus, akses root untuk runtime kontainer, dan backend database sungguhan. PostgreSQL adalah jalur bawaan untuk sebagian besar daftar ini, tapi secara harfiah bukan satu-satunya database yang didukung setiap perkakas.
• Kubernetes bisa menjalankan keempatnya, tapi jalur resminya tidak merata. ZITADEL, FusionAuth, dan Ory menerbitkan Helm chart resmi, sementara dokumentasi self-hosting Logto berfokus pada deployment Docker dan VM. Untuk SaaS B2B kecil yang belum sampai pada titik di mana Kubernetes membayar dirinya sendiri di tempat lain, ini biasanya over-engineering. Ambil jalur itu ketika sisa infrastruktur Anda memang sudah ada di sana.
• Bare metal tidak masalah kalau Anda memang sudah di sana. Sebagian besar tim SaaS B2B tidak.

Untuk pilot kecil satu node, saya akan mulai dari 4 GB RAM, 2 vCPU, dan 60 GB penyimpanan NVMe, lalu melakukan load test pada alur login yang sebenarnya. Itu baseline perencanaan, bukan minimum produksi universal. Aplikasinya relatif ringan, tapi PostgreSQL butuh memori dan hashing kata sandi butuh ruang CPU. Panduan produksi ZITADEL menyarankan menyediakan empat inti CPU untuk lonjakan hashing kata sandi.

Setelah produk jadi nyata dan trafiknya stabil, sesuaikan ukuran berdasarkan pengukuran. Penyimpanan cepat membantu latensi PostgreSQL, sementara ruang CPU penting saat hashing kata sandi berjalan bersamaan. Pantau memori, I/O database, latensi login, dan saturasi CPU alih-alih mengasumsikan satu sumber daya yang paling menentukan.

Menjalankan CIAM di produksi berarti uptime-nya kini jadi urusan Anda. Kami menjalankan instance Cloudzy Linux VPS untuk beban kerja semacam ini, dengan penyimpanan NVMe dan SLA uptime 99,95% pada platform yang mendasarinya. Cloudzy juga menyediakan VPS ZITADEL sekali klik kalau Anda lebih suka melewati skrip provisioning awal; tiga lainnya menyediakan image kontainer resmi untuk pemasangan berbasis Docker. Untuk pandangan setingkat manajer tentang bagaimana kontrol akses cocok dengan sisa postur keamanan Anda, panduan praktik terbaik IAM membahasnya dari sisi kebijakan.

Pertanyaan yang Sering Diajukan

Apakah Lisensi AGPL ZITADEL Memengaruhi SaaS Saya?

Biasanya tidak untuk deployment yang tidak dimodifikasi dan diintegrasikan secara terpisah, tapi ini bukan nasihat hukum. Kewajiban AGPL ZITADEL berlaku untuk ZITADEL itu sendiri. Kalau Anda memodifikasi ZITADEL dan mengoperasikan versi termodifikasi itu sebagai layanan jaringan, lisensinya bisa mewajibkan Anda menyediakan kode sumber yang bersesuaian di bawah AGPL. Posisi resmi ZITADEL adalah bahwa sekadar memakai instance yang tidak dimodifikasi sebagai layanan identitas SaaS Anda, dengan sendirinya, tidak mewajibkan Anda melisensikan aplikasi terpisah Anda di bawah AGPL. Baca pengumuman lisensi dari ZITADEL dan mintalah nasihat hukum kalau Anda memodifikasi, mendistribusikan ulang, menyematkan, atau menawarkan perangkat lunaknya ke pihak ketiga. Lisensi komersial juga tersedia.

Kenapa Keycloak atau Authentik Tidak Ada di Daftar Ini?

Keycloak dan Authentik adalah perkakas identitas self-hosted yang sangat baik (saya memakainya), tapi menyingkirkan Keycloak karena dianggap tidak punya organisasi B2B kini keliru: rilis Keycloak terkini sudah menyertakan Organizations, grup organisasi, dan kontrol administrasi terdelegasi. Saya tidak memasukkannya karena perbandingan ini berfokus pada empat opsi dengan jalur yang lebih langsung untuk SaaS B2B tim kecil; Keycloak layak dievaluasi tersendiri ketika operasional JVM, kedalaman ekosistem, dan fleksibilitas level realm menjadi penting. Authentik tetap lebih cocok untuk SSO karyawan dan aplikasi internal ketimbang pemodelan tenant yang menyatu dengan produk.

Apakah Self-Hosting Lebih Murah dari Auth0?

Pada MAU rendah, sering kali tidak. Jam kerja engineering Anda lebih mahal daripada tagihan Auth0 di tingkat startup awal. Self-hosting menang secara ekonomi pada skala ketika harga per MAU CIAM terkelola melampaui gabungan biaya VPS kecil plus beberapa jam engineering per bulan yang akan Anda habiskan untuknya. Titik impas persisnya bergantung pada biaya per jam tim Anda, kurva pertumbuhan MAU, dan apakah produk Anda butuh fitur enterprise yang mendorong Anda ke tingkat harga Auth0 yang lebih mahal. Anggap penghematannya nyata, tapi tidak instan.

Berapa Ukuran VPS Minimum untuk CIAM Produksi?

Untuk pilot kecil satu node, 4 GB RAM, 2 vCPU, dan penyimpanan NVMe adalah titik awal yang masuk akal, bukan jaminan produksi. Tentukan ukurannya dari jejak database, beban login bersamaan, biaya hashing kata sandi, dan target uptime Anda. Panduan produksi ZITADEL sendiri menyarankan empat inti CPU tersedia untuk lonjakan hashing; perkakas lain dan pola trafik lain butuh uji beban masing-masing.

Bisakah Saya Bermigrasi dari CIAM Terkelola ke Self-Hosted Nanti?

Bisa, tapi rencanakan sebagai proyek sungguhan. Reset kata sandi bukan keharusan: kemampuan ekspor dan format hash yang didukung berbeda-beda, dan sebagian target mendukung migrasi pengguna secara massal atau just-in-time , sementara yang lain mengharuskan reset. Faktor MFA, klien OAuth, sesi aktif, status verifikasi email, serta pemetaan tenant atau peran perlu penanganan terpisah. Kalau Anda sudah menduga akan self-host di kemudian hari, catat batasan ekspor dan migrasi itu sebelum memilih penyedia terkelola.