Caddy is organized into three main components: a command, the core library, and configuration modules.^[8] The command is the extensible interface by which the program is executed; it can also load configuration files, run common modes, manage installed plugins, and offer relevant utility functions. The core library has APIs for loading, unloading, and managing configuration; but it does nothing particularly useful on its own. Most of Caddy's functionality is provided by modules, which are plugins that extend Caddy's configuration structure; for example, the HTTP server is a module.^[9] Caddy modules implement various long-running services, web standards, and other useful features.

Caddy's input is a JSON configuration document^[10] which is received through an open socket via a RESTful HTTP API.^[11][6] In the absence of an HTTP client, Caddy's command-line interface can be used to load configuration files.^[12] Config adapters may be used to convert other configuration formats to JSON. Existing adapters include the Caddyfile, which has first-class support in the command line; and YAML, TOML, Nginx, and several other formats.^[13][6]

When a configuration is received through its administration socket, Caddy decodes the configuration for all the specified modules, and starts running all the app modules.^[6] When the app modules are being provisioned, they themselves may load and provision modules that they use. For example, the HTTP server is an app module which uses HTTP handler modules to handle HTTP requests; these handlers might use yet other modules to implement their functionality, and so on.^[14] All these modules are provisioned during the config load phase.^[8]

Plugins are installed by statically compiling them directly into the Caddy binary.^[3][6] Without plugins, Caddy's native configuration structure only has some basic options for administration and logging.^[10] All other functionality must be provided by app modules. Official Caddy distributions ship with dozens of standard modules;^[5] others can be added from the project's website,^[15] using the xcaddy command line tool, or by manually compiling a custom build.^[16]

Miek Gieben forked Caddy to use as the core of CoreDNS, now a project of the Cloud Native Computing Foundation, as he appreciated its overall architecture and simplicity of its configuration.^[17]

The HTTP server is an app module that comes standard with official Caddy distributions.^[9] It is primarily used as a static file server^[18] and load-balancing reverse proxy.^[19] While the basis of Caddy's HTTP features use the implementation found in Go's standard library,^[20] a variety enhancements and customizations are available as middleware and exposed through configuration parameters:^[6]

By default, TLS is used automatically if any routes have a non-empty host matcher.^[21] These are assumed to be site names or IP addresses that Caddy is serving, so Caddy will automatically procure and renew certificates for the configured hostnames and IP addresses. When automatic HTTPS is activated in this manner, Caddy will also redirect HTTP requests to their equivalent HTTPS location.

Caddy version 2 was released on May 5, 2020.^[7] Reviewers say that it still has a simpler configuration file syntax than the Apache Web Server, although version 2's configuration format is largely incompatible with the previous major release of Caddy.^[7][22]

• Official website