Caddy

What Is Caddy?

Caddy is a modern, open-source web server written in Go, best known for enabling HTTPS automatically by default. Where traditional servers require you to obtain, install, and renew TLS certificates yourself, Caddy provisions and renews certificates from Let's Encrypt (or another ACME certificate authority) on its own, with no manual steps. That single feature, automatic HTTPS out of the box, is the reason Caddy earned a devoted following and reshaped expectations for how easy a production web server should be to run.

Caddy was created by Matt Holt and first released in 2015. It is fully open source under the Apache 2.0 license and is widely regarded as one of the easiest production-grade web servers to configure, especially for developers who want a secure site running quickly without becoming a TLS expert. While Nginx and Apache remain far more common across the web as a whole, Caddy has carved out a strong niche among modern self-hosters, container deployments, and small-to-mid-size projects that value simplicity and secure-by-default behavior.

It is important to place Caddy correctly among its peers. It belongs to the same family as Nginx, Apache, LiteSpeed, and other web servers: software that listens for HTTP requests and returns responses, serves static files, and reverse-proxies traffic to application back ends. What distinguishes Caddy is its philosophy. It treats automatic HTTPS, sane defaults, and a clean configuration file as first-class features rather than add-ons, and it ships as a single self-contained binary with no external dependencies because it is compiled from Go. That packaging makes it especially friendly for containers and for anyone who wants to avoid the dependency management that other servers can require.

Caddy is server software you run yourself, not a hosted service or a browser tool. It sits on your infrastructure, in front of your application, and shapes how requests are handled and how the site is delivered over the network. Because it is the component that actually answers HTTP requests, its presence and behavior show up in the response headers a site returns, which is precisely where you look to detect it.

How Caddy Works

Caddy's defining behavior is automatic HTTPS. On startup, for any site you configure with a public domain name, Caddy contacts an ACME certificate authority, completes a challenge to prove you control the domain, obtains a TLS certificate, and installs it. It then keeps the certificate renewed automatically before it expires and redirects HTTP traffic to HTTPS. The practical effect is that you can stand up a fully encrypted site by specifying little more than a domain name and a destination, and Caddy handles the cryptographic plumbing that other servers leave to the administrator.

Configuration is famously concise. Caddy reads a file called a Caddyfile, whose syntax is deliberately minimal: you write a site address and a small block of directives, and Caddy fills in secure defaults for everything you do not specify. A complete configuration to serve a static site or reverse-proxy an application can be just a few lines. For programmatic control, Caddy also exposes a JSON configuration API and can be reconfigured at runtime without a restart, which suits automated and containerized environments.

Functionally, Caddy does what you expect of a modern web server and more. It serves static files efficiently, acts as a reverse proxy and load balancer in front of application servers, terminates TLS, supports HTTP/2 and HTTP/3 (QUIC), compresses responses, rewrites and redirects URLs, and enforces access control. Its capabilities are organized as modules, and the broader project allows building custom Caddy binaries with additional plugins compiled in, so the same core can be extended for specialized needs.

A typical deployment looks like this: Caddy runs as the public-facing server, listening on ports 80 and 443. Requests arrive, Caddy terminates TLS using a certificate it obtained automatically, applies any routing or rewriting rules from the Caddyfile, and either serves files from disk or forwards the request to an upstream application such as a Node.js, Python, PHP-FPM, or Go service. Responses flow back through Caddy to the client, often compressed and over HTTP/2 or HTTP/3. Because Caddy is a single Go binary, this entire role is filled by one lightweight process that is simple to deploy in a container or on a bare server.

That single-binary, secure-by-default design is the throughline of the whole project. It is why Caddy is popular for personal projects, internal tools, and modern microservice stacks, and it is also why Caddy's signature appears so cleanly in the headers a site sends back.

How to Tell if a Website Uses Caddy

The most reliable way to detect a web server like Caddy is to examine the HTTP response headers a site returns, because the server is the component generating those headers. StackOptic inspects these from the server side, and you can check the same signals with curl or your browser's DevTools.

The Server response header. By default, Caddy identifies itself in the Server HTTP response header with the value Caddy. Running curl -I against a site and seeing Server: Caddy is the single clearest indicator that Caddy is the web server. This is the same mechanism that reveals nginx or Apache on other sites.

HTTP/3 and modern protocol support. Caddy enables HTTP/3 (QUIC) readily, and sites fronted by Caddy frequently advertise it via an Alt-Svc response header offering an h3 endpoint. While not unique to Caddy, seeing modern protocol support alongside other clues reinforces the conclusion.

Automatic, valid HTTPS with sensible defaults. Because Caddy provisions TLS automatically, Caddy-served sites essentially always present a valid certificate and redirect HTTP to HTTPS. On its own this is circumstantial, but combined with a Server: Caddy header it fits the platform's profile.

Default error and response behavior. Caddy's default responses and headers follow recognizable patterns. When the Server header has not been customized, these defaults align with what you would expect from a Caddy instance.

Here is how to check each signal yourself:

Method	What to do	What Caddy reveals
curl -I	curl -I https://example.com	Server: Caddy header; often an Alt-Svc header advertising HTTP/3
Browser DevTools	Open the Network tab, click the document request, view Response Headers	The Server value and protocol/Alt-Svc details
Online header tools	Paste the URL into an HTTP header inspector	The Server header reported for the site
Wappalyzer	Run the extension on the live page	Identifies "Caddy" under web servers when the header is present
BuiltWith	Look up the domain	Server software detection where headers expose it

The fastest check is curl -sI https://example.com | grep -i server. If it returns Server: Caddy, you have your answer. For deeper methodology, see our guides on how to find out what server software a website runs and how to read a website's HTTP headers.

There is one important honesty caveat with any server detection: headers can be hidden or changed, and intermediaries can mask the origin. Caddy lets administrators override or remove the Server header, so a security-conscious operator may strip it or set a custom value, in which case the most obvious tell disappears. More commonly, a site sits behind a CDN or reverse proxy such as Cloudflare, and the Server header you see reflects that edge layer rather than the Caddy instance running at the origin. In other words, a CDN masks the origin server, so the absence of Server: Caddy does not prove Caddy is not in use, and the presence of a CDN header tells you about the edge, not the back end. This is why detecting the underlying server is inherently less certain than detecting a CMS or a JavaScript framework, and why combining signals matters. Our guide on how to tell if a website uses Cloudflare or another CDN explains how to recognize when an edge layer is sitting in front of the real origin. When a site is not behind a CDN and has not customized its headers, however, Server: Caddy is a clean, direct confirmation.

Key Features

• Automatic HTTPS by default. Provisions and renews TLS certificates from ACME authorities like Let's Encrypt with no manual steps, and redirects HTTP to HTTPS automatically.
• Minimal Caddyfile configuration. A concise, human-friendly config format with secure defaults, plus a JSON API for programmatic and runtime configuration.
• Single Go binary. No external dependencies, which makes deployment and containerization straightforward.
• Reverse proxy and load balancing. Built-in proxying to application back ends with health checks and load-balancing policies.
• Modern protocols. Native HTTP/2 and HTTP/3 (QUIC) support out of the box.
• Extensible module system. Custom builds can compile in plugins for additional functionality.
• Static file serving and compression. Efficient delivery of static assets with on-the-fly compression and flexible rewrites and redirects.

Pros and Cons

Pros

• Easiest path to fully automatic, always-valid HTTPS of any mainstream server.
• Extremely concise configuration with safe defaults that reduce misconfiguration risk.
• Single self-contained binary that is simple to deploy and ideal for containers.
• Modern protocol support and a clean, actively maintained Go codebase.

Cons

• Smaller ecosystem and community than Nginx or Apache, with fewer tutorials and third-party guides.
• Less battle-tested at the very largest scales than the long-established incumbents.
• Some advanced or niche features require building a custom binary with plugins.
• A smaller pool of engineers with deep Caddy-specific operational experience.

Caddy vs Alternatives

Caddy competes with other web servers and reverse proxies. The table below highlights where it fits relative to the most common options.

Server	Configuration	HTTPS	Best for
Caddy	Minimal Caddyfile / JSON API	Automatic by default	Modern projects, containers, easy secure-by-default hosting
Nginx	Detailed config files	Manual or via tooling	High-traffic sites, fine-grained tuning, huge ecosystem
Apache	.htaccess and config files	Manual or via tooling	Traditional and shared hosting, broad module support
LiteSpeed	Apache-compatible config	Manual or via tooling	Performance-focused hosting, drop-in Apache replacement
Traefik	Label/dynamic config	Automatic via ACME	Dynamic container and Kubernetes environments

If a site is not running Caddy, the same header inspection reveals the actual server. You can also consider how the server relates to broader infrastructure choices like managed platforms; see Cloudflare for how an edge layer changes what the headers show.

Use Cases

Caddy is a natural fit wherever simplicity and secure-by-default behavior are priorities. Developers reach for it to get a personal site, blog, or portfolio online over HTTPS in minutes without learning certificate management. It is popular for self-hosted applications and home labs, where a single binary and a three-line Caddyfile replace a tangle of certificate scripts and verbose configuration.

It also suits containerized and microservice deployments, where Caddy serves as a lightweight reverse proxy and TLS terminator in front of application services, and small-to-mid-size production sites that want modern protocols and automatic HTTPS without operational overhead. For startups and indie developers, Caddy reduces the time from code to a secure, public endpoint, which is why it appears frequently in modern, developer-driven stacks.

A few concrete patterns recur. A solo developer might run Caddy on a single virtual server, reverse-proxying to a Node.js or Python application while Caddy handles TLS and HTTP/3 automatically. A team shipping microservices in containers might use Caddy as the ingress that terminates TLS and routes requests to internal services, reconfiguring it on the fly through its JSON API. A hobbyist self-hosting a handful of applications at home might point Caddy at each one and never think about certificates again. The common thread is a desire to remove the friction and risk of manual HTTPS while keeping a clean, readable configuration.

From a technology-research perspective, detecting Caddy on a site is a useful signal about the team behind it. It often indicates a modern, developer-led operation that values simplicity and current best practices, as opposed to a legacy stack on traditional shared hosting. For vendors and analysts profiling a prospect's infrastructure, that context, surfaced quickly across many domains by an automated scan, helps distinguish modern self-managed deployments from older or fully managed ones.

Frequently Asked Questions

What makes Caddy different from Nginx and Apache?

The headline difference is automatic HTTPS. Caddy obtains and renews TLS certificates by itself with no configuration, whereas Nginx and Apache require you to set up certificates and renewal separately. Caddy also uses a far more concise configuration file with secure defaults and ships as a single dependency-free Go binary. Nginx and Apache are more established, have larger ecosystems, and offer extremely granular tuning, but they ask more of the administrator to reach the same secure baseline.

How do I check if a website is running Caddy?

Inspect the HTTP response headers. Run curl -I https://example.com (or open DevTools, Network tab, and view the document's response headers) and look for Server: Caddy. That header is Caddy's default self-identification and is the clearest sign. Detection tools like Wappalyzer and BuiltWith also report Caddy when the header is exposed. Keep in mind the header can be hidden, and a CDN in front of the site may replace it.

Can the Server: Caddy header be hidden?

Yes. Caddy allows administrators to override or remove the Server header, so a hardened deployment may not advertise itself. Additionally, if the site sits behind a CDN or reverse proxy, the Server header you see typically reflects that edge layer rather than the Caddy origin. Because of this, the absence of Server: Caddy does not rule Caddy out. Server detection is inherently less certain than detecting a CMS, which is why combining multiple signals is best practice.

Is Caddy free and open source?

Yes. Caddy is open source under the Apache 2.0 license and free to download and run. Anyone can use it in personal or commercial projects without licensing fees, inspect its source, and build custom versions with additional plugins. The project is actively maintained, and there are commercial offerings and support options in the broader ecosystem, but the core server itself is free and open.

Does Caddy support HTTP/3?

Yes. Caddy supports modern protocols including HTTP/2 and HTTP/3 (QUIC) out of the box. Sites served by Caddy often advertise HTTP/3 availability through an Alt-Svc response header that points clients to an h3 endpoint. This modern protocol support, combined with automatic HTTPS, is part of Caddy's secure-and-current-by-default philosophy and a useful corroborating signal when you are trying to identify the server.

Curious which web server, CDN, and platform a given site uses? Analyze any URL with StackOptic at https://stackoptic.com.