Caddy vs Nginx #

Caddy dan Nginx adalah dua web server modern yang paling sering dibandingkan. Keduanya capable, keduanya bisa menangani traffic production yang signifikan, dan keduanya memiliki komunitas yang aktif. Namun filosofi desain mereka sangat berbeda, dan perbedaan ini membuat masing-masing jauh lebih baik untuk konteks tertentu.

Artikel ini tidak akan menyimpulkan “mana yang lebih baik” — karena jawabannya selalu “tergantung”. Yang bisa kita lakukan adalah memahami perbedaan konkret mereka, melihat kode side-by-side untuk use case yang sama, dan memberikan framework berpikir yang bisa kamu gunakan untuk memutuskan sendiri berdasarkan konteksmu.

Perbedaan Filosofi #

Perbedaan paling mendasar antara Caddy dan Nginx bukan pada fitur teknis, melainkan pada filosofi desain:

Nginx didesain untuk performa dan fleksibilitas. Ia dirancang untuk menjadi web server yang sangat cepat dengan kontrol penuh atas setiap aspek perilakunya. HTTPS, header forwarding, redirect — semua harus dikonfigurasi secara eksplisit. Nginx tidak membuat asumsi tentang apa yang kamu inginkan.

Caddy didesain untuk kemudahan operasional dan keamanan sebagai default. Ia membuat asumsi yang reasonable: domain publik harus punya HTTPS, header forwarding yang umum harus diteruskan secara otomatis, redirect HTTP ke HTTPS harus aktif secara default. Caddy membuat keputusan yang baik untuk kamu, tapi kamu bisa override semua keputusan itu.

Ini seperti perbedaan antara framework yang “opinionated” dan yang “unopinionated” di dunia pemrograman.

Perbandingan Fitur #

Perbandingan Konfigurasi Side-by-Side #

Use Case 1: Static File Server dengan HTTPS #

Nginx membutuhkan minimal dua server block dan Certbot setup terpisah:

# HTTP → HTTPS redirect
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_stapling on;
    ssl_stapling_verify on;

    root /var/www/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

Caddy — semua hal di atas dihandle otomatis:

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

Use Case 2: Reverse Proxy ke Backend #

Nginx:

server {
    listen 80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
        proxy_read_timeout 86400;
    }
}

Caddy:

api.example.com {
    reverse_proxy localhost:8080
}

Use Case 3: Multiple Virtual Hosts dengan Load Balancing #

Nginx:

upstream app_servers {
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;
    # ssl config...

    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 443 ssl http2;
    server_name api.example.com;
    # ssl config lagi...

    location / {
        proxy_pass http://localhost:8080;
        # proxy headers lagi...
    }
}

Caddy:

app.example.com {
    reverse_proxy localhost:3001 localhost:3002 localhost:3003
}

api.example.com {
    reverse_proxy localhost:8080
}

Konfigurasi Dinamis — Perbedaan yang Signifikan #

Ini adalah area di mana perbedaannya paling terasa. Bayangkan kamu mengelola platform hosting di mana customer bisa mendaftarkan domain mereka sendiri.

Dengan Nginx, workflow untuk menambah domain baru adalah:

# 1. Generate file konfigurasi baru
cat > /etc/nginx/sites-available/customer-newdomain.com.conf << EOF
server {
    listen 80;
    server_name newdomain.com;
    return 301 https://\$host\$request_uri;
}
server {
    listen 443 ssl;
    server_name newdomain.com;
    # ...
}
EOF

# 2. Enable site
ln -s /etc/nginx/sites-available/customer-newdomain.com.conf \
      /etc/nginx/sites-enabled/

# 3. Jalankan Certbot untuk domain baru
certbot --nginx -d newdomain.com --non-interactive

# 4. Test konfigurasi
nginx -t

# 5. Reload Nginx
nginx -s reload

# Waktu total: 30–60 detik, banyak langkah bisa gagal

Dengan Caddy, satu API call sudah cukup:

# Tambah domain baru via Admin API
curl -X POST "http://localhost:2019/config/apps/http/servers/main/routes/" \
  -H "Content-Type: application/json" \
  -d '{
    "match": [{"host": ["newdomain.com"]}],
    "handle": [{
      "handler": "reverse_proxy",
      "upstreams": [{"dial": "localhost:3000"}]
    }]
  }'

# Caddy otomatis mendapatkan sertifikat untuk newdomain.com
# Waktu total: <1 detik untuk API call
# Sertifikat akan ada dalam beberapa detik berikutnya secara async

Performa: Angka dan Konteks #

Nginx memiliki reputasi yang sangat kuat untuk performa — dan itu bukan mitos. Nginx dioptimalkan selama lebih dari 20 tahun untuk throughput tinggi dan latency rendah.

Caddy, yang ditulis dalam Go dan menggunakan goroutine untuk concurrency, juga performan. Tapi ada beberapa nuansa yang perlu dipahami:

Perbandingan performa (data umum dari berbagai benchmark publik):

Static file serving (10k req/detik, concurrency 100):
  Nginx     ████████████████████  ~100% (baseline)
  Caddy     ████████████████████  ~88–95%
  Selisih   5–12% — hampir tidak terasa di aplikasi nyata

Reverse proxy ke backend (latency dominated):
  Nginx     ████████████████████  ~100%
  Caddy     ████████████████████  ~90–97%
  Selisih   3–10% — biasanya tidak relevan

High concurrency (50k+ concurrent connections):
  Nginx     ████████████████████  Sangat baik
  Caddy     █████████████████░░░  Baik, tapi Nginx lebih efisien
  Goroutine overhead vs event loop Nginx mulai terasa

TLS handshake overhead:
  Keduanya sebanding — TLS overhead lebih dipengaruhi
  oleh implementasi TLS library (OpenSSL vs Go crypto)
  daripada web server itu sendiri

Perbedaan performa 5–15% antara Caddy dan Nginx hampir tidak pernah menjadi bottleneck nyata di aplikasi production. Bottleneck hampir selalu ada di aplikasi backend, query database, atau network latency. Jika kamu sedang memilih web server berdasarkan benchmark sintetis, kamu mungkin mengoptimalkan hal yang salah. Gunakan profiling pada stack lengkap kamu untuk menemukan bottleneck yang sebenarnya.

Ekosistem Plugin: Matang vs Berkembang #

Ini adalah salah satu keunggulan nyata Nginx yang tidak bisa diabaikan.

Ekosistem Nginx — 20+ tahun pengembangan menghasilkan:

• ModSecurity — WAF (Web Application Firewall) yang sangat matang
• ngx_http_lua_module — scripting Lua yang powerful untuk logika kustom
• nginx-rtmp-module — streaming media
• ngx_http_geoip_module — geolocation berdasarkan IP
• openresty — platform Nginx + Lua yang sangat powerful
• Ratusan modul komunitas lainnya

Ekosistem Caddy — lebih muda tapi berkembang pesat:

• caddy-security — OAuth2, OIDC, LDAP
• caddy-ratelimit — rate limiting per-IP atau per-key
• cache-handler — HTTP caching
• caddy-docker-proxy — konfigurasi dari Docker labels
• 20+ DNS provider modules
• Terus bertambah

Untuk sebagian besar use case web server umum, ekosistem Caddy sudah mencukupi. Tapi jika kamu butuh WAF yang matang seperti ModSecurity, atau scripting Lua untuk logika yang sangat kustom, Nginx masih unggul.

Operasional Sehari-hari #

Pengalaman operasional sehari-hari adalah sesuatu yang sering diabaikan dalam perbandingan teknis, tapi ini yang paling sering kamu rasakan.

Nginx — operasional sehari-hari:

# Edit konfigurasi
sudo vim /etc/nginx/sites-available/example.com

# Test konfigurasi
sudo nginx -t

# Reload
sudo nginx -s reload

# Renew sertifikat (via Certbot)
sudo certbot renew --dry-run
sudo certbot renew

# Cek status sertifikat
sudo certbot certificates

# Lihat log
sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Caddy — operasional sehari-hari:

# Edit konfigurasi
sudo vim /etc/caddy/Caddyfile

# Validasi dan reload
caddy validate --config /etc/caddy/Caddyfile && sudo systemctl reload caddy

# Sertifikat — tidak perlu diurus, Caddy mengelola sendiri
# Tidak ada certbot, tidak ada cronjob

# Lihat status sertifikat via API
curl http://localhost:2019/config/apps/tls/ | jq .

# Lihat status upstream
curl http://localhost:2019/reverse_proxy/upstreams/

# Lihat log
sudo journalctl -u caddy -f

Decision Tree #

Gunakan framework berpikir ini untuk memutuskan:

Mulai di sini
    │
    ▼
Apakah kamu membutuhkan konfigurasi domain yang dinamis —
tambah/hapus domain via API tanpa restart atau edit file?
    │
    ├─ Ya → CADDY jelas lebih baik (Admin API)
    │
    └─ Tidak
          │
          ▼
      Apakah tim kamu sudah heavily invested di Nginx
      (keahlian tim, tooling, dokumentasi internal, dll)?
          │
          ├─ Ya → Tetap NGINX — familiar = lebih produktif
          │
          └─ Tidak
                │
                ▼
            Apakah kamu butuh WAF (ModSecurity),
            Lua scripting, atau modul Nginx yang spesifik?
                │
                ├─ Ya → NGINX
                │
                └─ Tidak
                      │
                      ▼
                  Apakah ini proyek baru dengan tim kecil
                  yang tidak punya waktu untuk urus Certbot?
                      │
                      ├─ Ya → CADDY (setup lebih cepat)
                      │
                      └─ Tidak → Kedua-duanya bisa, pilih sesuai preferensi

Ringkasan #

• Caddy unggul dalam HTTPS otomatis, konfigurasi ringkas, konfigurasi dinamis via Admin API, dan kemudahan operasional.
• Nginx unggul dalam ekosistem plugin yang sangat matang (ModSecurity, Lua), dokumentasi yang sangat luas, raw performance pada workload ekstrem, dan dukungan enterprise via Nginx Plus.
• Perbedaan performa 5–15% hampir tidak pernah menjadi bottleneck nyata — jangan buat keputusan berdasarkan benchmark sintetis.
• Untuk proyek baru dengan tim kecil, Caddy hampir selalu lebih produktif — waktu yang dihemat dari tidak mengurus Certbot bisa digunakan untuk hal yang lebih bernilai.
• Untuk tim yang sudah deeply invested di Nginx — tetap di Nginx, familiar lebih berharga dari fitur baru.
• Untuk platform multi-tenant yang perlu mengelola ratusan domain secara programatik — Caddy Admin API adalah keunggulan yang sangat signifikan.

← Sebelumnya: Sejarah & Evolusi   Berikutnya: Caddy vs Apache →