Kenapa VPS baru tidak boleh langsung dipakai VPS yang baru aktif biasanya datang dengan login root dan password. Kombinasi ini adalah target paling empuk di internet: bot pemindai port 22 bekerja 24 jam mencoba ribuan password umum. Anda mungkin tidak sadar server Anda sedang dicoba ditembus terus-menerus, karena percobaan itu tidak pernah berhenti. Hardening di sini bukan soal paranoia. Ini empat langkah dasar yang sekali jalan, berlaku seterusnya: ganti root dengan user biasa, matikan login password, tutup port yang tidak perlu, dan blokir otomatis IP yang nekat menebak-nebak. Total waktu yang dibutuhkan sekitar 15 menit. Satu aturan emas sebelum mulai: jangan tutup sesi SSH yang sedang aktif sampai Anda berhasil login lewat cara baru di terminal kedua. Kalau ada yang salah ketik, sesi lama itu jalan keluar Anda. Langkah 0: Perbarui sistem Login pertama sebagai root, lalu perbarui daftar paket dan paket yang terpasang: apt update && apt upgrade -y Perintah ini memasti...

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

Server yang sehat jarang berteriak. Ia berbisik lewat log. Masalahnya, bisikan itu tersebar di banyak tempat: log systemd, log Nginx, log aplikasi, dan log sistem. Kalau Anda tidak tahu ke mana harus melihat pertama kali, troubleshooting berubah jadi menebak-nebak. Artikel ini merangkum alur yang saya pakai setiap kali ada server bermasalah: cek log yang relevan, persempit waktunya, temukan baris error yang benar, lalu rapikan log supaya disk tidak penuh diam-diam. 1. journalctl: satu pintu untuk semua log systemd Di Ubuntu 24.04, hampir semua layanan yang dijalankan systemd mencatat ke journal. Artinya satu perintah, journalctl , bisa menjawab sebagian besar pertanyaan "kenapa layanan ini mati?" Melihat log satu layanan # 100 baris terakhir dari layanan nginx sudo journalctl -u nginx -n 100 # Mengikuti log secara live, seperti tail -f sudo journalctl -u nginx -f Flag -u memilih unit. Ganti nginx dengan nama layanan apa pun: ssh , docker , cron , atau nama service apl...

Masalah yang Sering Tidak Disadari dari Cron Hampir semua tutorial VPS menyuruh Anda menulis jadwal di crontab -e . Itu tidak salah, tapi cron punya tiga kelemahan yang baru terasa saat ada masalah: Tidak ada log bawaan. Kalau job gagal, cron tidak memberi tahu Anda kecuali Anda mengarahkan outputnya sendiri atau mengandalkan email lokal yang sering tidak terkonfigurasi. Tidak ada retry. Kalau server mati tepat di jam jadwal, job itu lewat begitu saja. Tidak ada yang mengejarnya saat server hidup lagi. Lingkungan minimal. Cron menjalankan job dengan PATH dan variabel lingkungan yang sangat terbatas. Script yang jalan mulus di terminal interaktif bisa gagal di cron karena perintah tidak ditemukan. Contoh crontab yang umum: # Backup database setiap hari jam 02:00 0 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup-db.log 2>&1 Lima kolom di depan adalah menit, jam, tanggal, bulan, dan hari dalam seminggu. Baris di atas berarti: menit ke-0, jam ke-2, setiap tangg...

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