caddy v2.5 releases: Fast, cross-platform HTTP/2 web server with automatic HTTPS

Caddy is fast, easy to use, and makes you more productive.

Available for Windows, Mac, Linux, BSD, Solaris, and Android.

Features

• Easy configuration with the Caddyfile
• Automatic HTTPS on by default (via Let’s Encrypt)
• HTTP/2 by default
• Virtual hosting so multiple sites just work
• Experimental QUIC support for those that like speed
• TLS session ticket key rotation for more secure connections
• Extensible with plugins because a convenient web server is a helpful one
• Runs anywhere with no external dependencies (not even libc)

Changelog v2.5

Highlights

• Reverse proxy: ✨ Dynamic upstreams, which is the ability to get the list of upstreams at every request (more specifically, every iteration in the proxy loop of every request) rather than just once at config-load time. Dynamic upstream modules can be plugged in to provide Caddy with the latest list of backends in real-time. Two standard modules have been implemented which can get upstreams from SRV and A/AAAA record lookups.
  • ⚠️ This deprecates the lookup_srv JSON field for upstreams (and srv+ scheme prefix in the Caddyfile), which will be removed in the future.
• Automatic HTTPS: Caddy will automatically try to get relevant certificates from the local Tailscale instance (if running with permission to access the Tailscale socket). This makes services running on a Tailscale network automatically available over trusted HTTPS with Caddy.
• Tracing: New OpenTelemetry integration with the tracing handler module and associated tracing directive.
• Reverse proxy: When using the response handlers, a new handler copy_response is available to copy the proxy’s response back to the client, and copy_response_headers may be used to selectively copy header values from the proxy’s response.
• API: Added new endpoints /pki/ca/<id> and /pki/ca/<id>/certificates for getting information about Caddy’s managed CAs, including the chain of root and intermediate certificates.

Notable

• Reverse proxy: The X-Forwarded-Host header will now be automatically set, along with X-Forwarded-For and X-Forwarded-Proto.
• ⚠️ Reverse proxy: Incoming X-Forwarded-* headers will no longer be automatically trusted, to prevent spoofing. Now, trusted_proxies must be configured to specify a list of downstream proxies which are trusted to have sent good values. You only need to configure trusted proxies if Caddy is not the first server being connected to. For example, if you have Cloudflare in front of Caddy, then you should configure this with Cloudflare’s list of IP ranges.
• Automatic HTTPS: Revoked certificates will be automatically replaced more reliably.
• Automatic HTTPS: Can now get certificates from Managers. As opposed to Issuers (such as the default ACME issuers) which give Caddy certificates to manage from a CSR, Managers give Caddy certificates to serve (rather than manage) during TLS handshakes.
• Automatic HTTPS: A DNS challenge domain override can be configured to delegate the solving of the challenge to a different domain.
• Automatic HTTPS: The DNS challenge propagation checks can now be delayed or disabled by setting propagation_delay or propagation_timeout to -1, respectively.
• Reverse proxy: The default dial timeout for the HTTP transport has been adjusted down to 3s (was 10s), which should allow for more easily configuring load balancing retries.
• Logging: HTTP access logs will now render empty values for often-sensitive HTTP headers such as Cookie, Authorization, and Proxy-Authorization. Logging such credentials is now opt-in with the log_credentials global option in the Caddyfile, or the server’s logs > should_log_credentials field in JSON.
• Logging: Logs can now be filtered by query string parameters, cookie values, and regular expressions; and log values can be hashed. These features are useful for redacting sensitive information.
• Logging: Errors during request handling will now be logged at DEBUG level if the error was handled via errors routes (handle_errors in Caddyfile).
• ⚠️ Logging: Removed the deprecated common_log field from HTTP access logs, and the single_field encoder. If you relied on this, you may use the transform encoder plugin to encode logs in Common Log format.
• ⚠️ Logging: The remote_addr field has been replaced by remote_ip and remote_port fields in HTTP access logs, which split up the two parts of the remote address. This improves ease of use for some tooling which only expect an IP address, without a port.
• HTTP server: The vars matcher can now match on multiple possible values.
• HTTP server: Requests can now be assigned a random and unique UUID from the new {http.request.uuid} placeholder.
• HTTP server: New http_redirect listener wrapper which can be used to redirect HTTP requests that come in on a server listening for HTTPS requests to be redirected to https://.
• ⚠️ Caddyfile: Deprecated paths in site addresses. Prefer using path matchers within your site block instead.
• Caddyfile: New default_bind global option lets you specify the default interface all sockets should bind to.
• Caddyfile: New pki global option lets you configure the properties of the internal CAs managed by Caddy.
• Caddyfile: New method directive allows rewriting the request method via Caddyfile.
• ⚠️ Caddyfile: The reverse_proxy directive’s handle_response subdirective has had its status replacement functionality moved to a new replace_status subdirective. This makes sure that the functionality of handle_response is not overloaded, and usage is clearer.
• Caddyfile: The map directive now casts outputs to the appropriate scalar type if possible (int, float, bool). If you need to force a string, you may use double quotes or backticks #4643.
• Caddyfile: New vars directive allows setting some variables during request handling for later use in another handler or matcher.
• Caddyfile: The Caddyfile adapter is now stricter about curly braces for block openers to try to prevent parsing ambiguities.
• Caddyfile: The caddy fmt CLI command now has a --diff option which lets you visually see the formatting differences.
• ⚠️ Admin: Renamed experimental property load_interval ➡️ load_delay for clarification, and improved dynamic config loading.

Download