Kenapa Docker Compose, Bukan docker run Panjang Waktu pertama kali saya self-hosting, tiap layanan dijalankan dengan satu perintah docker run yang panjang: port, volume, environment, restart policy, semua dijejalkan dalam satu baris. Begitu server restart atau saya lupa perintahnya, layanan itu hilang dan saya lupa cara mengembalikannya. Docker Compose menyelesaikan masalah itu. Seluruh konfigurasi layanan ditulis di satu file YAML, docker-compose.yml . Mau menyalakan ulang, memindahkan ke server lain, atau menambah layanan baru, semuanya tinggal edit file itu lalu jalankan satu perintah. File ini juga jadi dokumentasi: enam bulan kemudian, Anda masih bisa melihat persis bagaimana layanan itu dulu dipasang. Satu catatan penting: perintah docker-compose (dengan tanda hubung, versi 1) sudah digantikan docker compose (tanpa tanda hubung, versi 2) yang terpasang sebagai plugin resmi Docker. Tutorial lama yang masih memakai docker-compose bisa diikuti, tapi sebaiknya pakai bentuk bar...

Pelajaran yang Saya Dapat dari Cara yang Salah Dulu saya pernah menjalankan satu layanan di VPS pakai Docker Compose. Semua jalan lancar berbulan-bulan, sampai suatu hari saya membersihkan container dengan perintah yang salah. Container terhapus, dan bersama container itu hilang juga database beserta file upload pengguna. Layanan bisa dihidupkan lagi dalam lima menit, tapi datanya tidak kembali. Penyebabnya sederhana: saya tidak pernah memikirkan di mana data itu sebenarnya tinggal. Di Docker, container itu sendiri bersifat sekali pakai. Kalau data hanya hidup di dalam container, data itu akan ikut mati bersama container. Solusinya bernama volume — dan volume pun tetap harus di-backup. Di Mana Sebenarnya Data Container Tinggal? Ada tiga tempat penyimpanan di Docker, dan membedakannya penting: 1. Lapisan container (bukan tempat menyimpan data) Setiap file yang Anda tulis di dalam container tanpa volume tersimpan di lapisan container itu sendiri. Begitu container dihapus ( docker rm...

Kenapa Perlu Reverse Proxy Satu VPS biasanya menampung lebih dari satu layanan: satu aplikasi web di port 3000, satu dashboard di port 8080, satu lagi di port 9000. Kalau setiap layanan diekspos langsung, Anda harus mengingat port, membuka banyak port di firewall, dan tiap layanan harus mengurus HTTPS-nya sendiri. Reverse proxy menyelesaikan ketiganya sekaligus. Nginx duduk di depan sebagai satu-satunya pintu masuk: port 80 dan 443. Berdasarkan nama domain, ia meneruskan permintaan ke layanan yang tepat di belakangnya. Layanan internal tidak perlu diekspos ke internet, dan sertifikat HTTPS cukup diurus di satu tempat. Pola ini yang saya pakai untuk semua layanan di VPS saya. Satu domain per layanan, satu Nginx, nol drama port. Persiapan Asumsinya: VPS Ubuntu 24.04, domain sudah mengarah ke IP VPS (cek dengan dig +short namadomain.com ), dan layanan internal sudah jalan di localhost. Contoh yang dipakai di artikel ini: Aplikasi web di 127.0.0.1:3000 Dashboard monitoring di 127.0.0...

Masalah yang Sama, Dua Pendekatan Berbeda Begitu Anda menjalankan lebih dari satu layanan di satu VPS — misalnya blog, panel monitoring, dan aplikasi kecil — Anda butuh satu pintu depan. Reverse proxy menerima semua request di port 80/443, lalu meneruskannya ke layanan yang tepat berdasarkan domain. Nginx melakukan ini dengan file konfigurasi yang Anda tulis manual. Traefik melakukan ini dengan mengamati Docker secara langsung: begitu container baru jalan, Traefik otomatis membuatkan rutenya. Perbedaan ini kecil di atas kertas, besar dampaknya dalam pemakaian sehari-hari. Nginx: Kendali Penuh, Konfigurasi Manual Nginx sudah puluhan tahun menjadi standar. Ia cepat, stabil, dan dokumentasinya sangat lengkap. Setiap domain Anda daftarkan lewat satu blok server . Contoh: Anda menjalankan aplikasi Node.js di port 3000 dan ingin diakses lewat app.contoh.com dengan HTTPS. Konfigurasinya seperti ini: server { listen 443 ssl; server_name app.contoh.com; ssl_certificate /etc/...

Kenapa Caddy Layak Dicoba Kalau Anda pernah mengonfigurasi Nginx + Certbot, Anda tahu urutannya: tulis blok server, jalankan certbot, jawab pertanyaan, cek cron renewal, lalu berdoa sertifikat tidak kedaluwarsa diam-diam. Semua itu sah dan sudah terbukti, tapi untuk satu-dua layanan di VPS pribadi, rasanya berlebihan. Caddy membalik urutan itu. Anda menulis nama domain, Caddy yang mengurus sisanya: meminta sertifikat dari Let's Encrypt, memasangnya, dan memperbaruinya sendiri sebelum kedaluwarsa. Tidak ada perintah tambahan, tidak ada cron yang perlu dicek. Untuk saya, ini alasan utama Caddy jadi pilihan default saat memasang layanan baru yang sifatnya internal atau proyek kecil. Satu catatan penting di awal: "otomatis" bukan berarti "tanpa syarat". Domain Anda harus sudah mengarah ke IP VPS, dan port 80 serta 443 harus bisa dijangkau dari internet — karena di situlah validasi Let's Encrypt terjadi. Kalau salah satu tertutup, Caddy tidak bisa menerbitkan ...

Masalahnya: layanan jalan, tapi tidak bisa diakses dari luar Skenario yang familiar: Anda menjalankan sesuatu di rumah — dasbor monitoring, Immich, n8n, atau aplikasi kecil di port 3000. Di jaringan lokal semua jalan. Begitu ingin diakses dari luar, temboknya muncul: IP publik dinamis, router di balik CGNAT provider, dan port forwarding yang tidak bisa dibuat karena modem tidak bisa diutak-atik. Jalur klasiknya adalah port forwarding: buka port di router, arahkan ke mesin lokal. Cara ini bekerja, tapi ada harganya. Setiap port yang dibuka adalah permukaan serangan yang terlihat dari internet. Siapa pun bisa memindai IP Anda dan menemukan layanan itu. Belum lagi kalau provider memakai CGNAT — alamat IP yang Anda lihat di router bukan alamat publik yang bisa dijangkau, sehingga port forwarding tidak mungkin dilakukan sama sekali. Cloudflare Tunnel membalik arah koneksinya. Bukan internet yang mengetuk masuk ke jaringan Anda, melainkan mesin Anda yang membuat koneksi keluar (outbound) ...

VPS yang baru dibeli biasanya langsung dipakai deploy aplikasi, lalu dilupakan. Padahal dalam hitungan jam, alamat IP VPS sudah mulai dipindai bot dari seluruh dunia. Mereka tidak menargetkan Anda secara khusus — mereka memindai semua orang, mencari port terbuka, password lemah, dan paket yang belum di-patch. Audit berkala adalah cara termurah untuk menutup celah itu. Anda tidak butuh tool mahal. Tiga pemeriksaan di bawah ini cukup dilakukan sebulan sekali, dan semuanya bisa selesai dalam 15 menit. 1. Periksa port yang terbuka Port yang terbuka adalah pintu masuk. Setiap port yang listen berarti ada layanan yang bisa diajak bicara dari luar. Prinsipnya sederhana: kalau tidak dipakai, tutup. Lihat dulu apa saja yang sedang listen di server Anda: sudo ss -tulpn Outputnya menunjukkan protokol (TCP/UDP), alamat, port, dan proses pemiliknya. Yang perlu diperhatikan: Port yang listen di 0.0.0.0 atau * berarti bisa diakses dari internet. Wajar untuk 80 (HTTP) dan 443 (HTTPS) kalau se...

Kenapa cara ini Backup yang tidak terenkripsi itu titipan data mentah ke pihak ketiga. Kalau akun Google Drive bocor, siapa pun bisa membaca dump database dan file konfigurasi server. Di sisi lain, backup yang tidak pernah diuji restorenya sama saja dengan tidak punya backup — banyak orang baru tahu arsipnya korup pada hari servernya mati. Pola yang saya pakai: rclone mengunggah ke Google Drive lewat remote crypt , jadi file yang sampai di Drive sudah terenkripsi. Penjadwalan memakai systemd timer, bukan cron, karena timer punya log yang bisa dibaca dengan journalctl dan bisa diuji manual tanpa menunggu jadwal. Terakhir, setiap backup diuji restore ke direktori sementara — bukan ke lokasi asli. Yang dibutuhkan VPS Ubuntu 24.04 dengan akses root atau sudo. Akun Google dengan ruang Drive yang cukup. Dua hal yang wajib disimpan di luar server: password enkripsi rclone dan konfigurasi rclone. Kalau server hilang dan dua hal ini ikut hilang, backup terenkripsi tidak bisa dibuka lagi. ...

Kenapa Harus Punya Monitoring Sendiri Server yang down tapi baru ketahuan dari komplain pengguna adalah skenario terburuk. Layanan monitoring berbayar memang ada, tapi paket gratisnya biasanya membatasi jumlah monitor dan interval ceknya longgar. Uptime Kuma menyelesaikan masalah ini: gratis, open source, diinstal di server sendiri, dan interval ceknya bisa diatur sampai 20 detik. Yang saya pakai di sini: satu VPS Ubuntu 24.04 yang sudah terinstal Docker dan Docker Compose. Kalau Docker belum ada, pasang dulu dengan cara standar dari dokumentasi resmi Docker — jangan pakai skrip instalasi acak dari internet tanpa memeriksa isinya. Instalasi: Satu File Compose, Langsung Jalan Buat direktori khusus supaya datanya tidak tercampur dengan layanan lain: mkdir -p ~/uptime-kuma cd ~/uptime-kuma Lalu buat file docker-compose.yml : services: uptime-kuma: image: louislam/uptime-kuma:2 container_name: uptime-kuma volumes: - ./data:/app/data ports: - "127.0...

Kenapa Self-Host, Bukan Pakai Versi Cloud n8n adalah alat otomasi berbasis node: Anda merangkai pemicu (trigger) dan aksi menjadi satu alur kerja visual, tanpa menulis program. Versi cloud-nya praktis, tapi ada tiga alasan saya memilih self-host: Eksekusi tanpa batas buatan. Di server sendiri, jumlah eksekusi workflow hanya dibatasi spesifikasi VPS, bukan kuota paket. Data tidak keluar sembarangan. Credential API dan data yang lewat workflow tersimpan di server sendiri. Biaya datar. Satu VPS kecil sudah cukup untuk puluhan workflow ringan, sementara langganan cloud naik seiring pemakaian. Syaratnya cuma satu: VPS Ubuntu 24.04 dengan Docker terpasang dan RAM minimal 1 GB (2 GB lebih nyaman). Instalasi: Docker Compose, Bukan Install Manual Saya tidak menyarankan instalasi n8n lewat npm di server produksi. Alasannya sederhana: update jadi repot, dependensi bisa bentrok, dan prosesnya tidak terisolasi. Docker Compose menyelesaikan ketiganya: satu file konfigurasi, satu perintah jal...

Kenapa LLM lokal Ada tiga alasan praktis menjalankan LLM di server sendiri. Pertama, privasi: prompt dan dokumen yang Anda tempel tidak dikirim ke penyedia pihak ketiga. Kedua, biaya: tidak ada tagihan per token, yang ada hanya biaya VPS yang memang sudah Anda bayar. Ketiga, kendali: modelnya tetap sama dari hari ke hari, tidak berubah diam-diam karena update penyedia. Komprominya juga harus jujur. Model lokal yang muat di VPS murah tidak sepintar model frontier seperti GPT-5 atau Claude. Untuk tugas seperti merangkum dokumen, menulis draf, menjawab pertanyaan umum, dan membantu coding sederhana, model 7–8 miliar parameter sudah sangat bisa dipakai. Untuk riset mendalam atau penalaran berlapis, model API tetap unggul. Anggap LLM lokal sebagai asisten harian, bukan pengganti segalanya. Syarat server Pilih VPS dengan RAM yang cukup, karena model bahasa berjalan di RAM (atau VRAM kalau ada GPU, tapi sebagian besar VPS murah tidak punya GPU). Patokan kasar untuk model terkuantisasi (fo...

Kenapa Immich, bukan sekadar folder foto Menyimpan foto di folder VPS memang bisa, tapi tidak enak dipakai: tidak ada thumbnail, tidak bisa cari berdasarkan wajah atau lokasi, dan tidak ada aplikasi HP yang sinkron otomatis. Immich menutup semua celah itu. Tampilannya mirip Google Photos: timeline, album, pencarian, pengenalan wajah, peta lokasi, dan aplikasi Android/iOS untuk backup otomatis dari HP. Bedanya, semua berjalan di server Anda sendiri. Tidak ada yang memindai foto untuk iklan, tidak ada batas storage gratis, dan biayanya hanya sewa VPS plus disk yang Anda pakai. Kekurangannya juga perlu disebut di depan: Anda yang jadi adminnya. Kalau server mati atau disk rusak dan tidak ada backup, foto hilang. Jadi artikel ini tidak berhenti di install — backup adalah setengah dari isinya. Yang perlu disiapkan Spesifikasi realistis untuk pemakaian keluarga kecil (1–3 pengguna, puluhan ribu foto): VPS dengan minimal 2 CPU dan 4 GB RAM. Kalau ada video 4K yang perlu di-transcoding, 4...