Running Caddy in a cluster currently means that it will share certificates and other assets/data with the other instances in its cluster. A cluster is defined as Caddy instances which are configured to have the same storage as the other instances.
The website doesn’t yet have docs for third-party modules (I’ve been working on that the last two weeks… hopefully will have something to show later this week). For now, you can see what modules are available here: List of Caddy 2 Modules
One of the categories is storage modules. The default storage module (
file_system) is included, so it is on our website: https://caddyserver.com/docs/modules/caddy.storage.file_system
Yes to both. As you can see from the wiki, third-party modules currently include Consul, Redis, and DynamoDB.
Caddy instances that are configured to have the same storage will share data assets, for example TLS certificates: https://caddyserver.com/docs/automatic-https#storage (and they will even coordinate solving the ACME challenges together so you don’t have to take any pains of configuring a load balancer to handle those specially!) – Caddy does this automatically. For example, if you configure all to use the same redis DB or file system folder (maybe a network mount), Caddy will automatically share a single copy of every TLS certificate, and even coordinate its management so that if one initiates a renewal of it, another one can solve the ACME challenge and finish the renewal. They don’t need to talk to each other directly: it all happens through atomic operations in storage.
Typically, every instance that uses a storage module to coordinate/share or in other words “join a cluster” is primary.