caddy

Caddy is an open-source web server and reverse proxy for hosting websites and exposing applications over HTTPS. Written in Go, it serves static files, forwards requests to backend services, and manages TLS certificates automatically, making it useful for Linux administrators who want to reduce routine certificate work.

Its main appeal is how little configuration a common deployment can need. A Caddyfile describes the site's address and the features it uses; Caddy handles certificate issuance, renewal, and HTTP-to-HTTPS redirects for qualifying sites. That makes it a practical choice for self-hosted applications, small websites, and services that need an HTTPS entry point.

What Caddy can do

• Automatic HTTPS: Caddy obtains and renews certificates for public domain names through ACME certificate authorities such as Let's Encrypt or ZeroSSL. It can also provide HTTPS for local services using its own certificate authority, although client devices must trust that authority.
• Reverse proxying: Route requests to one or more backend applications, including services running on local ports. Configurable load balancing and health checks help manage multiple application instances.
• Static file hosting: Serve a website's HTML, images, and other files directly, with optional directory listings. File serving and proxy routes can coexist in the same configuration.
• PHP integration: The php_fastcgi directive forwards requests to a PHP FastCGI server such as PHP-FPM. It provides a shortcut for common PHP application routing; the PHP runtime remains a separate service.
• Modern HTTP support: Caddy supports HTTP/1.1, HTTP/2, and HTTP/3. The protocol a client actually uses depends on client support and the network path.
• Configuration for people and automation: Use the Caddyfile for manually maintained setups or native JSON for more detailed control. The administration API can load configuration changes without stopping the server.

For example, a Caddyfile site block with a domain name and a reverse_proxy directive can put an existing application behind HTTPS. The important distinction is that certificate management belongs to the same server configuration as request routing, so there is less separate certificate tooling to coordinate.

Where Caddy fits

Caddy suits administrators who value concise configuration and automated certificate maintenance. Its Caddyfile offers an approachable starting point, while JSON and the API support more elaborate deployments.

Automatic HTTPS still depends on a working deployment. For the usual public-domain setup, DNS must point to the server, validation traffic must reach Caddy, and its certificate data directory must remain writable and persistent. Local HTTPS requires distributing trust in Caddy's root certificate to the relevant clients.

Caddy, NGINX, Apache, or lighttpd?

All four can host websites and connect to applications, but their strongest reasons for choosing them differ.

Caddy: automatic HTTPS and concise configuration. Caddy combines certificate issuance, renewal, HTTPS redirects, and request routing in one server. Its Caddyfile makes common static-site and reverse-proxy setups compact. It is a strong fit for self-hosted services when reducing certificate administration is a priority.

NGINX: proxying, caching, and traffic distribution. NGINX combines reverse proxying with a built-in content cache and load balancing. It is particularly useful as a front end for several application servers, where serving cached responses can reduce requests reaching the application. Its event-driven architecture is designed to handle many connections with a small number of worker processes.

Apache HTTP Server (httpd): flexible modules and per-directory control. Apache stands out when a site needs specific Apache modules or relies on .htaccess files. Where enabled, these let site maintainers adjust selected rules without changing the main server configuration, which is useful on shared hosting. Administrators with full server access can keep those rules in the main configuration to avoid the extra filesystem checks.

lighttpd: a focus on low resource use. lighttpd emphasizes a small memory footprint while providing static file serving, FastCGI, URL rewriting, and compression. It is worth considering for a small server or appliance where memory is constrained and those capabilities cover the workload. Actual resource use depends on the configuration and application, so benchmark the intended setup before making a capacity decision.