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...

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 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 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...

Kenapa Vaultwarden, Bukan Sekadar File Catatan Menyimpan password di catatan HP atau spreadsheet adalah cara tercepat kehilangan akun. Sekali HP hilang atau file bocor, semua akun ikut terancam. Password manager menyelesaikan ini dengan satu master password yang mengunci brankas terenkripsi. Bitwarden resmi memang bisa di-self-host, tapi kebutuhan sumber dayanya besar untuk VPS kecil. Vaultwarden adalah implementasi ulang server Bitwarden yang kompatibel dengan aplikasi dan ekstensi Bitwarden resmi, tapi cukup berjalan dengan RAM ratusan MB. Praktisnya: Anda tetap memakai aplikasi Bitwarden di HP dan browser, hanya saja servernya milik Anda sendiri. Satu hal yang wajib dipahami sejak awal: Vaultwarden menyimpan brankas terenkripsi, tapi keamanan tetap bergantung pada Anda. Master password yang lemah atau hilang berarti brankas tidak bisa dibuka siapa pun, termasuk Anda. Tidak ada tombol "lupa password" di server sendiri. Persiapan Yang dibutuhkan: VPS Ubuntu 24.04 denga...