Caddy: HTTPS Otomatis Tanpa Ribet

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 sertifikat dan akan mencatat error di log. Itu normal, dan solusinya biasanya hanya soal DNS atau firewall.

Instalasi di Ubuntu 24.04

Caddy tersedia di repositori resminya. Jangan instal dari sumber acak; pakai repositori resmi supaya update keamanan ikut mengalir lewat apt biasa.

sudo apt install -y debian-keyring curl apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Setelah instalasi, Caddy langsung berjalan sebagai service systemd dan menyajikan halaman default di port 80. Verifikasi cepat:

systemctl status caddy --no-pager
curl -I http://localhost

Kalau statusnya active (running), instalasi beres. Buka juga port yang dibutuhkan di firewall, misalnya dengan UFW:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Caddyfile: Seluruh Konfigurasi Anda

Konfigurasi Caddy tinggal di satu file: /etc/caddy/Caddyfile. Formatnya jauh lebih ringkas daripada blok server Nginx. Contoh paling dasar — melayani file statis dari sebuah folder:

example.com {
    root * /var/www/html
    file_server
}

Ganti example.com dengan domain Anda, simpan, lalu muat ulang:

sudo systemctl reload caddy

Selesai. Akses https://example.com dan sertifikat sudah aktif. Tidak ada langkah certbot sama sekali.

Reverse Proxy: Kasus yang Paling Sering Dipakai

Dalam praktik self-hosting, yang lebih sering dibutuhkan adalah reverse proxy: aplikasi jalan di port lokal (misalnya 3000), Caddy yang meneruskannya ke domain dengan HTTPS. Konfigurasinya satu baris:

app.example.com {
    reverse_proxy localhost:3000
}

Caddy akan:

Menerima koneksi HTTPS di 443 dengan sertifikat Let's Encrypt yang ia urus sendiri.
Meneruskan request ke aplikasi di localhost:3000 lewat HTTP lokal.
Mengatur header X-Forwarded-For dan X-Forwarded-Proto secara otomatis, jadi aplikasi tahu alamat asli pengunjung.

Untuk beberapa layanan sekaligus, tinggal tambah blok baru di file yang sama:

app.example.com {
    reverse_proxy localhost:3000
}

files.example.com {
    reverse_proxy localhost:8080
}

git.example.com {
    reverse_proxy localhost:3001
}

Satu systemctl reload caddy menerapkan semuanya. Bandingkan dengan Nginx: tiap layanan biasanya berarti satu file konfigurasi, plus satu perintah certbot yang daftar -d-nya harus dijaga tetap sinkron.

Header dan Keamanan Dasar

Caddy juga memudahkan pengamanan dasar. Misalnya, memaksa header keamanan umum tanpa menulis banyak baris:

app.example.com {
    reverse_proxy localhost:3000
    header {
        Strict-Transport-Security "max-age=31536000;"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
    }
}

HSTS di atas memberi tahu browser agar selalu memakai HTTPS ke domain itu selama setahun. Aktifkan ini setelah Anda yakin HTTPS sudah stabil — karena setelah aktif, browser akan menolak versi HTTP polos domain tersebut.

Melihat Log Saat Ada Masalah

Kalau domain tidak bisa diakses atau sertifikat gagal terbit, jangan menebak-nebak. Caddy menulis log ke journal systemd:

sudo journalctl -u caddy --since "30 minutes ago" --no-pager

Pesan error yang paling sering muncul adalah soal DNS atau konektivitas: domain belum mengarah ke VPS, atau port 80 tertutup firewall sehingga validasi gagal. Perbaiki penyebabnya, reload, dan Caddy akan mencoba lagi secara otomatis — tidak perlu memicu penerbitan manual.

Untuk log akses per situs, tambahkan direktif log di blok yang bersangkutan:

app.example.com {
    reverse_proxy localhost:3000
    log {
        output file /var/log/caddy/app-access.log
    }
}

Caddy vs Nginx, Singkat Saja

Ini bukan soal mana yang "lebih baik" secara absolut — keduanya alat matang yang dipakai produksi di banyak tempat. Perbedaannya ada di beban kerja:

Aspek	Caddy	Nginx + Certbot
HTTPS	Otomatis, bawaan	Perlu certbot + renewal
Konfigurasi proxy	1–3 baris per situs	Satu blok server per situs
Performa mentah	Sangat baik	Sangat baik, sedikit lebih hemat memori
Ekosistem & modul	Cukup, berkembang	Sangat luas, dokumentasi melimpah
Kasus rumit (rate limit kompleks, caching lanjutan)	Bisa, tapi lebih terbatas	Lebih fleksibel

Aturan praktis saya: kalau kebutuhannya adalah reverse proxy untuk layanan self-hosting dengan HTTPS yang benar tanpa perawatan, pilih Caddy. Kalau Anda mengelola puluhan situs dengan aturan routing dan caching yang rumit, atau tim Anda sudah standar di Nginx, tetaplah di Nginx — tidak ada alasan memindah sesuatu yang sudah berjalan baik.

Kapan Jangan Pakai HTTPS Otomatis

Ada dua situasi di mana mode otomatis Caddy perlu diubah. Pertama, domain hanya bisa diakses dari jaringan internal (misalnya layanan di balik VPN): validasi Let's Encrypt tidak akan bisa mencapai server Anda. Solusinya adalah mode DNS challenge, yang membutuhkan API dari penyedia DNS Anda — ini mungkin untuk dibahas di artikel terpisah.

Kedua, Anda memakai sertifikat dari penyedia lain atau sertifikat internal perusahaan. Caddy tetap bisa memakai sertifikat tersebut dengan direktif tls yang menunjuk ke file sertifikat dan kunci Anda, menggantikan mode otomatis. Intinya: otomatis adalah default yang nyaman, bukan satu-satunya cara.

Checklist Penutup

Domain sudah mengarah ke IP VPS (cek dengan dig +short domain-anda).
Port 80 dan 443 terbuka di firewall.
Caddy terinstal dari repositori resmi dan service-nya aktif.
Blok domain di /etc/caddy/Caddyfile sudah benar, lalu systemctl reload caddy.
https://domain-anda bisa dibuka dan sertifikatnya valid.
Log dicek sekali dengan journalctl -u caddy untuk memastikan tidak ada error tersembunyi.

Setelah checklist ini hijau, Anda tidak perlu lagi memikirkan sertifikat: Caddy akan memperbaruinya sendiri jauh sebelum masa berlakunya habis. Itulah seluruh janji Caddy — HTTPS yang benar, tanpa ribet, dan waktu Anda kembali untuk mengurus aplikasinya sendiri.

Cari Blog Ini