Backend multi-tenant: satu instalasi, banyak workspace
Butuh backend multi-tenant yang melayani banyak klien dari satu instalasi? Kanesh memberi tiap workspace skema, anggota, peran, API, dan MCP sendiri.
Backend multi-tenant melayani beberapa klien atau produk dari satu instalasi, sambil memisahkan data, pengguna, dan izin mereka. Di Kanesh, setiap workspace punya skema, anggota, peran, API REST dan GraphQL, serta endpoint MCP sendiri, jadi klien baru berarti workspace baru, bukan server baru. Satu workspace per instalasi gratis, dan workspace tanpa batas biayanya $9 per bulan per instalasi.
Dua arti multi-tenant
Istilah ini mencakup dua desain, dan keduanya cocok untuk masalah yang berbeda.
- Skema bersama. Satu set tabel dengan kolom tenant di setiap baris. Kodemu sendiri harus memfilter tenant di setiap query.
- Workspace terpisah. Setiap tenant punya skema, anggota, dan izin sendiri di dalam satu instalasi.
Kanesh memakai yang kedua. Workspace adalah proyek independen yang kebetulan berjalan di proses yang sama. Itu cocok untuk agensi dengan beberapa klien, tim dengan satu alat per departemen, atau developer dengan beberapa proyek sampingan. Ini bukan filter tenant per baris di dalam satu skema.
Isi setiap workspace
| Bagian | Yang terpisah |
|---|---|
| Skema | Koleksi, field, relasi, dan index |
| Anggota | Siapa yang bisa masuk ke workspace |
| Peran | Owner, Administrator, Editor, Viewer, dan Public, plus hingga 20 peran khusus dan 50 kebijakan |
| API | REST, GraphQL, dan ekspor OpenAPI 3.1 untuk skema itu |
| MCP | Satu endpoint read-only (opt-in) per workspace |
Setiap request membawa workspace di path-nya, jadi dua klien tidak pernah berbagi endpoint:
GET /api/v1/workspaces/WORKSPACE_ID/collections/orders/recordsIzin diatur per workspace. Token API pribadi bertindak sebagai pengguna yang membuatnya, sehingga token hanya menjangkau apa yang bisa dijangkau pengguna itu. Kontrol akses berlaku sama untuk Studio, REST, GraphQL, dan MCP. Lihat kontrol akses.
Kenapa ini menghemat pekerjaan operasional
Dengan satu server per klien, kamu merawat satu container, satu database, satu job backup, dan satu set upgrade untuk masing-masing. Dengan workspace, kamu merawat masing-masing hanya satu. Kanesh adalah satu binary Go dengan Studio tertanam, dalam image sekitar 8,9 MB (arm64, diukur 2026-10-04), dan memorinya idle di bawah 10 MiB pada smoke test lokal. Itu bukan benchmark, dan belum termasuk datamu atau database eksternal.
Klien berikutnya adalah workspace baru di Studio. Owner menambahkan anggota dan memberi masing-masing satu peran untuk workspace itu.
Perbandingan soal workspace
| Kanesh | PocketBase | Appwrite | |
|---|---|---|---|
| Proyek per instalasi | Banyak workspace terpisah | Satu aplikasi per instance | Banyak proyek per instance |
| Bentuk self-host | Satu container | Satu executable | Tumpukan Docker Compose multi-container |
| Database | SQLite, PostgreSQL, MySQL | SQLite tertanam | Tidak dibandingkan di sini |
Biaya untuk banyak workspace
Satu workspace per instalasi gratis, dengan semua fitur core. Untuk menjalankan workspace tanpa batas dalam satu instalasi, kamu butuh Pro, harga flat $9 per bulan per instalasi tanpa biaya per kursi. Pro juga mencakup asisten AI di Studio, yang masih dalam pengembangan. Inti Kanesh berlisensi AGPL-3.0, dan kode Pro di ee/ berada di bawah Kanesh Commercial License (draf). Kalau key kedaluwarsa, workspace tambahan jadi read-only dan tidak ada yang dihapus. Lihat harga.
Batasan yang perlu diketahui
Satu instalasi dikonfigurasi dengan satu database, jadi semua workspace-nya berbagi server database itu. Pemisahannya bersifat logis, dengan skema, anggota, dan peran sendiri untuk tiap workspace. Kalau seorang klien butuh server database terpisah atau isolasi infrastruktur yang ketat, jalankan instalasi terpisah untuknya.
Hanya ada satu owner per instalasi, dan kepemilikan bisa dipindahkan. Beri klien peran Administrator atau Editor di dalam workspace mereka sendiri. Kalau kamu mengharapkan banyak tenant yang berbagi skema yang sama, modelkan tenant sebagai koleksi dan terapkan di layananmu sendiri.
Kanesh juga belum punya realtime, OAuth atau SSO, workflow, maupun SDK. Realtime, login OAuth atau SSO, dan workflow ada di roadmap.
FAQ
Apa itu backend multi-tenant?
Backend yang melayani lebih dari satu pelanggan, tim, atau produk dari instalasi yang sama sambil memisahkan data dan izin mereka. Desainnya berkisar dari satu skema bersama dengan kolom tenant sampai skema terpisah per tenant. Kanesh memakai workspace terpisah.
Apakah setiap workspace punya API dan endpoint MCP sendiri?
Ya. Setiap workspace punya API REST dan GraphQL sendiri, ekspor OpenAPI sendiri, dan, saat MCP_ENABLED=true, endpoint MCP read-only sendiri. Token membawa izin pengguna yang membuatnya.
Bisakah saya memindahkan workspace ke instalasi lain nanti?
Kamu bisa mengekspor record sebagai CSV atau JSON dengan batas ukuran dan mengimpornya ke koleksi di instalasi lain. Buat dulu koleksi dan tipe field-nya. Uji dengan koleksi kecil sebelum mengandalkannya untuk klien.
Langkah berikutnya
Buat workspace pertamamu lewat Memulai. Untuk melihat perbedaan dengan backend satu-aplikasi-per-instance, baca Kanesh vs PocketBase.
Baca juga
Mengenal Kanesh, backend AI-first yang kecil
Kenapa kami membangun platform data self-hosted yang muat di satu container dan bicara MCP di samping REST dan GraphQL.
MVP backend: kapan data statis cukup dan kapan perlu API
Pilih MVP backend sesuai kebutuhan: bandingkan data statis dan API, hitung biaya migrasi, dan mulai dengan koleksi Kanesh tanpa menulis backend sendiri.
Satu backend per klien membuat saya terus mengulang setup
Berulang kali menyiapkan Directus untuk proyek klien membuat saya membangun backend multi-tenant dengan workspace terpisah dalam satu instalasi Kanesh.