Satu backend per klien membuat saya terus mengulang setup

Menangani banyak klien berarti saya harus menyiapkan instance Directus terpisah untuk setiap proyek, lengkap dengan server, pembaruan, dan admin masing-masing. Pekerjaan yang terus berulang itu menjadi alasan saya membuat Kanesh dengan banyak workspace independen dalam satu instalasi.

Masalahnya

Directus adalah produk yang bagus. Saya bisa mengelola data tanpa membuat antarmuka admin dari awal untuk setiap klien. Yang mulai terasa melelahkan adalah mengulang pekerjaan di sekitar instalasinya setiap kali ada proyek baru.

Untuk setiap klien, saya menjalankan instance baru. Artinya ada server lain yang perlu dirawat, instalasi lain yang perlu diperbarui, dan admin lain yang perlu saya buka saat ada perubahan. Kalau dilihat satu per satu, setup itu masuk akal. Setelah jumlahnya bertambah, pengulangannya mulai terasa.

Saya lalu mempertanyakan satu kebiasaan dalam cara saya bekerja: apakah klien baru selalu membutuhkan instalasi backend baru? Klien memang perlu model data dan akses sendiri. Saya ingin mempertahankan batas itu tanpa harus menyiapkan seluruh kebutuhan operasionalnya dari awal lagi.

Itulah konteks cerita ini. Saya tidak sedang mencari kesalahan Directus. Ada pekerjaan berulang dalam keseharian saya yang ingin saya kurangi. Halaman perbandingan dengan Directus menjelaskan perbedaan yang lebih luas, termasuk posisi Kanesh yang jauh lebih baru.

Yang saya inginkan

Saya ingin membuka instalasi yang sama, lalu membuat workspace untuk proyek berikutnya. Workspace itu harus punya skema, anggota, dan peran sendiri. Data setiap klien berbeda, begitu juga orang yang bertanggung jawab mengelolanya. Berbagi instalasi seharusnya tetap mempertahankan perbedaan tersebut.

Saya juga ingin batas yang sama berlaku saat proyek terhubung ke layanan lain. Aplikasi memakai API milik workspace-nya. Agent terhubung ke endpoint MCP workspace tersebut. Satu instalasi tidak berarti seluruh proyek harus dianggap sebagai satu kumpulan data yang bisa diakses bersama.

Tujuan saya sederhana: mengurangi waktu untuk setup infrastruktur yang berulang agar saya bisa mengerjakan kebutuhan proyek. Saya tetap harus merawat instalasi, memeriksa akses, dan menyiapkan backup. Menggabungkan pekerjaan itu ke satu tempat mengubah cara saya menanganinya, tetapi tanggung jawabnya tetap ada.

Cara workspace menyelesaikannya

Di Kanesh, setiap workspace punya skema, anggota, peran, API, dan endpoint MCP sendiri. Saya bisa menempatkan proyek-proyek independen dalam satu instalasi sambil mengatur aksesnya secara terpisah. Panduan kontrol akses menjelaskan bagaimana izin workspace berlaku di Studio, REST, GraphQL, dan MCP.

Dibandingkan dengan cara saya bekerja sebelumnya, perubahan operasional yang saya inginkan seperti ini:

Tanggung jawab	Satu instance per klien	Satu instalasi, banyak workspace
Server	Server terpisah untuk setiap klien dalam setup saya	Satu instalasi Kanesh bersama; workspace berbagi server database
Pembaruan	Mengulang pembaruan untuk setiap instance	Memperbarui instalasi bersama
Backup	Menyiapkan rencana backup tiap instance	Merencanakan backup instalasi bersama beserta datanya
Login admin	Membuka admin terpisah milik setiap klien	Memakai satu Studio dengan keanggotaan dan peran per workspace
Endpoint API	Endpoint instance terpisah untuk tiap klien	Endpoint API khusus workspace dalam instalasi yang sama

Bagian backup perlu diperjelas. Jumlah instalasi yang lebih sedikit mengurangi tempat yang perlu saya urus, tetapi beberapa proyek kini berada dalam tanggung jawab operasional yang sama. Rencana backup dan pemulihannya harus memperhitungkan semua proyek tersebut. Batas workspace bukan server database terpisah.

Untuk akses agent, MCP saat ini perlu diaktifkan secara khusus dan hanya bisa membaca data. Aturan otorisasinya sama dengan antarmuka lain di workspace tersebut. Halaman data untuk agent bisa menjadi bacaan berikutnya jika proyekmu membutuhkan akses semacam itu.

Model workspace saya bahas lebih lanjut di satu instalasi, banyak workspace. Satu workspace per instalasi gratis, dan workspace tanpa batas butuh Pro seharga $9 per bulan per instalasi; lihat harga. Untuk mencobanya, ikuti panduan memulai.

Yang belum tersedia

Kanesh masih baru, di rilis stabil pertamanya. Realtime, OAuth, workflow, dan function ada di roadmap. Saya ingin cerita tentang alasan membuat Kanesh tetap jelas membedakan kebutuhan yang melatarbelakanginya dengan fitur yang sudah bisa dipakai sekarang.

Hanya ada satu owner per instalasi. Semua workspace berbagi server database instalasi tersebut, meskipun skema, anggota, dan perannya terpisah. Kalau klien membutuhkan server database sendiri atau kendali atas instalasinya sendiri, saya tetap akan memakai instalasi terpisah untuk klien itu.

FAQ

Apakah ini alasan untuk berhenti memakai Directus?

Bagi saya, ini alasan untuk membuat sesuatu yang mengurangi biaya setup berulang. Directus tetap produk yang bagus. Kalau fitur dan model deployment-nya sesuai dengan pekerjaanmu, cerita ini tidak berarti kamu perlu menggantinya. Keputusan saya berangkat dari kebutuhan yang saya hadapi sendiri.

Apakah setiap klien mendapatkan owner sendiri?

Tidak. Kanesh punya satu owner untuk setiap instalasi. Masing-masing workspace punya anggota dan peran sendiri, tetapi pengelolaannya tetap berada di bawah kepemilikan instalasi tersebut. Saya tidak menganggap workspace sebagai instalasi yang sepenuhnya berdiri sendiri dan dimiliki klien.

Apakah satu instalasi berarti tidak perlu perawatan lagi?

Tetap perlu. Saya masih harus mengurus server, pembaruan, backup, dan keputusan akses. Hasil yang saya cari adalah berkurangnya pengulangan saat menangani banyak proyek klien. Workspace memungkinkan saya mengelola satu instalasi sambil mempertahankan skema dan izin yang terpisah untuk setiap proyek.