Caddy v2.11.7

Caddy is an open-source web server and reverse proxy designed to make modern HTTPS deployments simpler. Written in Go, it combines a web server, automatic TLS certificate management, reverse proxy, static file server, and extensible module system in a single application.

Its biggest differentiator is automatic HTTPS. When configured with a domain name, Caddy can obtain and renew certificates and redirect HTTP traffic to HTTPS without requiring the extensive certificate configuration often associated with traditional web servers.

Features

Caddy supports HTTP/1.1, HTTP/2, and HTTP/3, with modern protocols enabled by default. It can serve static websites and files, or act as a reverse proxy in front of applications and services.

The Caddyfile provides a relatively simple configuration syntax for common deployments, while Caddy's native JSON configuration and API provide considerably more control for advanced setups. Configuration adapters also allow other formats to be converted into Caddy's native configuration model.

The reverse proxy supports multiple upstreams, load balancing, active and passive health checking, retries, connection pooling, header manipulation, buffering, and different transport options. This makes Caddy capable of handling substantially more than a basic single-backend proxy.

Caddy's TLS system can automatically obtain publicly trusted certificates using supported ACME issuers, while its internal CA can be used for internal services and local development. It also supports features such as multi-issuer fallback and Encrypted ClientHello.

The architecture is highly modular. Caddy functionality is implemented through modules, allowing additional capabilities to be added without modifying the core application. The official project also provides an extensive plugin ecosystem.

Download Caddy v2.11.7 - Software Mirrors
Caddy v2.11.7 for Windows caddy_2.11.7_windows_arm64.zip | 15.78 MB caddy_2.11.7_windows_amd64.zip | 17.62 MB
Caddy v2.11.7 for macOS caddy_2.11.7_mac_arm64.tar.gz | 16.5 MB caddy_2.11.7_mac_amd64.tar.gz | 17.69 MB
Caddy v2.11.7 for Linux caddy_2.11.7_linux_s390x.tar.gz | 16.66 MB caddy_2.11.7_linux_s390x.deb | 16.69 MB caddy_2.11.7_linux_riscv64.tar.gz | 16.3 MB caddy_2.11.7_linux_riscv64.deb | 16.33 MB caddy_2.11.7_linux_ppc64le.tar.gz | 15.72 MB caddy_2.11.7_linux_ppc64le.deb | 15.74 MB caddy_2.11.7_linux_armv7.tar.gz | 16.34 MB caddy_2.11.7_linux_armv7.deb | 16.37 MB caddy_2.11.7_linux_armv6.tar.gz | 16.36 MB caddy_2.11.7_linux_armv6.deb | 16.38 MB caddy_2.11.7_linux_armv5.tar.gz | 16.37 MB caddy_2.11.7_linux_armv5.deb | 16.39 MB caddy_2.11.7_linux_arm64.tar.gz | 15.72 MB caddy_2.11.7_linux_arm64.deb | 15.75 MB caddy_2.11.7_linux_amd64.tar.gz | 17.27 MB caddy_2.11.7_linux_amd64.deb | 17.3 MB
Caddy v2.11.7 for BSD caddy_2.11.7_freebsd_armv7.tar.gz | 16.27 MB caddy_2.11.7_freebsd_armv6.tar.gz | 16.29 MB caddy_2.11.7_freebsd_arm64.tar.gz | 15.65 MB caddy_2.11.7_freebsd_amd64.tar.gz | 17.2 MB
Others Download related to Caddy v2.11.7 caddy_2.11.7_src.tar.gz | 11.46 MB caddy_2.11.7_checksums.txt | 6.61 kB caddy_2.11.7_buildable-artifact.tar.gz | 11.01 MB
Caddy v2.11.7 Source Code Caddy v2.11.7 Source code (zip) Caddy v2.11.7 Source code (tar.gz)
Caddy v2.11.7 Release Notes: This patch release fixes regressions from 2.11.6, including a crash when proxying over HTTP/2 and streams that were cut off after a minute. If you're on 2.11.6, we recommend upgrading. It also adds support for the brand new Incremental header field (RFC 10036). Huge thank you to our sponsors for keeping the project alive with resources, and for our maintainers who triage and assist tirelessly in this relentless new age of AI. Highlights Fixed: crash and dropped streams caused by the new idle timeouts. 2.11.6 introduced default idle read/write timeouts, which caused some problems: In 2.11.6, the request body's idle deadline could outlive the handler that set it: -- - Over HTTP/2, Caddy could panic with a nil pointer dereference when the reverse proxy was still reading a request body after the handler had returned. (#8101) -- - Over HTTP/1.1, streaming responses to requests with a body, such as SSE clients that open the stream with a POST, were cut off exactly 60 seconds after the body was read. (#8103) -- Both are fixed in #8107. Thanks @steadytao! Over HTTP/2, streaming responses that paused between writes for longer than write_idle (1 minute by default), like quiet SSE streams, were reset with a stream error. As documented, only a write that stalls should count. Thanks @WeidiDeng! (#8118, #8119) Fixed: placeholders for missing cookies are empty again. Since 2.11.6, places that keep unknown placeholders as written, like respond headers, would output {http.request.cookie.} literally when the cookie wasn't in the request. The same happened to {http.request.tls.} on plain HTTP requests. Both are empty again. Thanks @steadytao! (#8019) New: support for the Incremental header field (RFC 10036). It's the standard replacement for NGINX's proprietary X-Accel-Buffering header. If an upstream response has Incremental: ?1, reverse_proxy forwards it immediately, the same as flush_interval -1, and encode streams it instead of holding it back. Great for Mercure, SSE and other streaming apps. If the request_buffers or response_buffers options would prevent incremental forwarding, Caddy responds with 501 Not Implemented instead of silently buffering, as the RFC requires. The new proxy_status_name option adds a Proxy-Status header to those responses, explaining why the message was refused. Thanks @dunglas! (#8020) Faster TLS handshakes: When nothing subscribes to certificate events and debug logging is off, CertMagic no longer builds event data for every handshake. Certificate lookup per handshake is about twice as fast, with 10 allocations instead of 15. Thanks @u5surf! (#8010) Unix sockets: When a reload moves a listener (or the admin endpoint) off a Unix socket, the old socket now closes right away and its file is removed. Before, clients connecting to the old path would hang until the next garbage collection, about 2 minutes later. Thanks @littfed! (#8061) Headers handler: Multiple Set-Cookie values in a JSON config's set are now sent as separate header fields, instead of being joined with commas into one field that clients can't parse. Thanks @Indra55! (#8080) caddy fmt no longer deletes an opening brace at the very end of the input. Thanks @n0liu! (#8047) What's Changed events: tell CertMagic which events are worth emitting by @u5surf in #8010 feat: implement the Incremental header field (RFC 10036) by @dunglas in #8020 caddyfile: Keep an opening brace that ends the input by @n0liu in #8047 listeners: close unix socket immediately and unlink file on reload by @littfed in #8061 reverseproxy: stabilise half-close test by @steadytao in #8049 caddyhttp: keep absent optional placeholders empty by @steadytao in #8019 headers: Preserve separate Set-Cookie values by @Indra55 in #8080 caddyhttp: end request-body deadline ownership with handler by @steadytao in #8107 timeouts: fix idle writer terminate h2 response writers between writes by @WeidiDeng in #8119 New Contributors @n0liu made their first contribution in #8047 @littfed made their first contribution in #8061 Full Changelog: v2.11.6...v2.11.7

Performance and Compatibility

Caddy is written in Go and compiles for major platforms without requiring external runtime dependencies. It can be deployed directly as a binary, in containers, or through other supported installation methods.

Its performance is strong enough for production web serving and reverse-proxy workloads, while the configuration model is arguably its bigger advantage over traditional alternatives. A simple reverse proxy can be configured with only a few lines, while more complex deployments can use the JSON API and modular configuration system.

Caddy is particularly attractive for administrators who regularly deploy HTTPS services. Automatic certificate provisioning and renewal remove much of the routine TLS maintenance, while the same configuration can handle reverse proxying, static files, headers, compression, and other HTTP functions.

There is a learning curve once deployments move beyond simple Caddyfile configurations. Caddy's underlying JSON configuration and modular architecture are powerful, but understanding modules, matchers, handlers, transports, and adapters takes time.

For administrators migrating from Nginx or Apache, Caddy's configuration model is also substantially different. Existing configurations cannot simply be copied over, although Caddy provides configuration adapters for several formats.

System Requirements

• Windows, Linux, macOS, or another supported platform

• 64-bit or platform-appropriate Caddy binary

• Network access for public certificate issuance and renewal when using publicly trusted HTTPS certificates

• Ports 80 and 443 when using standard public HTTPS with automatic certificate management

• Additional storage and resources depending on website, proxy, logging, and workload requirements

Pros and Cons

Pros

• Automatic HTTPS and certificate renewal

• HTTP/1.1, HTTP/2, and HTTP/3 support

• Simple Caddyfile configuration

• Powerful JSON configuration and API

• Excellent reverse-proxy capabilities

• Load balancing and health checking

• Static file server

• Highly extensible modular architecture

• Cross-platform

• No external runtime dependencies

• Supports internal HTTPS with its own CA

• Suitable for containers and modern infrastructure

• Strong support for automated deployments

Cons

• Configuration becomes more complex for advanced deployments

• Different configuration model from Nginx and Apache

• Large plugin ecosystem can make choosing extensions more complicated

• Some advanced functionality requires understanding Caddy's module architecture

• Automatic HTTPS still requires correct DNS and network configuration for public services

• Migration from existing Nginx or Apache configurations requires rewriting the configuration

How to Install

Download the appropriate Caddy package for your operating system or use one of the supported installation methods.

For a basic HTTPS website, create a Caddyfile containing the domain and the desired handler. For example:

example.com {
    reverse_proxy localhost:9000
}

Run Caddy with the configuration file. If the domain resolves to the server and ports 80 and 443 are reachable, Caddy can automatically obtain and manage the TLS certificate.

For containerized deployments, Caddy can also be run as a Docker container with configuration and certificate storage mounted as persistent volumes.

Before deploying a configuration, caddy validate can be used to verify the configuration, while caddy reload allows configuration changes to be applied without stopping the running server.

Final Verdict

Caddy is one of the strongest choices for administrators who want a modern web server and reverse proxy without spending significant time managing TLS certificates.

Its automatic HTTPS is the standout feature, but the software offers considerably more than certificate automation. HTTP/3, load balancing, health checks, static file serving, API-driven configuration, and a powerful module architecture make it capable of handling serious production workloads.

Its main weakness is complexity at the advanced end. Caddy is extremely approachable for simple deployments, but administrators who need highly customized routing and modular behavior will need to learn its underlying configuration architecture.

For new deployments, especially reverse proxies and HTTPS services, Caddy offers an excellent balance of simplicity, automation, and production capability.

Free

Download

Software Informations:
Developer:
ZeroSSL
Operating System:
Windows / macOS / Linux / BSD
Date Added:
2026-10-05T14:03:45.000Z
Categories:

Related to Caddy v2.11.7:

Post a Comment/Report Broken Link: