Satu VPS untuk banyak proyek
Server yang awalnya hanya untuk GarudaSuite saya tata ulang supaya bisa menampung aplikasi lain — tanpa satu proyek pun bisa merusak proyek lain.
Selama beberapa bulan, satu VPS saya hanya punya satu penghuni: GarudaSuite. Tujuh belas aplikasi, satu Postgres, satu Caddy di depan semuanya. Itu bekerja dengan baik sampai saya ingin menaruh hal lain di server yang sama — situs ini, misalnya.
Ternyata ada satu baris di skrip deploy yang membuat itu mustahil:
cp infra/Caddyfile /etc/caddy/Caddyfile
Setiap kali GarudaSuite di-deploy, seluruh konfigurasi web server ditimpa. Kalau saya menambahkan situs lain ke Caddy hari ini, push GarudaSuite berikutnya akan menghapusnya tanpa suara.
Gedung dan penyewa
Cara saya memikirkannya sekarang: VPS adalah gedung, setiap proyek adalah penyewa. Penyewa boleh mengatur ruangannya sendiri, tapi tidak boleh membongkar lobi.
/srv/
├── platform/ ← milik gedung: Caddy induk, backup, daftar port
├── projects/ ← satu folder per proyek
└── backups/
Konfigurasi Caddy induk hanya berisi pengaturan server, lalu import sites/*.caddy. Setiap proyek memasang satu file miliknya sendiri lewat skrip kecil yang memvalidasi seluruh konfigurasi dulu — kalau Caddy menolak, file lama dikembalikan. Salah ketik di satu proyek tidak pernah menjatuhkan proyek lain.
Bonus yang tidak direncanakan
Konfigurasi lama memakai admin off. Akibatnya systemctl reload caddy selalu gagal lalu jatuh ke restart penuh — semua domain putus sesaat di setiap deploy. Itu menjelaskan lonjakan error 522 yang dulu saya catat tapi tidak pernah benar-benar saya pahami. Dengan admin API di loopback, reload sekarang benar-benar reload: PID yang sama, nol koneksi putus.
Yang dulu belum ada sama sekali
Backup. Database, dokumen pengguna, email — semuanya hanya ada di satu disk. Sekarang setiap malam jam 02.30 setiap proyek punya hook backup-nya sendiri, dan hasilnya diperiksa: dump Postgres benar-benar berisi kedua database, checksum cocok. Backup yang belum pernah dibuka isinya hanyalah harapan.
Server yang rapi bukan yang paling sedikit filenya, tapi yang bisa dibangun ulang dari nol tanpa mengingat apa pun.
Untuk itu semua aturan gedung sekarang ada di satu repo, lengkap dengan bootstrap.sh. Pindah server tinggal: clone, jalankan, pulihkan backup.