Caddy dan Automatic HTTPS: Bagaimana SSL Ter-generate Sendiri

Setup HTTPS di server web biasanya berarti serangkaian langkah manual: install Certbot, jalankan perintah untuk request sertifikat, edit konfigurasi Nginx atau Apache untuk menunjuk ke file sertifikat, lalu pasang cron job supaya sertifikat diperbarui sebelum expired. Setiap langkah ini punya potensi kesalahan — lupa buka port 80 untuk validasi, salah path di konfigurasi, atau cron job yang diam-diam gagal berbulan-bulan sampai sertifikat kedaluwarsa dan situs down. Caddy mengambil pendekatan berbeda: cukup sebutkan domain di konfigurasi, dan HTTPS langsung aktif tanpa langkah tambahan. Artikel ini membahas apa yang sebenarnya terjadi di balik “keajaiban” ini — protokol yang dipakai, cara domain divalidasi, dan bagaimana siklus hidup sertifikat dikelola sepenuhnya oleh Caddy sendiri.

Apa Itu Caddy dan Automatic HTTPS

Caddy adalah web server dan reverse proxy open-source yang ditulis dalam Go, dikenal karena filosofi “secure by default”. Berbeda dari Nginx atau Apache yang menganggap HTTP sebagai mode normal dan HTTPS sebagai fitur tambahan yang harus dikonfigurasi manual, Caddy membalik asumsi ini: begitu kamu menyebutkan nama domain di konfigurasi, Caddy langsung berasumsi kamu ingin domain itu diakses lewat HTTPS, dan dia akan mengurus semuanya sendiri.

Fitur ini disebut Automatic HTTPS. Ia mencakup empat hal sekaligus: menerbitkan sertifikat TLS, memasangnya ke server, memperbarui sertifikat sebelum kedaluwarsa, dan — jika dikonfigurasi — mengalihkan trafik HTTP ke HTTPS secara otomatis. Semua ini terjadi tanpa satu baris konfigurasi tambahan untuk kasus penggunaan standar.

Untuk memahami skala perbedaannya, berikut perbandingan alur kerja antara pendekatan tradisional dan Caddy:

Perbedaan mendasar ini bukan sekadar soal kenyamanan — ia menghilangkan seluruh kelas bug operasional yang muncul dari proses manual yang terputus-putus.

Anatomi ACME Protocol

Automatic HTTPS di Caddy dibangun di atas ACME (Automatic Certificate Management Environment), sebuah protokol standar (RFC 8555) yang dirancang untuk otomatisasi penuh siklus hidup sertifikat TLS — mulai dari permintaan, validasi kepemilikan domain, penerbitan, sampai pencabutan.

ACME awalnya dikembangkan oleh Internet Security Research Group (ISRG) bersamaan dengan peluncuran Let’s Encrypt, certificate authority (CA) gratis yang menjadi pemicu utama adopsi HTTPS massal di web. Caddy mendukung Let’s Encrypt sebagai CA default, dengan ZeroSSL sebagai fallback otomatis jika Let’s Encrypt tidak bisa dihubungi. Selain itu, Caddy juga bisa dikonfigurasi memakai CA internal perusahaan (misalnya lewat Smallstep CA) selama CA tersebut mengimplementasikan ACME.

Peran CertMagic

Seluruh logika Automatic HTTPS di Caddy sebenarnya berada di sebuah library terpisah bernama CertMagic, yang juga ditulis oleh tim yang sama. CertMagic menangani:

• Komunikasi dengan ACME server (request, polling status, download sertifikat)
• Penyimpanan sertifikat dan private key secara aman di disk
• Penjadwalan pengecekan dan renewal otomatis
• Pemilihan challenge type yang paling sesuai untuk tiap domain
• Fallback antar CA jika salah satu tidak tersedia

Karena CertMagic adalah library Go yang independen, developer lain bisa memakainya di luar Caddy untuk membangun Automatic HTTPS ke aplikasi Go mereka sendiri. Tapi di konteks Caddy, CertMagic terintegrasi penuh sebagai bagian dari core, sehingga developer yang memakai Caddy tidak perlu tahu detail ini — cukup menyebutkan domain, dan CertMagic bekerja di balik layar.

Alur Komunikasi ACME Secara Umum

Berikut gambaran interaksi antara Caddy (lewat CertMagic) dan ACME server:

sequenceDiagram
    participant Caddy
    participant ACME as ACME Server (Let's Encrypt)
    participant Validator as Infrastruktur Validasi

    Caddy->>ACME: Request sertifikat untuk example.com
    ACME-->>Caddy: Kirim challenge (token unik)
    Caddy->>Caddy: Siapkan bukti sesuai challenge type
    ACME->>Validator: Verifikasi bukti kepemilikan domain
    Validator-->>ACME: Hasil verifikasi
    ACME-->>Caddy: Sertifikat diterbitkan (jika valid)
    Caddy->>Caddy: Simpan cert dan pasang ke server

Poin pentingnya: ACME server tidak langsung percaya begitu saja bahwa Caddy menguasai domain tersebut. Ia mengirim challenge yang harus dijawab dengan cara spesifik, dan baru memverifikasi jawaban itu dari sisi eksternal — inilah yang disebut proses domain validation.

Challenge Types — Cara Domain Divalidasi

Inti dari pertanyaan “bagaimana Caddy bisa generate SSL sendiri” ada di bagian ini. Validasi domain adalah mekanisme yang memastikan hanya pihak yang benar-benar menguasai domain (baik lewat kontrol server maupun kontrol DNS) yang bisa mendapat sertifikat untuk domain tersebut. Tanpa mekanisme ini, siapa saja bisa meminta sertifikat untuk domain milik orang lain.

Caddy mendukung tiga jenis challenge ACME, dan secara otomatis memilih salah satunya berdasarkan konfigurasi dan kondisi jaringan.

HTTP-01 — Validasi Lewat File di Port 80

Ini adalah metode paling umum dan menjadi default Caddy untuk sebagian besar kasus.

Cara kerja:

1. Caddy meminta sertifikat ke ACME server untuk domain example.com.
2. ACME server membalas dengan sebuah token unik, misalnya xK3f9a....
3. Caddy menghitung sebuah “key authorization” — kombinasi token dengan thumbprint dari account key milik Caddy sendiri — dan menyajikannya di path spesifik:

http://example.com/.well-known/acme-challenge/xK3f9a...

4. ACME server, dari infrastrukturnya sendiri (bukan dari Caddy), melakukan HTTP request ke URL tersebut.
5. Jika isi respons cocok dengan yang diharapkan, ACME server menganggap domain tervalidasi — karena hanya pihak yang benar-benar mengontrol server di balik example.com yang bisa menyajikan file di path itu.

flowchart TD
    A[Caddy request sertifikat] --> B[ACME kirim token]
    B --> C["Caddy serve token di\n/.well-known/acme-challenge/token"]
    C --> D[ACME server fetch URL dari luar]
    D --> E{Isi cocok?}
    E -- Ya --> F[Domain tervalidasi]
    E -- Tidak --> G[Validasi gagal]

HTTP-01 membutuhkan port 80 terbuka ke internet saat proses provisioning berlangsung, meskipun situs akhirnya akan diakses lewat port 443. Kalau port 80 diblokir firewall atau di-redirect ke tempat lain sebelum Caddy sempat menjawab challenge, penerbitan sertifikat akan gagal.

Metode ini tidak bisa dipakai untuk wildcard certificate (*.example.com), karena ACME server tidak tahu subdomain mana yang harus dicek — validasi HTTP-01 selalu spesifik per hostname.

TLS-ALPN-01 — Validasi Lewat Handshake TLS di Port 443

Metode ini berguna ketika port 80 tidak tersedia sama sekali (misalnya server yang memang hanya boleh melayani trafik di port 443, atau environment dengan pembatasan firewall ketat).

Cara kerja:

1. Caddy request sertifikat seperti biasa, menerima token dari ACME server.
2. Alih-alih menyajikan file lewat HTTP, Caddy membuat sertifikat TLS sementara — sertifikat self-signed khusus yang isinya menyematkan bukti kepemilikan token, ditandai dengan ekstensi khusus bernama acmeIdentifier.
3. Caddy mengonfigurasi server TLS untuk menyajikan sertifikat sementara ini, tapi hanya jika request datang dengan ALPN protocol khusus bernama acme-tls/1.
4. ACME server melakukan TLS handshake ke example.com:443 sambil meminta protokol acme-tls/1.
5. Caddy merespons dengan sertifikat sementara tadi. ACME server memverifikasi isi sertifikat itu cocok dengan token yang diberikan.
6. Jika cocok, domain tervalidasi — tanpa satu pun request HTTP biasa terjadi.

sequenceDiagram
    participant ACME as ACME Server
    participant Caddy

    ACME->>Caddy: TLS handshake ke port 443 (ALPN: acme-tls/1)
    Caddy->>Caddy: Buat sertifikat sementara berisi bukti token
    Caddy-->>ACME: Kirim sertifikat sementara
    ACME->>ACME: Verifikasi ekstensi acmeIdentifier
    ACME-->>Caddy: Validasi sukses, cert asli diterbitkan

Kelebihan metode ini adalah tidak butuh port 80 sama sekali — cocok untuk server yang benar-benar hanya membuka port 443. Kekurangannya sama seperti HTTP-01: tidak mendukung wildcard, dan hanya berfungsi untuk domain yang memang bisa diakses langsung oleh ACME server (server harus punya alamat IP publik yang di-resolve dari domain tersebut).

DNS-01 — Validasi Lewat DNS Record

Ini satu-satunya metode yang mendukung wildcard certificate, dan juga satu-satunya yang tidak butuh port apapun terbuka ke internet.

Cara kerja:

1. Caddy request sertifikat, kali ini bisa untuk domain wildcard seperti *.example.com.
2. ACME server memberi token yang harus dipasang sebagai TXT record di DNS dengan nama khusus:

_acme-challenge.example.com    TXT    "nilai-token-dari-ACME"

3. Caddy — lewat plugin DNS provider yang sudah dikonfigurasi (Cloudflare, Route53, DigitalOcean, dan puluhan provider lain) — memanggil API DNS provider tersebut untuk membuat TXT record ini secara otomatis.
4. Caddy menunggu beberapa saat untuk memastikan propagasi DNS selesai, lalu memberi tahu ACME server bahwa record sudah siap.
5. ACME server melakukan query DNS ke _acme-challenge.example.com, mencocokkan nilai TXT record dengan yang diharapkan.
6. Jika cocok, domain (termasuk seluruh wildcard-nya) tervalidasi. Caddy kemudian menghapus TXT record tersebut karena sudah tidak dibutuhkan.

flowchart TD
    A[Caddy request cert wildcard] --> B[ACME kirim token]
    B --> C[Caddy panggil API DNS provider]
    C --> D["Buat TXT record\n_acme-challenge.domain"]
    D --> E[Tunggu propagasi DNS]
    E --> F[ACME query TXT record]
    F --> G{Cocok?}
    G -- Ya --> H[Wildcard cert diterbitkan]
    G -- Tidak --> I[Validasi gagal / timeout]

DNS-01 adalah pilihan terbaik untuk server yang berada di belakang NAT, VPN, atau firewall ketat — karena validasi terjadi murni lewat kontrol DNS, tanpa perlu ACME server bisa menjangkau server Caddy sama sekali secara langsung.

Kekurangannya adalah kompleksitas setup: Caddy butuh API credential dari DNS provider dan plugin yang sesuai (Caddy tidak menyertakan semua provider secara default — build custom atau pakai image yang sudah menyertakan plugin dibutuhkan).

Perbandingan Ketiga Challenge Type

Caddy secara default akan mencoba HTTP-01 terlebih dahulu untuk domain biasa. Jika port 80 tidak bisa dipakai, Caddy otomatis fallback ke TLS-ALPN-01. Untuk domain wildcard, Caddy akan memaksa penggunaan DNS-01 karena memang hanya itu satu-satunya opsi yang valid secara protokol ACME.

Alur Lengkap dari Startup Sampai Sertifikat Aktif

Untuk memahami gambaran penuh, berikut apa yang terjadi sejak Caddy dijalankan sampai sebuah domain benar-benar bisa diakses lewat HTTPS:

flowchart TD
    A[Caddy start, baca konfigurasi] --> B{Domain butuh TLS?}
    B -- Tidak --> Z[Serve sebagai HTTP biasa]
    B -- Ya --> C{Sertifikat sudah ada di storage?}
    C -- Ya, masih valid --> D[Load sertifikat existing]
    C -- Tidak ada / expired --> E[Mulai proses ACME]
    E --> F[Pilih challenge type sesuai kondisi]
    F --> G[Jalankan validasi domain]
    G --> H{Validasi sukses?}
    H -- Ya --> I[Download sertifikat dari CA]
    H -- Tidak --> J[Retry dengan backoff, atau gagal]
    I --> K[Simpan sertifikat ke storage]
    K --> D
    D --> L[Pasang sertifikat ke TLS server]
    L --> M[Domain bisa diakses via HTTPS]

Beberapa detail penting dari alur ini:

Caddy tidak menunggu semua domain siap sebelum mulai melayani trafik. Setiap domain diproses secara independen — kalau kamu punya lima domain di satu konfigurasi, Caddy akan mulai melayani domain yang sertifikatnya sudah siap sementara domain lain masih dalam proses provisioning.

Storage sertifikat defaultnya di disk lokal, biasanya di $XDG_DATA_HOME/caddy (di Linux umumnya ~/.local/share/caddy), terorganisir per CA dan per domain. Isinya termasuk private key, sertifikat, dan metadata seperti tanggal terbit dan expiry. Untuk deployment multi-instance (misalnya di belakang load balancer dengan beberapa node Caddy), storage ini bisa diarahkan ke backend terdistribusi seperti Redis atau database lewat plugin storage, supaya semua instance berbagi sertifikat yang sama tanpa masing-masing melakukan request terpisah ke ACME server.

Rate limit dari CA jadi pertimbangan penting. Let’s Encrypt membatasi jumlah sertifikat yang bisa diterbitkan per domain per minggu (saat ini 50 sertifikat per domain terdaftar per minggu, dan retry gagal dibatasi juga). Inilah kenapa berbagi storage antar instance penting — tanpa itu, tiap instance akan mencoba request sertifikat terpisah untuk domain yang sama dan bisa cepat kena rate limit.

Auto-Renewal — Mekanisme di Balik Layar

Sertifikat dari Let’s Encrypt punya masa berlaku pendek: 90 hari. Ini bukan kelemahan, justru desain yang disengaja — masa berlaku pendek mengurangi dampak kalau ada private key yang bocor, dan memaksa proses renewal jadi kebiasaan otomatis, bukan tugas tahunan yang gampang terlupakan.

Caddy menangani ini lewat proses background yang berjalan selama Caddy aktif:

1. Caddy secara periodik mengecek semua sertifikat yang dikelolanya.
2. Untuk setiap sertifikat, Caddy menghitung sisa masa berlaku.
3. Kalau sertifikat tersisa kurang dari sepertiga masa berlaku total (untuk Let’s Encrypt, ini berarti mulai renewal di sekitar 30 hari sebelum expired), Caddy memulai proses renewal — mengulang seluruh alur ACME dari awal (request, challenge, validasi, penerbitan) untuk domain tersebut.
4. Sertifikat baru dipasang tanpa restart server dan tanpa downtime — koneksi TLS yang sedang berlangsung tetap memakai sertifikat lama sampai selesai, sementara koneksi baru langsung memakai sertifikat baru begitu tersedia.

stateDiagram-v2
    [*] --> Aktif: Sertifikat terbit
    Aktif --> MendekatiExpiry: Sisa masa berlaku < 1/3
    MendekatiExpiry --> ProsesRenewal: Trigger renewal otomatis
    ProsesRenewal --> Aktif: Renewal sukses, cert baru terpasang
    ProsesRenewal --> RetryBackoff: Renewal gagal
    RetryBackoff --> ProsesRenewal: Retry dengan jeda bertambah
    RetryBackoff --> Expired: Semua retry gagal, cert expired

Kalau semua percobaan retry gagal — misalnya karena domain sudah tidak mengarah ke server yang benar, atau DNS provider API credential expired — sertifikat akan benar-benar kedaluwarsa dan situs akan menampilkan error TLS ke pengunjung. Caddy akan mencatat error ini di log, jadi monitoring terhadap log Caddy tetap penting meskipun proses renewal sudah otomatis.

Strategi retry Caddy memakai exponential backoff — jeda antar percobaan renewal yang gagal semakin lama, supaya tidak membanjiri ACME server dengan request berulang dalam waktu singkat, sekaligus memberi waktu untuk masalah sementara (misalnya gangguan jaringan) untuk pulih dengan sendirinya.

Konfigurasi Praktis — Caddyfile

Bagian ini menunjukkan bagaimana semua konsep di atas diterjemahkan jadi konfigurasi nyata lewat Caddyfile, format konfigurasi native Caddy yang ringkas dibanding alternatif JSON.

Konfigurasi Minimal

Automatic HTTPS aktif secara default begitu kamu menyebutkan domain:

example.com {
    reverse_proxy localhost:3000
}

Tidak ada baris tambahan untuk TLS. Caddy otomatis:

• Request sertifikat untuk example.com lewat HTTP-01
• Redirect trafik dari port 80 ke port 443
• Menyajikan trafik lewat HTTPS ke aplikasi backend di port 3000
• Menjadwalkan renewal otomatis

Override CA — Staging vs Production

Saat development atau testing konfigurasi, sangat disarankan memakai staging environment dari Let’s Encrypt, karena environment production punya rate limit ketat yang gampang tersentuh kalau kamu berulang kali restart Caddy dengan konfigurasi salah:

{
    acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

example.com {
    reverse_proxy localhost:3000
}

Sertifikat dari staging tidak dipercaya browser (akan muncul warning), tapi ini normal — tujuannya memvalidasi bahwa seluruh alur ACME berjalan benar sebelum beralih ke production CA.

Setup DNS-01 dengan Plugin

Untuk wildcard certificate, dibutuhkan plugin DNS provider. Caddy dengan plugin Cloudflare (dibangun lewat xcaddy atau image Docker yang sudah menyertakan plugin) dikonfigurasi seperti berikut:

{
    email [email protected]
}

*.example.com, example.com {
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }
    reverse_proxy localhost:3000
}

API token disimpan sebagai environment variable, bukan hardcoded di file konfigurasi — praktik ini penting untuk keamanan, terutama kalau Caddyfile disimpan di repository Git.

export CLOUDFLARE_API_TOKEN="token-rahasia-dari-cloudflare"
caddy run

On-Demand TLS — Untuk Domain Dinamis

Kasus penggunaan menarik lainnya adalah aplikasi multi-tenant di mana pelanggan bisa memasang custom domain mereka sendiri (misalnya platform seperti Shopify atau Webflow). Menyebutkan setiap domain secara eksplisit di konfigurasi tidak praktis kalau jumlahnya bisa ribuan dan berubah setiap saat.

On-demand TLS memungkinkan Caddy menerbitkan sertifikat saat itu juga, tepat ketika request pertama untuk domain baru datang:

{
    on_demand_tls {
        ask http://localhost:8080/check-domain
    }
}

:443 {
    tls {
        on_demand
    }
    reverse_proxy localhost:3000
}

Endpoint ask di sini penting sebagai pengaman: sebelum Caddy mau menerbitkan sertifikat untuk domain yang belum dikenal, ia akan bertanya dulu ke endpoint tersebut apakah domain itu memang valid dan terdaftar di sistem kamu. Tanpa pengaman ini, siapa saja bisa mengarahkan domain apa pun ke server Caddy kamu dan memicu penerbitan sertifikat tanpa batas — berpotensi memicu rate limit dari CA atau bahkan disalahgunakan sebagai vektor serangan.

On-demand TLS wajib dipasangkan dengan endpoint ask di lingkungan production. Tanpa validasi ini, server kamu jadi rentan terhadap penyalahgunaan yang menghabiskan rate limit ACME milikmu untuk domain-domain yang tidak sah.

Local Development — Caddy sebagai Local CA

Salah satu fitur yang sering luput diperhatikan adalah kemampuan Caddy menyajikan HTTPS bahkan untuk localhost atau domain internal seperti myapp.local, tanpa perlu setup manual seperti yang biasa dilakukan dengan tool mkcert.

Untuk domain lokal, Caddy tidak memakai ACME sama sekali (karena ACME hanya berlaku untuk domain publik yang bisa diverifikasi). Sebagai gantinya, Caddy menjalankan local Certificate Authority miliknya sendiri:

1. Saat pertama kali dijalankan, Caddy membuat root certificate lokal dan menyimpannya di storage lokal.
2. Caddy menawarkan untuk menambahkan root certificate ini ke trust store sistem operasi (butuh permission admin/sudo sekali saja).
3. Setelah root certificate dipercaya sistem, Caddy bisa menerbitkan sertifikat “asli” (dari sudut pandang browser) untuk domain apa pun yang kamu jalankan secara lokal.

localhost {
    reverse_proxy localhost:3000
}

Konfigurasi ini langsung menghasilkan HTTPS yang valid di browser untuk https://localhost, tanpa warning sertifikat tidak dipercaya — sangat berguna untuk testing fitur yang butuh secure context (seperti Service Worker atau WebAuthn) di environment development.

Kapan Automatic HTTPS Tidak Cocok atau Perlu Disesuaikan

Meskipun Automatic HTTPS sangat kuat, ada beberapa skenario di mana pendekatan default perlu disesuaikan atau bahkan dinonaktifkan:

Server internal tanpa akses publik. Kalau server Caddy hanya bisa diakses dari jaringan internal (VPN corporate, misalnya), ACME publik seperti Let’s Encrypt tidak bisa memvalidasi domain lewat HTTP-01 atau TLS-ALPN-01 karena CA tidak bisa menjangkau server dari luar. Solusinya adalah DNS-01 (kalau domain publik tapi server privat), atau memakai internal CA seperti Smallstep step-ca yang mendukung ACME tapi berjalan di infrastruktur milik sendiri.

Kebutuhan sertifikat dari CA korporat/internal. Beberapa organisasi punya kebijakan compliance yang mewajibkan sertifikat diterbitkan oleh CA internal perusahaan, bukan CA publik. Caddy mendukung ini selama CA tersebut mengimplementasikan protokol ACME — cukup arahkan acme_ca ke endpoint CA internal.

Load balancer atau CDN di depan Caddy yang sudah menangani TLS termination. Kalau arsitektur sudah memakai CDN (Cloudflare, CloudFront) atau load balancer cloud yang sudah menangani sertifikat TLS di layer depan, Caddy di belakangnya sering tidak perlu mengurus TLS sama sekali — traffic dari load balancer ke Caddy bisa berupa HTTP biasa dalam jaringan privat. Dalam kasus ini, Automatic HTTPS bisa dinonaktifkan eksplisit:

example.com {
    tls internal
    reverse_proxy localhost:3000
}

Directive tls internal memaksa Caddy memakai local CA (bukan ACME publik) — cocok untuk skenario di mana enkripsi tetap dibutuhkan di dalam jaringan privat tapi tidak perlu sertifikat yang dipercaya publik.

Rate limit yang gampang tersentuh saat testing berulang. Seperti disebutkan sebelumnya, iterasi konfigurasi yang cepat dengan restart berulang bisa memicu rate limit Let’s Encrypt production. Selalu pakai staging CA saat development konfigurasi baru.

Multi-instance tanpa shared storage. Kalau menjalankan banyak instance Caddy untuk domain yang sama tanpa storage backend bersama, tiap instance akan mencoba request sertifikat independen — berpotensi memicu rate limit dan menciptakan sertifikat yang tidak konsisten antar instance. Solusinya adalah shared storage lewat plugin seperti caddy-storage-redis atau backend serupa.

Ringkasan

• Automatic HTTPS di Caddy dibangun di atas protokol ACME, dijalankan lewat library internal bernama CertMagic, dengan Let’s Encrypt sebagai CA default dan ZeroSSL sebagai fallback.
• Validasi domain terjadi lewat tiga jenis challenge: HTTP-01 (file di port 80), TLS-ALPN-01 (handshake TLS khusus di port 443), dan DNS-01 (TXT record di DNS, satu-satunya yang mendukung wildcard).
• DNS-01 adalah pilihan terbaik untuk server di belakang NAT/firewall dan untuk wildcard certificate, tapi butuh plugin DNS provider dan API credential.
• Caddy otomatis memilih challenge type paling sesuai berdasarkan konfigurasi dan ketersediaan port, dengan HTTP-01 sebagai default.
• Auto-renewal dipicu ketika sisa masa berlaku sertifikat kurang dari sepertiga total (untuk Let’s Encrypt, sekitar 30 hari sebelum expired), berjalan tanpa downtime dan tanpa restart server.
• Sertifikat disimpan di storage lokal secara default, tapi untuk deployment multi-instance sebaiknya memakai shared storage backend untuk menghindari rate limit dan inkonsistensi.
• On-demand TLS memungkinkan penerbitan sertifikat dinamis untuk aplikasi multi-tenant, tapi wajib dipasangkan dengan endpoint ask untuk mencegah penyalahgunaan.
• Untuk local development, Caddy menjalankan local CA sendiri sehingga localhost dan domain internal bisa punya HTTPS valid tanpa tool tambahan seperti mkcert.
• Automatic HTTPS bisa dinonaktifkan atau disesuaikan lewat tls internal untuk skenario di mana TLS termination sudah ditangani layer lain, atau saat server tidak punya akses publik yang dibutuhkan ACME.