Enam bulan lalu seorang kawan mengirim tangkapan layar Portainer-nya: empat belas container berjalan, semua hijau. Minggu lalu saya tanya lagi. Tersisa tiga. Bukan karena hard disk rusak, bukan karena listrik mati, bukan karena dia kehabisan uang. Yang mati adalah sesuatu yang tidak pernah muncul di tutorial mana pun: kesediaan untuk terus mengurusnya.
Saya sudah melihat pola ini berulang sejak 2003, waktu mengurus shared hosting dengan 300 akun di satu Pentium III. Dulu penyebabnya keterbatasan teknis. Sekarang penyebabnya justru kebalikannya — terlalu mudah. Satu perintah docker compose up -d, dan dalam sembilan puluh detik Anda punya Nextcloud. Itu masalahnya. Kemudahan instalasi menciptakan ilusi bahwa pekerjaannya selesai.
Puncak kepuasan ada di hari instalasi
Instalasi memberi umpan balik instan. Anda mengetik perintah, layar menampilkan "login berhasil", dan otak melepas dopamin. Ini yang membuat orang memasang layanan kelima belas padahal yang ketujuh belum pernah dipakai sebulan.
Setelah itu datang fase yang tidak memberi imbalan apa pun: menambal CVE, memutar log, memastikan sertifikat tidak kedaluwarsa, memeriksa apakah backup benar-benar bisa direstore. Tidak ada yang memberi tepuk tangan untuk pekerjaan itu. Dan justru di situ semua nilai sebenarnya berada.
Kurva yang saya lihat hampir selalu identik:
- Bulan 1 — euforia. Enam sampai sepuluh layanan terpasang, dashboard rapi, semua orang di grup Telegram dikirimi tautan.
- Bulan 2–3 — eksperimen. Tambah Immich, tambah n8n, tambah satu VPS lagi. Dokumentasi mulai tertinggal.
- Bulan 4 — drift. Anda lupa port mana milik layanan mana. Satu container restart sendiri setiap Selasa dan tidak ada yang tahu kenapa.
- Bulan 5 — insiden pertama. Storage penuh, atau sertifikat mati, atau Nextcloud menolak login setelah update.
- Bulan 6 — konsolidasi paksa. Entah turun ke tiga layanan, atau seluruh server dimatikan dan diganti langganan cloud.
Yang menarik: kegagalan di bulan 5 hampir tidak pernah benar-benar fatal. Satu jam kerja biasanya cukup untuk memperbaikinya. Yang fatal adalah kepercayaan yang hilang — setelah sekali kehilangan data atau sekali panik jam dua pagi, orang berhenti percaya pada sistem yang dia bangun sendiri. Dan sistem yang tidak dipercaya tidak akan dirawat.
Biaya sebenarnya bukan hardware
Perhitungan yang selalu salah adalah menghitung harga mini PC. Angkanya kira-kira begini untuk satu unit 15 watt yang menyala terus:
- Listrik — 15 W × 8.760 jam ≈ 131 kWh per tahun, sekitar Rp 190 ribu dengan tarif rumah tangga. Murah. Ini bukan biaya Anda.
- Storage dan cadangan — disk 4 TB plus disk cadangan eksternal: Rp 2–3 juta sekali beli, lalu penggantian tiap 4–5 tahun.
- Waktu — inilah pos yang sebenarnya. Dua jam per minggu untuk pemeliharaan rutin adalah angka yang sangat optimistis. Setahun: 104 jam.
Kalau waktu Anda dihargai Rp 150 ribu per jam — angka yang wajar untuk orang yang mengurus server sebagai bagian dari pekerjaan — maka biaya pemeliharaan setahun mencapai Rp 15,6 juta. Tiga puluh kali lipat biaya listriknya. Dan itu belum termasuk biaya emosional dari insiden jam dua pagi.
Saya tidak menulis ini untuk menakut-nakuti. Saya menulis ini karena keputusan self-host hampir selalu diambil dengan menghitung kolom pertama dan mengabaikan kolom ketiga. Padahal kolom ketiga yang menentukan apakah proyek ini hidup atau mati.
Tiga anti-pola yang paling mahal
1. Volume Docker tanpa backup yang pernah diuji
Ini kesalahan nomor satu, dan penyebabnya sepele: orang mencadangkan folder yang salah. Data Nextcloud ada di volume bernama, bukan di folder bind-mount yang Anda kira. Perintah docker compose down -v yang dijalankan untuk "membersihkan sisa instalasi lama" akan menghapus volume itu tanpa konfirmasi.
Saya pernah diminta memulihkan instalasi Vaultwarden yang database-nya hilang. Semua password di dalamnya terenkripsi dengan master password pemiliknya — secara desain, tidak ada jalan masuk. Tidak ada vendor, tidak ada support, tidak ada backdoor. Yang bisa diselamatkan hanya akun-akun yang kebetulan masih login di ponsel. Itu pelajaran yang tidak perlu Anda ulangi sendiri.
Aturan yang saya pegang: backup yang belum pernah direstore bukan backup, itu harapan. Uji restore ke mesin lain minimal sekali per kuartal. Kalau prosesnya tidak Anda dokumentasikan, Anda tidak akan bisa melakukannya saat panik. Untuk skrip yang bisa dijalankan otomatis, pola backup restic ke object storage adalah titik awal yang layak.
2. Reverse proxy sebagai titik tunggal kegagalan
Semua layanan lewat satu reverse proxy seperti Nginx Proxy Manager atau Caddy. Terdengar rapi sampai container itu mati — dan tiba-tiba seluruh dashboard, termasuk panel untuk memperbaikinya, ikut tidak bisa diakses. Anda terkunci di luar rumah digital Anda sendiri.
Solusinya bukan menghindari reverse proxy, tapi memastikan ada jalan masuk kedua: akses SSH langsung, Tailscale, atau satu layanan kecil yang sengaja dipasang di port berbeda khusus untuk keperluan darurat. Prinsipnya sama seperti pintu darurat di gedung — tidak dipakai setiap hari, tapi wajib ada.
3. Update otomatis tanpa snapshot
Watchtower terdengar seperti solusi keamanan. Kenyataannya, ia adalah cara tercepat untuk merusak layanan yang punya batasan versi. Nextcloud tidak mengizinkan lompat versi mayor — dari 27 harus ke 28, baru ke 29. Immich, selama masih pra-1.0, beberapa kali mengubah skema database tanpa jalur migrasi mundur.
Yang saya lakukan sekarang: update manual, terjadwal, dan selalu didahului snapshot. Di Proxmox atau ZFS, snapshot butuh tiga detik. Di Docker biasa, setidaknya dump database dulu. Otomatisasi yang tidak punya tombol undo bukan otomatisasi, itu perjudian.
Yang bertahan lima tahun melakukan hal berbeda
Orang-orang yang homelab-nya masih hidup setelah lima tahun bukan yang paling jago teknis. Mereka yang paling disiplin soal batasan.
- Satu layanan, satu alasan tertulis. Setiap container punya alasan di README. Kalau alasannya "karena bisa", layanan itu dihapus. Ini aturan yang paling banyak menyelamatkan waktu.
- Batas jumlah yang keras. Kebanyakan yang bertahan berhenti di lima sampai tujuh layanan. Bukan karena tidak mampu lebih, tapi karena tahu biaya marginalnya naik tajam setelah angka itu.
- Dokumentasi sebagai kode. Semua
docker-compose.ymldi Git, rahasia di.envyang tidak ikut di-commit, satu README per layanan berisi cara restore. Kalau Anda tidak bisa membangun ulang server dari repo itu dalam satu malam, dokumentasinya belum cukup. - Monitoring yang berteriak, bukan yang dipandang. Dashboard yang indah tidak menolong siapa pun jam tiga pagi. Yang menolong adalah notifikasi yang sampai ke ponsel — dan dead man's switch yang berbunyi ketika server berhenti mengirim sinyal sama sekali. Uptime Kuma bagus untuk status, tapi ia tidak akan membangunkan Anda.
- Rencana mati yang jelas. Untuk setiap layanan, ada catatan: kalau ini mati tiga hari, apa yang rusak? Kalau jawabannya "tidak ada", layanan itu kandidat penghapusan pertama.
Uji 72 jam sebelum menambah layanan
Sebelum memasang apa pun yang baru, saya jalankan satu pertanyaan sederhana ke diri sendiri: kalau layanan ini mati selama 72 jam, apa yang benar-benar berhenti?
Untuk Vaultwarden, jawabannya jelas — saya tidak bisa masuk ke akun apa pun. Itu layanan yang layak dirawat dengan serius. Untuk aplikasi pencatat kebiasaan yang saya pasang tahun lalu, jawabannya "tidak ada", dan saya menghapusnya dua hari kemudian. Pertanyaan ini memisahkan infrastruktur dari hobi, dan keduanya boleh ada — asal Anda tahu mana yang mana.
Kerangka keputusan: self-host, SaaS, atau hybrid
Empat pertanyaan yang saya ajukan sebelum memutuskan:
- Apakah data ini tidak bisa saya ciptakan ulang? Kalau ya, self-host dengan cadangan serius — atau jangan sama sekali.
- Apakah saya menikmati mengurusnya? Faktor ini nyata dan sering diabaikan. Orang merawat apa yang mereka sukai; sisanya ditinggalkan.
- Apakah ada SaaS yang sepuluh kali lebih baik dengan biaya di bawah dua jam kerja saya per bulan? Kalau ada, sering kali jawabannya adalah membayar.
- Bisakah orang lain mengambil alih ini dengan bermodal README? Kalau tidak, Anda sedang membangun utang, bukan aset.
Pola hybrid yang paling sehat yang saya lihat: self-host untuk data pribadi yang sensitif dan untuk hal yang memang Anda nikmati, SaaS untuk hal yang tidak boleh gagal dan tidak menarik untuk diurus. Email masuk kategori kedua. Self-host email berarti berurusan dengan reputasi IP, port 25 yang diblokir ISP rumahan, dan SPF/DKIM/DMARC yang salah satu saja keliru membuat surat Anda masuk spam — dan Anda tidak akan pernah tahu sampai ada yang memberi tahu. Itu bukan proyek akhir pekan.
Kesimpulan yang tidak nyaman
Self-hosting bukan tentang kemampuan memasang layanan. Itu bagian yang mudah, dan semakin mudah setiap tahun. Self-hosting adalah tentang memutuskan apa yang layak Anda urus selama lima tahun ke depan — lalu dengan sengaja menolak sisanya.
Kawan saya yang tersisa tiga container itu tidak kalah. Dia hanya berhenti berpura-pura bahwa empat belas layanan yang menyala berarti empat belas layanan yang terpelihara. Tiga yang benar-benar dirawat, dicadangkan, dan dipahami jauh lebih berharga daripada empat belas yang menyala sampai listrik berikutnya padam.
Kalau Anda baru mulai, mulai dari satu. Pilih yang datanya tidak bisa Anda ciptakan ulang. Rawat enam bulan. Baru setelah itu tambah yang kedua.
Baca juga:
- Cara Install Nextcloud dengan Docker Compose (Cloud Pribadi)
- Cara Self-Host Vaultwarden: Password Manager Pribadi
- Cara Memakai Cloudflare Tunnel: Akses Server Tanpa Buka Port
- Cara Backup Otomatis VPS ke Object Storage dengan restic
-Lengkap-Dengan-Gambar.jpg)
Posts
0 comments:
Post a Comment