Kenapa Saya Terus Mindahin Stack ke Self-Hosting

Situs ini aja udah saya jalanin di VPS biasa pakai Nginx, bukan platform otomatis, jadi jelas saya nggak alergi ngurus infrastruktur sendiri. Tapi tahun ini saya sadar diam-diam udah mindahin beberapa hal lain dari SaaS ke VPS yang sama juga — analytics, uptime monitoring, backend form, satu step image processing — tanpa pernah beneran mutusin “saya bakal self-host lebih banyak sekarang” sebagai satu keputusan sadar. Pas saya nengok balik kenapa masing-masingnya kejadian, biaya ternyata alasan paling kecil, bukan yang paling besar.

Analytics yang pertama pindah, dan privasi yang jadi pemicu sebenarnya. Saya pakai SaaS analytics pihak ketiga yang sebenarnya oke, murah malah, tapi setiap page load berarti ada request keluar ke server orang lain bawa data visitor yang sebenarnya nggak perlu-perlu amat saya kasih ke mereka. Saya ngerjain app privacy-first di sela-sela proyek lain, dan lama-lama kerasa nggak konsisten — peduli banget soal data user di satu proyek tapi cuek-cuek aja di proyek sendiri. Saya pindah ke tool analytics self-hosted yang cookieless, di VPS yang sama. Bukan downgrade — saya tetep dapet angka yang saya perluin (page view, referrer, geografi kasar) tanpa cookie banner, dan datanya nggak pernah keluar dari infrastruktur yang saya kontrol sendiri. Penghematan biayanya beneran ada tapi kecil. Motivasi sebenarnya itu saya nggak mau terus bikin pengecualian buat situs saya sendiri.

Uptime monitoring pindah gara-gara satu kegagalan spesifik. Saya pakai SaaS uptime checker free-tier, dan satu minggu dia diem-diem berhenti ngirim alert — nggak ada error, nggak ada notif kalau notifikasinya berhenti, saya cuma kebetulan cek dashboard dan sadar situs saya udah down enam jam tanpa satu ping pun yang kekirim. Itu skenario mimpi buruk buat monitoring tool: bukan karena nggak sempurna, tapi karena gagal diam-diam persis pas kamu butuh dia. Saya pindah ke checker self-hosted kecil yang ping situs-situs saya dan email langsung ke saya, nggak ada pihak ketiga di tengah yang bisa diam-diam ngedown-grade layanan. Kurang polished — nggak ada status page yang fancy, nggak ada grafik historical uptime — tapi saya lebih percaya failure mode-nya, karena kalau dia rusak, dia rusaknya keras di infrastruktur yang emang udah saya pantau.

Pindahnya form backend soal nggak mau tergantung sama roadmap perusahaan orang. Saya pakai layanan hosted form-to-email buat beberapa contact form di proyek yang beda-beda. Jalan lancar sampai perusahaannya push perubahan pricing tier yang mindahin fitur yang saya andelin ke paket berbayar yang lebih mahal, dengan pemberitahuan sekitar dua minggu. Nggak ada yang rusak, saya cuma harus buru-buru nyesuaiin sebelum deadline. Kecil sih kalau dilihat sendiri, tapi itu bikin saya sadar berapa banyak infrastruktur “simpel” saya sebenarnya rantai perusahaan eksternal yang masing-masing bisa sendiri-sendiri mutusin ngubah terms ke saya dengan pemberitahuan singkat. Form handler itu paling kira-kira empat puluh baris kode dengan mail library di belakangnya. Jalanin sendiri berarti satu-satunya roadmap yang saya gantungin cuma roadmap saya sendiri.

Image processing pindah lebih karena latency, jujur, dibanding prinsip. Saya pakai layanan SaaS image resizing/optimization di pipeline salah satu proyek klien, dan itu nambahin round-trip yang beneran kerasa di tiap upload — oke-oke aja buat pemakaian sesekali, tapi ganggu buat workflow yang proses gambar terus-menerus. Jalanin processing yang sama pakai library langsung di VPS motong round-trip itu sepenuhnya. Ini yang paling deket ke keputusan performa murni dibanding filosofis, tapi tetep ngikutin pola yang sama: task yang cukup simpel buat saya jalanin sendiri malah lewat network hop ke pihak ketiga tanpa alasan lain selain karena dulu emang gampang di-setup kayak gitu.

Yang nggak saya lakuin: nganggep self-hosting jawaban universal. Saya masih pakai banyak SaaS — email, registrasi domain, provider VPS-nya sendiri secara teknis juga infrastruktur orang lain, jelas. Pola-nya bukan “hindarin semua pihak ketiga,” tapi nyadarin dependency mana yang beneran krusial buat hal yang saya pedulikan (privasi, reliability, nggak tergantung belas kasihan halaman pricing orang) versus mana yang cuma default nyaman yang nggak pernah dipikirin ulang. Keempat perpindahan di atas semuanya mulai dari gangguan yang spesifik dan konkret — bukan ideologi umum bahwa self-hosting itu lebih baik secara moral. Saya nggak mikir gitu, otomatis. Tool SaaS yang dijalanin orang yang beneran spesialis di satu hal itu sering lebih reliable dibanding versi buatan saya sendiri, dan saya bakal bohong kalau bilang uptime checker saya lebih bagus uptime-nya dibanding perusahaan monitoring khusus.

Biaya maintenance-nya beneran ada dan saya nggak mau ngecilin itu. Tiap perpindahan ini berarti sekarang saya yang jadi orang yang patch server, pantau disk usage, dan kena “page” (dari monitoring saya sendiri, malah) pas ada yang rusak jam 2 pagi, bukan tim on-call perusahaan SaaS yang ngurus itu diam-diam di belakang layar. Itu tradeoff beneran, bukan menang gratisan. Yang bikin ini worth it khusus buat saya itu karena keempat layanan ini nggak cukup kompleks buat jadi beban operasional beneran begitu udah di-setup — mereka proses kecil, membosankan, single-purpose yang jalan di sebelah static site yang emang udah ada di situ. Kalau saya self-host sesuatu yang beneran kompleks, app berbasis database dengan requirement uptime beneran buat orang lain, saya bakal mikirinnya sama sekali beda. Hitung-hitungannya cuma jalan karena hal-hal yang saya pindahin cukup simpel sampai “saya jalanin sendiri” nggak makan waktu saya jauh lebih banyak dari “saya konfigurasi dashboard punya orang lain” yang udah ada sebelumnya.

Pelajaran sebenarnya, kalau ada: tiap kali sesuatu di list ini ngelanggar janji — alert yang gagal diam-diam, perubahan pricing dengan pemberitahuan singkat, hit latency yang nggak perlu — itu momen yang pantas buat nanya “bisa nggak sih saya jalanin ini sendiri.” Bukan sebelumnya, cuma karena preferensi murni, dan bukan sebagai kebijakan blanket. Cuma pas satu dependency beneran nunjukin failure mode-nya, itu biasanya waktu terbaik buat mutusin apa kamu masih oke gantungin diri ke situ ke depannya.