Learning Caddy - History, Background & Why You Need Caddy

#Introduction

Before you write your first Caddyfile, it's important to understand why Caddy exists. Web servers aren't a new concept — Apache and NGINX have ruled the internet for decades. So what made Matt Holt go to the trouble of building a new web server in 2015?

The answer is simple: HTTPS. Securing a site with TLS certificates manually is painful — you have to buy a certificate, install it, configure renewal, and repeat every 90 days. Caddy was born to remove all of that complexity. It is the first web server to provide automatic HTTPS by default.

This episode 1 takes you through the history and background of Caddy, the advantages that set it apart, comparisons with competitors, and the use cases it fits best. This context will make the decisions in the upcoming episodes feel logical.

#The Evolution of Traditional Web Servers

#From Apache to NGINX

Apache dominated the early internet thanks to its flexibility: .htaccess, dynamic modules, and thorough documentation. But that flexibility came at a price — long .htaccess configurations and .conf files, plus a process-per-request model that was memory-hungry.

NGINX emerged as a challenger with an event-driven architecture that is far more resource-efficient and is often used as a reverse proxy in front of applications. The problem: configuring NGINX for HTTPS was still manual. You had to supply certificate files, write ssl_certificate blocks, set up HTTP-to-HTTPS redirects, and build a cron job for certificate renewal.

#Manual Certificate Management: The Real Problem

Beyond syntax complexity, the biggest problem with traditional web servers is manual certificate management. Every new site means a new certificate. Every expired certificate means a down site or a browser security warning. Automatic renewal was an expensive, complicated feature to configure.

The modern world needs more: many sites, fast deployments, multi-instance environments, and security that is encrypted by default, not optional.

#The Origins of Caddy

#Born from the Hands of Matt Holt

Caddy was created by Matt Holt and first released in 2015. The big idea was revolutionary: flip the convention — instead of HTTPS being something you configure, HTTPS became the default, automatic behavior. If you write a domain name in the Caddyfile, Caddy will obtain a certificate from Let's Encrypt with no extra steps.

Caddy is written in Go, a language known for high performance, concurrency, and compiling to a single static binary. The result: one binary file with no external dependencies that runs on almost any platform. Caddy is released under the Apache 2.0 license, fully open source.

#Developer-Centered Design

From the start, Caddy was designed for developers: human-readable configuration (the Caddyfile), seamless reloads with zero downtime, and an administrative API for dynamic configuration changes. All of this is built on a module system that allows extension without rewriting the core.

#Key Advantages of Caddy

#Automatic HTTPS and Zero-Configuration TLS

This is the flagship feature no other web server has out of the box:

• Integrated Let's Encrypt: certificates are obtained and renewed automatically.
• Automatic HTTP-to-HTTPS redirects with no configuration.
• OCSP stapling and certificate transparency handled for you.
• Automatic renewal 30 days before expiry, with zero downtime.

#The Human and Modern Caddyfile

Compare the minimal configuration block across different servers:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    root /var/www;
}

In Caddy, the entire block above is simply:

example.com {
    root * /var/www
    file_server
}

Notice: no certificate filenames, no port 443, no redirect block — everything is automatic. The caddy adapt command can convert a Caddyfile to JSON:

caddy adapt --config Caddyfile

#Other Modern Features

• HTTP/2 and HTTP/3 (QUIC) enabled automatically.
• Native reverse proxy for Node.js, PHP, or other applications.
• API-driven configuration through the admin API on port 2019.
• Single binary, cross-platform, with no dependencies.
• Graceful reloads that don't drop active connections.

#Caddy vs NGINX, Apache, and Traefik

#When to Choose Each

• Apache: choose it if you need .htaccess and a very old module ecosystem. In the modern world, this choice is increasingly rare.
• NGINX: very powerful and fast, but HTTPS is manual. A good fit if your team is already highly skilled with the NGINX ecosystem.
• Traefik: powerful for Kubernetes and Docker with automatic label discovery, but more complex configuration for single users.
• Caddy: choose it if you want drama-free automatic HTTPS, short configuration, and fast deployment for personal projects, homelabs, and small to medium production.

caddy run --config Caddyfile starts the server, and if something goes wrong, Caddy tells you with clear logs — not cryptic errors.

#Use Cases Caddy Fits Best

#Where Caddy Shines

• Static websites: portfolios, documentation, and landing pages.
• Reverse proxy: exposing Node.js, Python, or Go applications behind HTTPS.
• API gateway: forwarding requests to microservices with clean routing.
• File server: sharing files with simple authentication.
• Load balancer: distributing traffic across multiple backends with health checks.
• PHP applications: FastCGI integration with PHP-FPM.
• Homelab and personal projects: free HTTPS for your own domains.

#Conclusion

Episode 1 gave you the historical context: from the pain of manual HTTPS in Apache and NGINX, the birth of Caddy by Matt Holt in 2015 as the first web server with built-in automatic HTTPS, written in Go under the Apache 2.0 license, to the advantages of a concise Caddyfile and zero-downtime reloads.

Key takeaways:

• Traditional web servers manage TLS certificates manually, and it hurts.
• Caddy was born in 2015 by Matt Holt with the idea of HTTPS being automatic by default.
• Written in Go, a single binary, open source under Apache 2.0.
• The Caddyfile is far more concise than NGINX or Apache configuration.
• HTTP/2, HTTP/3, reverse proxy, and the admin API come built in.
• Caddy is best suited for automatic HTTPS, homelabs, and modern deployments.

In the next episode, episode 2, we'll dissect Caddy's architecture and core concepts — the HTTP server core, the module system, the request flow from listener to response, and the concepts of site address, directive, matcher, and handler, plus the four configuration methods available. This is the foundation we'll use throughout the series.