Caddy vs Nginx untuk HTTPS Otomatis: Kapan Masing-Masing Menang

Setiap VPS yang saya siapkan akhirnya sampai pada pertanyaan yang sama: siapa yang menangani terminasi TLS? Hampir sepanjang karier saya jawaban refleksnya adalah Nginx, dengan certbot ditempel untuk Let's Encrypt. Lalu saya mulai memakai Caddy di side project dan tool internal, dan kesimpulan jujurnya: tidak ada yang menang secara universal. Keduanya menang di situasi berbeda, dan tahu Anda sedang berada di situasi yang mana akan menyelamatkan Anda dari mengasuh renewal berbasis cron atau berkelahi dengan bahasa config asing jam 2 pagi.

Versi singkatnya: Caddy membuat HTTPS jadi non-event — sertifikat diterbitkan, diperpanjang, dan di-failover otomatis begitu Anda mendeklarasikan hostname. Nginx tetap pilihan lebih baik saat Anda butuh ekosistemnya yang sangat besar, knob tuning yang teruji, atau Anda sudah menjalankan fleet yang terstandardisasi dengannya lewat Ansible. Di bawah ini perbandingan detail yang saya harap saya punya sebelum memigrasikan server pertama saya.

Bagaimana Caddy Membuat HTTPS Jadi Otomatis

Caddy melayani semua situs lewat HTTPS secara default sejak 2015. Anda menulis Caddyfile yang mendeklarasikan hostname, dan deklarasi itu sendirilah pemicunya: Caddy mengambil sertifikat dari provider ACME, me-redirect HTTP ke HTTPS, dan menjaga semuanya tetap diperpanjang tanpa satu baris ekstra pun. Ini benar-benar seluruh config untuk dua aplikasi yang di-proxy:

# Caddyfile — this is the entire HTTPS configuration
app.example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:4000
}

Yang Anda dapatkan secara implisit dari file itu adalah bagian yang paling mengesankan bagi saya:

• Penerbitan dan perpanjangan dikelola di dalam proses server itu sendiri. Tidak ada timer eksternal, tidak ada cron job, tidak ada binary kedua yang bisa diam-diam rusak sementara proxy-nya tetap jalan.
• Failover issuer yang sepenuhnya redundan: kalau Let's Encrypt down atau me-rate-limit Anda, Caddy otomatis mencoba ZeroSSL sebelum backoff. Dengan certbot, outage CA di jendela renewal Anda adalah masalah yang harus Anda sadari sendiri.
• Hostname lokal dan internal seperti localhost mendapat sertifikat self-signed dari CA bawaan Caddy, jadi lingkungan dev Anda juga berbicara HTTPS, dengan sintaks config yang sama.

Workflow Nginx + Certbot, Dikerjakan dengan Benar

Nginx tidak melakukan ACME sendiri; pasangan standarnya adalah certbot, di-install via snap sesuai instruksi terkini dari EFF. Setup-nya singkat tapi ia adalah komponen bergerak terpisah dengan siklus hidupnya sendiri:

# Nginx + certbot: install once, then per domain
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx -d app.example.com

# verify the renewal timer actually works
sudo certbot renew --dry-run
systemctl list-timers | grep certbot

Certbot memasang systemd timer (atau cron job) yang memperpanjang sertifikat sebelum kedaluwarsa dan me-reload Nginx. Ini bekerja baik — saya menjalankannya bertahun-tahun di VPS klien — tapi perhatikan kata kerjanya: memasang, memperpanjang, me-reload. Tiga hal yang hidup di luar web server Anda dan bisa gagal secara independen. Pemeriksaan dry-run di atas tempatnya di playbook provisioning Anda, bukan di ingatan Anda.

Adu Langsung: Perbedaan yang Penting di Production

Benchmark kebanyakan mengukur skenario yang tidak akan pernah Anda temui di VPS 2 vCPU. Dimensi-dimensi inilah yang benar-benar menentukan keputusan saya:

Kapan Saya Memilih Caddy

• VPS kecil yang menampung beberapa aplikasi di belakang reverse proxy, di mana Caddyfile dua baris menggantikan lima puluh baris server block Nginx plus state certbot.
• Tool internal dan environment staging, di mana sertifikat CA lokal otomatis berarti HTTPS di mana-mana tanpa ritual mkcert.
• Proyek yang nantinya dirawat orang yang kurang berorientasi infrastruktur. Menyerahkan Caddyfile ke developer junior jauh lebih ramah daripada menyerahkan nginx.conf plus timer renewal yang harus dijaga tetap hidup.
• Apa pun dengan banyak subdomain berumur pendek, karena penerbitan sertifikat on-demand menangani host yang belum Anda ketahui saat deploy.

Kapan Nginx Tetap Menang

• Fleet yang sudah ada. Semua ingress Docker Swarm production saya dan role Ansible di sekitarnya mengasumsikan Nginx; biaya migrasi melebihi kenyamanan Caddy di sana.
• Workload traffic tinggi di mana Anda ingin kontrol eksplisit atas ssl_session_cache, perilaku keepalive, worker process, dan ukuran buffer yang dijabarkan presisi oleh dokumentasi Nginx.
• Setup yang butuh module atau pola spesifik dengan banyak preseden: scripting njs, rate limiting kompleks, mirroring traffic, atau semantik caching persis yang diandalkan aplikasi Anda yang tanpa CDN.
• Tim yang sudah fasih Nginx. Bahasa config yang bisa dibaca semua orang mengalahkan bahasa config lebih bagus yang hanya dibaca satu orang.

Migrasi Satu Server dari Nginx ke Caddy: Urutan yang Aman

Kalau Anda ingin mencoba Caddy di box yang sedang live tanpa membakar jembatan, ini urutan yang saya pakai:

1. Tulis padanan Caddyfile dari server block Anda dan jalankan Caddy di port alternatif (8080/8443) berdampingan dengan Nginx untuk memvalidasi routing dan header.
2. Turunkan TTL DNS Anda, lalu hentikan Nginx dan jalankan Caddy di 80/443 saat jendela sepi. Penerbitan pertama hanya hitungan detik per domain.
3. Pantau log Caddy untuk aktivitas ACME dan akses setiap vhost. Biarkan sertifikat lama dan nginx.conf tetap utuh di disk sebagai jalur rollback.
4. Setelah satu minggu bersih, hapus certbot, timer-nya, dan paket Nginx — timer renewal sisa yang menunjuk ke webroot mati senang sekali memenuhi log dengan noise.

Intinya

HTTPS otomatis bukan lagi pembeda yang harus Anda bayar dengan kompleksitas. Caddy menjadikannya default, dan untuk workload VPS kecil-menengah yang sebagian besar dari kita jalankan, default itu bernilai uang operasional nyata: lebih sedikit komponen bergerak, lebih sedikit insiden expiry, lebih sedikit playbook.

Tapi keputusan infrastruktur menyangkut fleet dan tim, bukan server tunggal. Nginx dengan timer certbot yang terverifikasi dengan benar tetap stack yang sepenuhnya modern, dan jadi pilihan tepat saat kedalaman ekosistem, kontrol tuning, atau otomasi yang sudah ada memberatkan timbangan. Pilih per situasi — dan apa pun pilihan Anda, taruh expiry sertifikat di dashboard yang benar-benar Anda lihat.