Caddy Web Server Documentation

website·Indexed Apr 13, 2026

https://caddyserver.com/docs/

Official documentation for Caddy, an open-source web server written in Go with automatic HTTPS. Covers Caddyfile and JSON configuration formats, admin API for runtime configuration, command-line interface, module/plugin architecture, reverse proxy and static file serving, TLS certificate management via ACME protocol with Let's Encrypt and ZeroSSL, Prometheus metrics, structured logging, and systemd deployment on Linux.

Tokens
69.5K
Snippets
55
Records
704
Agent score
50%

What's inside Caddy

  1. Caddyfile versus JSON configuration

    The Caddyfile is a config adapter for Caddy. It is preferred for manually crafting configurations but is less expressive, flexible, or programmable than Caddy's native JSON structure. For automated deployments, use JSON with Caddy's API. The Caddyfile can also be used with the API to a limited extent.
  2. Reverse proxy with load balancing and health checks

    Caddy's reverse_proxy handles HTTP, HTTPS, WebSockets, gRPC, and FastCGI. Configure dynamic backends via DNS SRV records (dynamic srv _api._tcp.example.com), load balancing policies (e.g., lb_policy least_conn), active/passive health checks with fail_duration and lb_try_duration, circuit breaking, retries, and graceful config changes. Example: reverse_proxy /api/* { dynamic srv _api._tcp.example.com } or reverse_proxy /service/* { to 10.0.1.1:80 10.0.1.2:80; lb_policy least_conn; lb_try_duration 10s; fail_duration 5s }.
  3. intercept directive overview and behavior

    The intercept directive intercepts and modifies HTTP responses before they reach the client. It is a generalized abstraction of the response interception feature from the reverse_proxy directive, and can be used with any handler that produces responses (e.g., FrankenPHP's php_server). The directive matches responses using response matchers; the first matching handle_response route or replace_status will be invoked. When invoked, the original response body is held back, giving the opportunity to write a different response body, new status code, or header manipulations. If the route does not write a new response body, the original response body is written instead.
  4. Caddy web server overview

    Caddy is a powerful, extensible platform to serve sites, services, and apps, written in Go. At its core, it is a server of servers that can take on the role of any long-running process with the requisite modules. Caddy compiles for all major platforms and has no runtime dependencies. Most users employ Caddy as a web server or reverse proxy.
  5. forward_auth directive overview

    The forward_auth directive offloads authentication to an external gateway by forwarding requests to a verification endpoint. It is an opinionated wrapper around reverse_proxy tailored for authentication use cases. If the upstream responds with a 2xx status code, access is granted and configured headers are copied to the original request. Any other status code causes the upstream's response (typically a redirect to a login page) to be returned to the client.
  6. HTTPS for localhost and internal networks

    Caddy serves HTTPS for localhost and internal IP addresses using a fully-automated, self-managed internal Certificate Authority (CA). This CA is automatically installed into most local trust stores. Certificates are provisioned on-demand for any localhost address, enabling production-like HTTPS testing during development.
  7. Verify Caddy artifact signatures using Sigstore

    Caddy v2.6.0+ release artifacts are signed using Sigstore technology. This allows you to validate that the artifact you downloaded matches the original and was not modified by an unauthorized party (e.g., man-in-the-middle attack). To verify, download three files: the artifact itself, its .sig signature file, and its .pem certificate file. Then decode the certificate and inspect it with OpenSSL.
  8. Extending Caddy with plugins

    Caddy's plugin architecture allows extending functionality beyond the core. Modules are plugins that extend Caddy's JSON config structure. Standard modules are those bundled with Caddy as the most commonly useful. Modules can also add subcommands to the CLI with custom flags and environment variables.
  9. Add Caddyfile support to custom Caddy modules

    Caddy modules are automatically usable via the native JSON config when registered with their namespace. Caddyfile support is optional but often requested by users. To add Caddyfile support, implement the caddyfile.Unmarshaler interface on your module type. The interface gives you control over the Caddyfile syntax through how you parse tokens.
  10. Caddy Admin API Overview

    Caddy's admin API is a REST API accessible via HTTP on the admin endpoint. Default address is localhost:2019. Change it via the CADDY_ADMIN environment variable or in the Caddy config (config takes precedence). The admin endpoint can be configured in the JSON config under admin {}. Configuration changes are saved to disk automatically unless disabled. Use caddy run --resume to restore the last working config after a restart.
  11. Redirect a specific path to a new location

    To redirect a specific path (e.g., /about-us) to a new path (/about) while handling other requests with another directive:

    example.com {
        redir /about-us /about
        reverse_proxy localhost:9000
    }

    example.com { redir /about-us /about reverse_proxy localhost:9000 }

  12. Adding custom modules to Caddy

    Caddy modules are plugins that extend Caddy's JSON configuration structure. Non-standard modules can be added using xcaddy or the download page. To build a custom Caddy binary with additional modules, use: xcaddy build --with <module>