Self-Hosting Supabase di Production: Apa yang Sebenarnya Anda Tanggung

Self-Hosting Supabase di Production: Apa yang Sebenarnya Anda Tanggung

Self-hosting Supabase kelihatannya satu perintah: clone repository, jalankan docker compose up, buka Studio. Itu hari pertama, dan hari pertama memang semudah itu. Keputusan yang sebenarnya diambil soal hari kedua ratus — siapa yang sadar backup gagal, siapa yang merencanakan upgrade versi, siapa yang merotasi secret.

Saya pernah menjalankan Supabase self-hosted di production dan memigrasikan tim masuk maupun keluar darinya. Ini buku kas jujurnya.

Alasan sah untuk self-host

Alasan sahnya nyata. Data locality: di satu deployment kesehatan yang saya bangun, data yang bersinggungan dengan pasien tidak boleh keluar dari fasilitas, titik. Stack-nya jalan di server di dalam gedung, dan tidak ada layanan managed yang bisa memenuhi batasan itu. Industri teregulasi dan proyek pemerintahan di Indonesia makin sering menaikkan tembok yang sama tiap tahun.

Mandat on-prem: sebagian klien memang mensyaratkan sistem berjalan di infrastruktur yang mereka kendalikan. Biaya pada skala besar: melewati beban berkelanjutan tertentu, VPS yang dikelola sendiri jelas lebih murah daripada tier managed.

Ada juga alasan yang tidak sah: menghemat dua puluh lima dolar sebulan. Kalau motivasinya cuma tagihan kelas hobi, waktu ops-nya akan lebih mahal daripada langganannya.

Isi stack-nya yang sebenarnya

"Supabase" bukan satu service. Compose file self-hosted menghidupkan Postgres, GoTrue untuk auth, PostgREST untuk API instan, server Realtime, Storage API dengan image proxy, Kong sebagai gateway, Studio, service analytics, dan runtime edge functions. Belasan container, masing-masing dengan konfigurasi, log, mode kegagalan, dan ritme rilisnya sendiri.

Bayangkan self-host seperti membangun rumah sendiri lengkap dengan pipa, listrik, dan atap sendiri, bukan sekadar sewa apartemen yang tinggal huni. Ini bukan sekadar mengadopsi database. Ini mengadopsi service sebanyak satu tim platform — minus tim platformnya.

Backup jadi tugas Anda — dan bucket ikut dihitung

Platform managed mem-backup semuanya tanpa terasa. Self-hosted, backup jadi tanggung jawab sendiri, dan kesalahan yang paling sering saya temukan: scope-nya cuma Postgres.

Storage bucket tidak hidup di database. Storage API menyimpan metadata objek di Postgres, tapi menulis file sebenarnya ke volume disk atau penyimpanan kompatibel S3. Backup database saja, dan hasil restore akan bangun dengan semua bucket utuh — sebagai baris-baris yang menunjuk ke file yang sudah tidak ada. Volume file wajib masuk scope backup, dan harus ditangkap konsisten dengan dump database-nya, atau metadata dan file hasil restore saling melenceng.

Dan backup yang belum pernah di-restore cuma rumor. Latihan restore terjadwal tidak bisa ditawar — praktiknya saya tulis di verifikasi backup Postgres, dan di sini berlaku dua kali lipat karena ada dua penyimpanan yang harus bangun serempak.

Upgrade dan monitoring juga jadi milik Anda

Di platform managed, upgrade terjadi begitu saja. Self-hosted, upgrade adalah proyek: belasan image yang versinya harus tetap saling kompatibel, release notes yang harus dibaca. Upgrade juga butuh jendela maintenance yang harus dijadwalkan, dan rencana rollback untuk saat auth berperilaku beda setelahnya. Pin setiap versi image secara eksplisit — latest di production adalah resep upgrade kejutan jam 3 pagi.

Monitoring mengikuti logika yang sama. Pertumbuhan disk di database dan di volume file, saturasi connection pool, container yang restart, sertifikat yang kedaluwarsa — tidak ada yang mengawasi semua itu. Kecuali pengawasnya memang dipasang sendiri.

Permukaan keamanan

Stack compose ini adalah kumpulan service internal di belakang Kong, dan topologi itu adalah keputusan keamanan: cuma gateway yang boleh berada di tepi jaringan. Postgres, GoTrue, PostgREST, dan Storage semestinya tak terjangkau dari luar — setiap port yang dibuka melewati gateway adalah attack surface yang direlakan sendiri.

JWT secret adalah akar kepercayaan seluruh stack: anon key dan service-role key yang dibagikan ke client diturunkan darinya, dan siapa pun yang memegang service-role key memegang kendali penuh atas database. Perlakukan rotasi sebagai praktik yang dilatih, bukan keterampilan darurat — merotasi secret membatalkan semua token yang sudah diterbitkan beserta kedua key turunannya, jadi ia harus jadi perubahan terencana dan terkoordinasi.

Simpan secret di environment manager, jangan pernah di compose file yang sampai ke git. Secret default di konfigurasi contoh ada untuk diganti sebelum deploy pertama, bukan setelah insiden pertama.

Kapan managed hosting adalah rekomendasi yang jujur

Kalau tidak ada satu pun orang di tim yang akan memiliki ini — benar-benar memiliki, dengan latihan backup, jendela upgrade, dan monitoring di dashboard yang memang dilihat orang — platform managed adalah jawaban yang benar. Saya menyatakannya di assessment bahkan saat kontrak self-hosting akan membayar lebih besar.

Biaya sebenarnya dari self-hosting adalah waktu orang, bukan server. Ia pilihan tepat saat tembok regulasi atau skala nyata menuntutnya. Ia jadi hobi mahal saat dipilih cuma karena hari pertamanya semudah satu perintah.

Apa pun pilihannya, yang dibangun di atasnya tidak berubah — aplikasi dan dashboard yang menghubungkan sistem-sistem ini tidak tahu dan tidak peduli lokasi stack-nya berjalan. Pilih dengan buku kas terbuka: locality, kendali, dan biaya di satu sisi; backup, upgrade, monitoring, dan disiplin secret di sisi lain. Kedua sisinya nyata.