Show HN: Caddy 2

blog image

All-new core ✨

After 14 months of redesign, Caddy 2 has a whole new architecture inspired by 5 years of experience and feedback from v1.

Fewer moving parts ⚙️

Caddy saves money, increases developer productivity, and reduces problems in production.

A whole new server experience

Play screencast to see Caddy serve HTTPS in < 1 minute.

Caddy is “really fun to use” and helps make complex deployments simpler. Your Caddy site will have fewer moving parts which lowers costs, increases productivity, and improves reliability.

Use Caddy’s native JSON configuration to customize every inch of your server, or use the Caddyfile to stand up a production site in just a few easy lines.

With Caddy, HTTPS just works; and you can configure and deploy your site in more ways than you ever thought possible. The days of hacking your deployment workflows around the limitations of your web server are over!

HTTPS quick-start
 
Upgrade guide

More than just a web server

Caddy 2 is a highly extensible, self-hosted platform on which you can build, configure, and deploy long-running services (“apps”).

Caddy ships with apps for an HTTPS server (static files, reverse proxing, load balancing, etc.), TLS certificate manager, and fully-managed internal PKI. Caddy apps collaborate to make complex infrastructure just work with fewer moving parts.

For example, the config shown here keeps your TLS certificates renewed for other programs to use; no external tools or HTTP daemon required!

Providing a unified configuration, on-line config API, and automatic documentation for all apps, Caddy is nearly infinitely extensible. Thanks to its unique modular architecture, we can offer unlimited features without bloating the code base.

{
"apps": {
"tls": {
"certificates": {
"automate": [
"example.com",
"example.net"
]
}
}
}
}

Thank you

API Layer
Ardan Labs
Smallstep


As I feel our contributors and sponsors do not get enough recognition or appreciation, allow me to interrupt this release announcement with a personal, open letter to the above named…

If you’re reading this: thank you. You were the primary collaborators on Caddy 2, and this would not have been possible without you. You gave Caddy new distribution packages, containers, docs, features, field testing; and helped countless users. I think almost no topic in our community forums has gone unanswered. That’s truly amazing!

Thanks for sticking with the project and believing in it enough to yield a second version. We’ve solved some hard problems together—usually during nights and weekends—and in days of isolation during this pandemic, no less.

Now look at what we have made! Caddy is the only server that grants privacy to its sites’ visitors by default. We’ve raised the bar for the rest of the Web. I hope you are as pleased with our results as I am. Millions more people will soon benefit from your contributions.

– Matt

Twenty
beta versions

Thousands
of businesses

Millions
of production hours

Billions
of connections secured

Trillions
of requests served

Caddy 2 is production-ready. It is already serving thousands of sites for businesses and has an unparalleled reliability record in the face of external factors that negatively affect HTTPS uptime. Caddy stays up when other servers let you down.

Try your current server with tens of thousands of sites and certificates, then try them with Caddy – you’ll see what we mean.

Deploy with Docker
 
Deploy on DigitalOcean

Familiar Caddyfile, now even better

caddyserver.com

root * src

file_server
templates
encode zstd gzip

redir /docs/json /docs/json/
rewrite /docs/json/* /docs/json/index.html
rewrite /docs/* /docs/index.html

reverse_proxy /api/* localhost:9002

Actual config used by this site.

Config API for dynamic, on-line updates

Caddy is configured through an intuitive REST API that offers ACID guarantees:

  • Atomic: Multiple changes in a single request are treated as a single unit; any failed change aborts all the other changes.
  • Consistent: No invalid configurations can be loaded; your server will never break if a problem is detected at config load.
  • Isolated: No config changes rely on another. (It helps that HTTP is a stateless protocol!)
  • Durable: Caddy automatically persists the current, valid configuration to disk and can safely resume it after a power cycle if the --resume flag is used.

In addition, Caddy’s API is safely scoped, meaning the URI path restricts changes, making it impossible to accidentally alter other parts of your config.

API tutorial
 
API reference

$ caddy start --config caddy.json

$ curl localhost:2019/id/my_handler
-X PATCH
-H "Content-Type: application/json"
-d '{
"handler": "static_response",
"body": "Work smarter, not harder."
}'

$ curl localhost:2019/config/ | jq

Powered by … nginx.conf? 🤔

$ caddy run
--config nginx.conf
--adapter nginx

Sure, why not!

With first-class support for config adaptation, you can use whatever configuration language you prefer, such as NGINX config files! Several other config adapters are already available, including JSONC, JSON5, YAML, and CUE.

Our NGINX adapter is still a work in progress, but for some of you Caddy could be a drop-in replacement upgrade for NGINX, with memory safety!

Config adapters

Every site on HTTPS – including local and internal sites

Caddy has always been known for serving sites over HTTPS by default, and now we’re extending that to internal and local development sites, too.

Powered by open source Smallstep libraries, Caddy automatically acts as a fully-featured, self-hosted CA when necessary. If you configure sites with local or internal addresses (e.g. localhost or IP addresses), Caddy will still serve them over HTTPS using its locally-trusted certificate authority with short-lived, auto-renewing certificates. This makes it easy to mimic production environments in dev!

Smallstep

192.168.1.10 {
respond "Hello from HTTPS!"
}

http://localhost {
respond "Plain HTTP"
}

We fixed all known limitations of v1

With an all-new architecture, the development of Caddy 2 closed about 400 issues and solved all known limitations on Caddy 1 caused by fundamental design constraints.

Caddy 2 is designed to be highly flexible when needed, but also highly focused on its core competency. If there was anything in Caddy 1 that felt out of place or hacky, it won’t in v2.

This design was an incredible undertaking: of the approximate 14 months spent developing Caddy 2, only about 7 of them actually consisted of writing code; the other half was solely focused on the design of the underlying architecture.

Keeps your sites online when other servers… don’t

Caddy has the most robust TLS stack on the market. With stronger memory safety guarantees than OpenSSL (Apache & NGINX) and more advanced certificate automation logic than any other server or utility, Caddy keeps your sites online through problems that other servers don’t handle.

Advanced TLS automation

Caddy was the first server to fully automate public certificate management—so we’ve been doing this longer than anyone. With more than 5 million certificates under management, Caddy has set the gold standard for other servers to live up to:

  • Async management. Certificate automation never blocks the main thread of the web server.
  • Gentle retries. Failed validation attempts are retried with exponential backoff for up to 1 month. They don’t count against normal rate limits; Caddy uses staging/test endpoints during retries.
  • OCSP stapling and caching. Caddy staples OCSP to all qualifying certificates and keeps them conservatively fresh. It even caches them to disk in case of extended OCSP responder outages.
  • Auto-replace after revocation. If the latest OCSP staple indicates a revocation, Caddy automatically replaces the revoked certificate with a new one.
  • Storage pre-checks. Before attempting costly or valuable ACME transactions, Caddy checks to ensure its storage space is sufficient and writeable.
  • Internal throttling and job scheduling. Give Caddy a million certs to manage: no problem, it will gracefully manage them as fast as it can without hammering the CA or duplicating jobs over a long period of time.
  • TLS session ticket key rotation. Caddy automatically rotates TLS 1.2 session ticket keys for better privacy. It can even do this across a cluster!
  • Fleet coordination. All Caddy instances configured for the same storage backend will automatically share certificate and coordinate management in its cluster.

Real-life examples

In 2018, several popular sites went down for many users of mainstream clients because crucial OCSP infrastructure had an extended outage. Only Caddy staples and caches OCSP responses by default, so all Caddy sites were unaffected.

More recently in 2020, a mass certificate revocation event left many sysadmins scrambling to renew their certificates ahead of schedule. Caddy automatically renews certificates that get revoked, and all Caddy sites were unaffected.

Companies have deployed Caddy in front of their site just hours before important audits—potentially saving their compliance status—because of Caddy’s safe defaults and “batteries included” approach.

Recommended by experts

“TLS must be enabled by default … and the Caddy web server is a good and usable example.”   —Krombholz et al., USENIX 2017

“Caddy is impressive. This is what we want, setting up a secure website.”   —Josh Aas, Executive Director, Let’s Encrypt

“No popular server software does [session ticket key rotation], with the exception of Caddy.”   —Springall et al., ACM IMC 2016

Read More