Web / Caddy Server Interview questions
How does Caddy's storage module work for certificate persistence?
Certificates, private keys, and ACME account data all need to survive restarts and, in a cluster, be visible to every instance - that's the job of CertMagic's Storage interface, which Caddy uses for everything related to certificate persistence.
| Storage backend | Typical use case |
| file_system (default) | Single server; writes to a local data directory, e.g. /var/lib/caddy or /data. |
| Redis / Consul / etcd | Shared, low-latency storage for a cluster of Caddy instances. |
| S3 / object storage | Durable shared storage decoupled from any single node's disk. |
| DynamoDB and similar | Managed cloud-native storage with built-in locking for clustered issuance. |
The default file-system backend works fine for a single instance, but in a multi-node cluster behind a load balancer, every node needs to see the same certificate for a given domain - otherwise each node might independently try to issue its own certificate for the same hostname, risking Let's Encrypt rate limits. Pluggable storage modules (compiled in via xcaddy) solve this by pointing every instance at one shared backend, and CertMagic's Storage interface also includes distributed locking so only one node performs an ACME transaction for a given domain at a time.
More Related questions...
