Follow us
Web Hosting

Caddy automatic HTTPS for teams moving away from Nginx

Caddy offers rapid deployment and automated TLS certificate management via Let's Encrypt. Benchmarks show Caddy maintains a 0.48ms response time for synthetic requests while providing a simpler configuration than Nginx.

Share

Rapid deployment and performance reality

I recommend Caddy for teams that prioritize fast deployment and reduced certificate management. In a benchmark with 200 concurrent clients, Caddy showed a 0.02ms response time penalty for synthetic responses compared to Nginx. Nginx handles more synthetic requests, yet Caddy performs similarly for most other request types. Caddy utilizes more CPU resources, reaching 300% utilization, whereas the Nginx default caps at 100% because its worker_processes defaults to one. Caddy also grabs about 40MB of memory at startup due to the Go runtime. While Nginx uses almost no memory, Caddy can utilize multiple cores, such as hitting 300% utilization on a 4-core machine.

Test Type Nginx (p95) Caddy (p95)
Synthetic 0.40ms 0.48ms
HTML Small 0.43ms 0.57ms
HTML Large 4.20ms 3.96ms
Proxy 0.92ms 1.04ms

I find that Caddy is the better choice for new cloud applications because it reduces day-one complexity.

Automated HTTPS and configuration logic

Caddy automates the TLS certificate lifecycle by using Let’s Encrypt or ZeroSSL. If you use any domain ending in .localhost, Caddy uses an auto-renewing self-signed certificate, but for any other domain name, Caddy attempts to get a publicly-trusted certificate from a provider via Let’s Encrypt or ZeroSSL. To proxy traffic to a backend service at 127.0.0.1:9000, the configuration requires only a single reverse_proxy line. If the configuration fails to load due to indentation errors, run caddy fmt –overwrite /etc/Caddyfile to correct the formatting. You should also note that Caddy handles the HTTP to HTTPS redirect automatically without any extra configuration. For those of you who have already mastered Nginx server blocks, does Caddy provide enough depth for complex path-based routing? While the reverse_proxy documentation notes that schemes cannot contain paths, you can use the handle directive to manage upstreams with different paths. To use Caddy as a reverse proxy, you must have Caddy in your PATH. If you need to bind to low ports on Linux, you should use the setcap command to give Caddy permission to do so.

Caddy provides several ways to manage upstreams. You can use a simple URL like http://localhost:4000 or a network address. If you need to proxy to a service via a Unix socket, you can use the unix/ prefix. For load balancing, Caddy includes a random policy by default. You can also use round_robin or least_conn to distribute traffic. If you use the cookie policy, Caddy adds a Set-Cookie header to the response to ensure client stickiness. If the hostname you are proxying to is different from the one you are proxying from, use the –change-host-header flag to reset the Host header. You can also use ip_hash or uri_hash to map requests to a specific upstream. For dynamic upstreams, you can use the SRV or A/AAAA DNS modules. These modules allow you to define a dial_timeout or refresh interval to keep the upstream list updated. If you use a port range, Caddy expands this to multiple upstreams with the same host.

Switching workflows and operational control

I find the decision between Caddy and Nginx comes down to a choice between simplicity and explicit control. Nginx requires a multi-step process to establish a secure environment, involving the installation of Certbot, the creation of server blocks, the configuration of proxy_pass, the forwarding of correct headers, and the monitoring of certificate renewal. Caddy simplifies this by making HTTPS the default behavior for any recognized hostname. Nginx remains the better choice for teams that need advanced routing, custom header behavior, or compatibility with legacy infrastructure. Caddy supports HTTP/2 and HTTP/3 without requiring the user to manually track version compatibility or update configuration files.

I would skip Caddy if your existing deployment scripts and playbooks depend heavily on Nginx’s specific operational patterns. I also find that Nginx users often prefer the explicit control it offers over the machinery of the server. Caddy optimizes for developer experience and operational simplicity. The choice between these two depends on which one your team can operate more safely and consistently. If you want to get a secure reverse proxy in front of an application today, Caddy wins.

Share

Technewsdaily

Senior tech writer covering AI, gadgets and cybersecurity. Breaking down the news that matters, every day.