Banyak project sampingan, satu VPS? Hitung ulang biayanya

Pola klasik developer sampingan: satu VPS, lima project. Bot Telegram, API kecil, landing page, cron harian, eksperimen mingguan: semuanya tinggal di satu kotak, dikonfigurasi sekali, “hemat”. Lalu tiga bulan kemudian: satu project makan RAM dan yang lain ikut lambat, update satu library merusak yang lain, dan menambah project keenam terasa berat karena konfigurasinya menumpuk.

Tulisan ini bukan soal VPS jelek. Untuk beban berat dan konstan, VPS tetap menang. Ini soal pola hosting yang lebih pas untuk profil “banyak project kecil”.

Biaya tersembunyi dari “satu kotak untuk semua”

• Isolasi nol. Satu project bocor memori, semua terasa. Satu project diserang, semua yang berbagi kotak ikut berisiko.
• Konfigurasi menumpuk. Nginx, sertifikat, systemd unit, environment variable: tiap project menambah lapisan. Enam bulan kemudian, tidak ada yang ingat kenapa ada baris tertentu di config.
• Deploy jadi ritual. Takut restart karena satu kotak menampung semua, maka perubahan kecil pun menunggu jam sepi.
• Biaya jiwa. Ini yang paling mahal: project sampingan mati bukan karena idenya gagal, tapi karena maintenance kotaknya melelahkan.

Pola worker-per-project

Model serverless membalik strukturnya: setiap project adalah satu unit terisolasi dengan runtime sendiri, URL sendiri, dan kegagalan sendiri. Di CloudAgni, satu worker per project: bot dapat satu worker, API dapat satu, masing-masing bisa di-deploy dan dihapus tanpa menyentuh tetangganya.

Hitungannya: paket Starter Rp 39.000/bulan memuat 20 worker dengan database D1 dan KV masing-masing. Dua puluh project kecil dalam satu paket setara satu VPS menengah, tanpa konfigurasi nginx, tanpa takut restart, tanpa satu project mengganggu yang lain.

Yang berubah dalam kebiasaan

• Eksperimen jadi murah. Ide Jumat malam dideploy malam itu, dihapus Senin kalau gagal, tanpa jejak di kotak produksi.
• Monitoring per project, bukan per kotak. Daripada membaca log campuran, tiap worker punya catatan pemakaian sendiri.
• Skala jadi keputusan per project. Bot yang mulai dipakai ribuan orang naik paket sendiri; yang lain tidak ikut membayarnya.

Batas wajib diakui

Kalau project Anda butuh proses latar yang menempel terus (queue pekerja berat, WebSocket super panjang, cron tiap detik), model eksekusi-per-request bukan tempatnya, dan satu VPS memang lebih masuk akal. Tapi untuk profil mayoritas project sampingan (request masuk, kode jalan, respons keluar), isolasi per worker menyelesaikan masalah yang sebenarnya membuat project sampingan mati: bukan biaya server, tapi lelahnya merawat server.

Mulai kecil: pindahkan satu project paling sepi dulu, rasakan deploy-nya. Cara deploy worker pertama satu sore cukup, dan trial 14 hari tidak menagih apa-apa.