Supabase di Server Sendiri: Beban Operasionalnya

Menjalankan Supabase di server sendiri berarti tim Anda mengurus basis data, autentikasi, penyimpanan berkas, dan layanan pendukungnya. Tentukan siapa yang menguji pencadangan, memasang pembaruan, menangani gangguan, dan menjaga kunci akses. Pilihan ini bisa sesuai untuk kebutuhan kendali atau lokasi data. Bandingkan biaya kerja tim dengan layanan terkelola sebelum memilihnya.

Saya pernah menjalankan Supabase di server sendiri untuk sistem produksi, termasuk membantu tim berpindah ke dan dari pilihan tersebut. Berikut tanggung jawab yang perlu diperhitungkan.

Kapan server sendiri menjawab kebutuhan proyek

Lokasi data: pada satu proyek kesehatan yang saya bangun, data terkait pasien harus tetap berada di fasilitas. Seluruh layanan berjalan pada server di dalam gedung, sehingga layanan terkelola di luar fasilitas tidak memenuhi batas tersebut. Persyaratan lokasi serupa juga perlu diperiksa pada industri teregulasi dan proyek pemerintahan.

Kewajiban memakai infrastruktur sendiri: sebagian klien memang mensyaratkan sistem berjalan di infrastruktur yang mereka kendalikan. Biaya pada skala besar: pada beban berkelanjutan tertentu, biaya VPS yang dikelola sendiri dapat lebih rendah daripada paket terkelola. Tetap masukkan waktu kerja tim ke perbandingan.

Penghematan dua puluh lima dolar sebulan saja belum cukup menjadi alasan. Pada beban kecil, waktu pengoperasian dapat lebih mahal daripada selisih langganan.

Layanan yang harus dioperasikan bersama

Supabase terdiri atas beberapa layanan. Konfigurasi Compose menjalankan Postgres, GoTrue untuk autentikasi, PostgREST untuk API, Realtime, serta Storage API dengan perantara gambar. Ada pula Kong sebagai gerbang akses, Studio, layanan analitik, dan lingkungan eksekusi Edge Functions. Setiap kontainer memiliki konfigurasi, catatan, risiko kegagalan, dan jadwal pembaruan tersendiri.

Menjalankan semua layanan ini menyerupai mengelola rumah beserta pipa, listrik, dan atapnya. Tim mengambil tanggung jawab atas keseluruhan platform, bukan hanya basis datanya.

Pencadangan jadi tugas Anda — dan bucket ikut dihitung

Layanan terkelola menyediakan pencadangan basis data sesuai paketnya, tetapi pencadangan Supabase tidak mencakup objek Storage. Berkas memerlukan rencana perlindungan sendiri pada kedua pilihan pengelolaan server. Di server sendiri, Anda juga mengoperasikan seluruh proses pencadangan; kesalahan yang sering saya temukan adalah cakupannya hanya Postgres.

Wadah objek Storage (bucket) menyimpan berkas di luar basis data. Storage API menyimpan metadata objek di Postgres, tapi menulis berkas sebenarnya ke volume disk atau penyimpanan kompatibel S3. Jika hanya basis data yang dicadangkan, hasil pemulihan dapat berisi catatan objek yang berkasnya sudah hilang. Sertakan volume berkas dan ambil salinannya secara konsisten dengan salinan basis data agar kedua penyimpanan tetap cocok setelah dipulihkan.

Jadwalkan pengujian pemulihan untuk membuktikan salinan dapat digunakan kembali. Praktiknya saya bahas dalam verifikasi pencadangan Postgres, dengan perhatian tambahan karena basis data dan berkas harus dipulihkan secara selaras.

Pembaruan dan pemantauan juga jadi milik Anda

Pada layanan terkelola, penyedia menangani banyak pembaruan platform. Di server sendiri, tim perlu menjaga kompatibilitas versi setiap citra kontainer dan membaca catatan rilisnya. Pembaruan juga butuh jendela pemeliharaan yang harus dijadwalkan, dan rencana pemulihan ke versi sebelumnya untuk saat autentikasi berperilaku beda setelahnya. Kunci setiap versi citra kontainer secara eksplisit — hindari latest di produksi agar versi tidak berubah tanpa peninjauan.

Pemantauan mengikuti logika yang sama. Pertumbuhan disk di basis data dan di volume berkas, kapasitas kelompok koneksi yang habis, kontainer yang mulai ulang, sertifikat yang kedaluwarsa — semuanya perlu masuk sistem pemantauan yang dipasang dan ditinjau tim.

Permukaan keamanan

Susunan layanan Compose menempatkan layanan internal di belakang Kong. Penempatan ini membatasi akses jaringan: hanya gerbang Kong yang semestinya menerima koneksi dari luar. Postgres, GoTrue, PostgREST, dan Storage semestinya tak terjangkau dari luar — porta yang dibuka langsung menambah jalur serangan.

Pada konfigurasi yang memakai rahasia JWT lama, kunci anon dan kunci service-role diturunkan dari rahasia akses tersebut. Kunci anon dapat dipakai aplikasi klien bersama aturan akses data yang tepat. Kunci service-role hanya untuk layanan server tepercaya: kunci ini dapat melewati Row Level Security (RLS), aturan pembatasan akses per baris. Jangan pernah membagikannya ke peramban atau aplikasi pengguna. Latih rotasi sesuai mekanisme kunci penandatanganan dan versi susunan layanan Anda; penggantian rahasia JWT lama memerlukan koordinasi token dan kunci turunannya.

Simpan rahasia akses di pengelola variabel lingkungan, jangan di berkas Compose yang masuk repositori Git. Rahasia akses bawaan di konfigurasi contoh ada untuk diganti sebelum penerapan pertama, bukan setelah insiden pertama.

Kapan layanan terkelola lebih sesuai

Jika belum ada penanggung jawab untuk pengujian pencadangan, pembaruan terjadwal, dan pemantauan harian, pertimbangkan platform terkelola. Saya menyatakannya di penilaian bahkan saat kontrak pengelolaan server sendiri akan membayar lebih besar.

Biaya server sendiri mencakup waktu kerja orang yang mengoperasikannya. Pilihan ini sesuai ketika kebutuhan regulasi, kendali, atau skala membenarkan tanggung jawab tersebut. Kemudahan pemasangan hari pertama belum menggambarkan biaya operasionalnya.

Apa pun pilihannya, yang dibangun di atasnya tidak berubah — aplikasi dan dasbor yang menghubungkan sistem-sistem ini dapat memakai antarmuka yang sama pada kedua pilihan pengelolaan. Bandingkan kebutuhan lokasi data, kendali, dan biaya dengan pekerjaan pencadangan, pembaruan, pemantauan, serta pengamanan kunci akses.