Deploy Banyak Proyek di Satu VPS: Struktur Nginx yang Saya Pakai

Saya punya beberapa side project yang jalan bareng di satu VPS yang sama — situs personal ini, beberapa aplikasi client kecil yang saya host sendiri buat mereka, sama beberapa domain kecil buat eksperimen. Total ada sekitar tujuh-delapan domain aktif di satu server $6/bulan yang sama. Daripada sewa server terpisah per proyek — mahal banget kalau dikaliin segitu banyak, dan boros buat proyek yang trafficnya kecil — saya pakai satu VPS dengan Nginx sebagai reverse proxy dan static file server buat semuanya.

Struktur yang saya pakai cukup standar, tapi saya jadi lebih disiplin soal ini setelah sekali kena masalah yang nyaris bikin dua proyek client down bareng-bareng gara-gara satu kesalahan config.

Satu file config per domain

Tiap proyek punya file config sendiri di /etc/nginx/sites-available/, di-symlink ke sites-enabled/ kalau lagi aktif. Ini bikin gampang enable atau disable satu proyek tanpa ganggu yang lain — tinggal hapus symlink-nya, nginx -t buat test, reload. Awal-awal saya sempet nulis semua domain dalam satu file config besar biar “gampang diliat sekaligus,” dan itu ternyata ide buruk: sekali saya typo di server block satu domain, nginx -t gagal buat keseluruhan file, yang artinya semua domain lain ikut nggak bisa reload sampai typo-nya saya benerin. Setelah kejadian itu saya pisah semuanya per file.

Static site vs proxy, dibedain jelas

Proyek static (kayak situs ini) langsung root ke direktori file hasil build. Proyek yang butuh backend (misalnya app client dengan API Node atau Spring Boot) pakai proxy_pass ke port lokal tempat aplikasinya jalan. Saya jaga penomoran port-nya di catatan terpisah biar nggak ada dua aplikasi yang somehow rebutan port yang sama pas saya nambah proyek baru — pernah kejadian sekali, dan debug-nya lumayan makan waktu sebelum saya sadar itu cuma port conflict biasa.

SSL per domain, dikelola Certbot

Tiap domain punya sertifikat sendiri, auto-renew lewat Certbot lewat cron job. Saya sengaja nggak pakai satu wildcard cert buat semua domain — kedengerannya lebih simpel, tapi kalau wildcard-nya kadaluarsa atau ada masalah verifikasi, semua domain ikut kena bareng-bareng. Certbot per domain artinya kalau satu domain gagal renew (biasanya karena DNS-nya lagi ada masalah di sisi klien), cuma domain itu yang kena, bukan semuanya.

Isolasi resource kalau perlu

Buat aplikasi yang lebih berat — biasanya yang ada background job atau proses yang gampang makan memory — saya jalanin di Docker container terpisah, Nginx tetap jadi entry point tunggal yang proxy ke port container masing-masing. Ini bikin satu aplikasi yang tiba-tiba leak memory nggak langsung nyeret proses aplikasi lain yang jalan native di host yang sama.

Manfaat terbesarnya emang efisiensi biaya — satu VPS $6/bulan bisa nampung tujuh-delapan proyek kecil-menengah dengan nyaman. Tapi manfaat yang saya nggak sadar dari awal itu isolasi konfigurasinya: kalau salah satu proyek butuh maintenance atau lagi ada masalah, yang lain nggak ikut kena dampak — asal, seperti yang saya pelajari dari kejadian config gede itu, semuanya emang dipisah dengan bener dari awal.