History & Evolution of Caddy #

Caddy wasn’t created just to be another alternative to established web servers like Nginx or Apache. The project was born as a direct response to a frustration developers and system operators had experienced for years: why did setting up HTTPS for a production website still require a long, error-prone, manual process with repeated intervention? Understanding Caddy’s history — from the initial idea, the architectural limitations of the first version, the licensing controversy, to the bold decision to rewrite the entire codebase — will help you understand why Caddy is designed so differently from traditional web servers.

Context: The Web Before Caddy (2015) #

To appreciate the innovation Caddy brought, we need to look back at the web server landscape around 2014–2015. At that time, web infrastructure was in the middle of a major transition toward mass adoption of SSL/TLS encryption for user security.

Back then, Nginx had become the de facto standard for high-performance web servers. But installing an SSL certificate on Nginx was entirely manual. You had to buy a certificate from a commercial Certificate Authority (CA) on a recurring basis at prices ranging from tens to hundreds of dollars per year, download the certificate files, copy them to the right server folder, configure the file paths inside the Nginx config, and make sure the port 80 config was properly moved to port 443. Every step was verbose and prone to typos.

Meanwhile, Apache still dominated the web server market, especially in shared hosting, thanks to the ease of local .htaccess config files and direct-execution modules like mod_php. Unfortunately, Apache’s process-based architecture was starting to struggle with modern traffic loads because it was extremely wasteful with RAM.

In late 2014, the Let’s Encrypt initiative was announced to provide SSL certificates for free. Let’s Encrypt entered public beta in November 2015. This was the opportunity Matt Holt, Caddy’s creator, seized. He thought: if SSL certificates could now be obtained for free through an open, standard protocol, why shouldn’t the web server integrate that process directly into its core code so it runs automatically?

The Birth of Caddy and Early ACME Integration (April 2015) #

Caddy was first introduced to the public by Matt Holt in April 2015. Matt was a software developer tired of the complexity of web server configuration and the SSL certificate maintenance that required renewal every few months. The basic idea was simple: a web server that enables HTTPS by default the moment it runs, configured with a minimalist syntax, and distributed as a single binary with no external dependencies.

Go was chosen as Caddy’s primary programming language because it offered several strategic advantages for systems software:

• Memory Safety: Eliminates an entire class of security vulnerabilities like buffer overflows that often plague C/C++ software.
• Easy Compilation: Compiles to a static single binary that needs no external runtime libraries on the target server.
• Natural Concurrency: Goroutines make it easy to efficiently manage thousands of parallel connections.

From its very first release, Caddy integrated an early implementation of the ACME protocol (Automated Certificate Management Environment), which was still a draft standard at the time. Through this open protocol, Caddy could talk directly to the Let’s Encrypt API to prove domain ownership, request SSL certificates, and install them on the web server without any human operator intervention.

Caddy’s initial launch was warmly received by the developer community, especially on platforms like Hacker News. At the same time, though, skepticism came from system engineers who doubted whether a web server written in Go could match the stability and memory efficiency of C-based servers like Nginx.

Caddy v1 (2015–2020): Proof of Concept and Licensing Controversy #

Over the next five years, the first version of Caddy (v1) grew rapidly from an experimental project into a tool relied upon in production by thousands of teams worldwide.

Caddy v1 proved that automatic HTTPS wasn’t just a nice-to-have feature, but a much-needed new standard. When Let’s Encrypt fully launched its service in April 2016, Caddy was the only web server ready to integrate it out of the box. Caddy also became one of the first web servers in the world to enable HTTP/2 by default on a wide scale.

1. The Commercial License Controversy (2017) #

In mid-2017, the Caddy project hit a critical moment that shook community trust. To sustainably fund this open-source project, Matt Holt introduced a new commercial licensing model. Under this model, the pre-compiled Caddy binary downloaded from the official Caddy website was subject to a license fee when used for commercial/business purposes. In addition, Caddy injected a custom HTTP header — Server: Caddy (Unlicensed) — into the free binary to encourage companies to pay for a license.

The model triggered a wave of strong protests from the open-source community. Many felt the move contradicted the spirit of free open-source software and polluted the cleanliness of HTTP responses. The community responded by creating several independent forks of Caddy and publishing guides on how to compile Caddy directly from source to avoid that custom header.

Aware of the negative impact on Caddy’s adoption, the development team eventually reversed this decision in 2018. The custom header was removed and all pre-compiled licensing was restored to fully open-source under the Apache 2.0 / MIT license. This valuable experience taught the Caddy team that community support is the project’s greatest asset.

2. v1 Architectural Limitations That Blocked Scalability #

As enterprise-scale usage grew, the fundamental architectural limitations of Caddy v1 became a major obstacle:

• No API for Dynamic Configuration: Caddy v1 configuration was entirely based on reading physical Caddyfile files at server startup. To add a new domain in production, you had to manually edit the text file and then send a reload signal (SIGUSR1) to the Caddy process. Repeated reloads on a server with thousands of domains caused massive CPU overhead.
• Rigid Plugin Compilation Model: Plugins in Caddy v1 had to be statically linked into the Caddy core during source compilation. Users needing extra plugins had to download a specially pre-compiled binary from the Caddy website or compile it themselves using a Go compiler on their local machine.
• Tightly Coupled Code Structure: Caddy v1’s web server core was designed to be tightly fused with the Caddyfile format. This made it impossible to integrate Caddy programmatically with other modern structured data formats (like JSON or YAML).

The Total Rewrite Decision #

In late 2018, Matt Holt and the Caddy core team realized that the structural problems of the first version couldn’t be solved with incremental patches. Caddy needed an entirely new architectural foundation oriented toward dynamic infrastructure.

This is where the development team took a bold and controversial step: rewriting Caddy from scratch without preserving backward compatibility with the first version. The decision raised concerns among loyal Caddy v1 users because of the potential for significant configuration syntax changes when migrating to Caddy v2. However, the team convinced the community that this step was essential for Caddy’s long-term survival.

Caddy v2 (May 2020): API-First Architecture #

After a long development and beta-testing period of nearly two years, Caddy v2 was officially released in May 2020. The new version brought radical architectural changes, positioning Caddy not just as an ordinary web server but as a highly reliable dynamic configuration platform.

1. JSON as the Primary Internal Representation #

In Caddy v2, all web server configuration is represented as standardized JSON data structures in memory. The Caddyfile you’re used to is actually just an external adapter that translates the developer-friendly syntax into an internal JSON config before the Caddy core engine runs it.

# Translate a Caddyfile configuration into internal JSON
caddy adapt --config /etc/caddy/Caddyfile --adapter caddyfile

This model opened up endless possibilities: third-party developers could now write their own Config Adapters so Caddy could read configuration from other formats like YAML, TOML, or even translate Nginx configs directly.

2. REST Admin API Architecture #

Because Caddy’s internal configuration was now JSON, Caddy v2 ships a built-in REST Admin API on port 2019. This lets you modify routing rules in real time without touching files on disk and without forcing a hard restart of the server process.

flowchart TD
    A["Application / DevOps Controller"] -->|"HTTP POST JSON"| B["REST Admin API (Port 2019)"]
    B --> C["Caddy Engine (Memory Config Updates)"]
    C --> D["Instant Hot-Swap (Without Dropping Connections)"]
    C --> E["ACME Certificate Manager (Async SSL Issuance)"]

    style B stroke:#0288d1,stroke-width:2px
    style C stroke:#43a047,stroke-width:2px

Configuration changes are validated by the Caddy engine first. If valid, the new module is initialized in memory, and traffic connections are moved to the new module instantly (hot-swap), while the old, no-longer-used module is shut down cleanly.

3. The Module System and xcaddy #

Every feature in Caddy v2 is implemented as an independent module that registers itself with the Caddy core engine. This makes Caddy highly modular and extensible without compromising the stability of the main system.

To simplify plugin management, the Caddy team introduced xcaddy, an official command-line tool that automates compiling a Caddy binary with external modules:

# Compile Caddy with the Cloudflare DNS plugin
xcaddy build --with github.com/caddy-dns/cloudflare

Caddy Development Timeline #

Caddy’s journey from its beginnings to today can be summarized in the following timeline table:

Key Lessons from Caddy’s Evolution #

There are several valuable lessons to draw from Caddy’s years of development and evolution:

• Security Should Be the Default: Caddy’s decision to make automatic HTTPS a core feature — not an add-on module — proved to change how the industry views the security standard of a website.
• The Courage to Break Compatibility: Sometimes, to produce a mature, sustainable software architecture, a team must be willing to make breaking changes and redesign the system from scratch rather than preserve fragile legacy code.
• API-First Design: Making JSON and a REST API the foundation of configuration proved to open infrastructure automation integration opportunities far beyond what traditional web servers can do.

Caddy Today #

Today, Caddy is widely recognized as one of the world’s leading web servers, used by large companies to handle millions of requests every day. Go’s reputation as an efficient, memory-leak-safe language has proven to be a very solid foundation for Caddy’s stability in enterprise environments.

Caddy’s success has also contributed greatly to the standardization of HTTPS across the internet. Many developers who switched to Caddy say the operational time saved from SSL server maintenance can now be redirected to more productive application feature development.

Caddy v1 is end-of-life and no longer receives security updates. If you’re still on v1, migrating to v2 is strongly recommended. The migration guide is available in the official documentation at caddyserver.com/v2-upgrade.

Summary #

• Born in 2015 — Caddy was created by Matt Holt to solve the pain of manual HTTPS setup developers faced before the era of SSL certificate automation.
• Caddy v1’s Limitations — Although it proved the concept of automatic HTTPS, the first version had architectural limitations like the lack of a dynamic API and a rigid plugin system.
• Total v2 Rewrite (2020) — The Caddy team decided to rewrite the code from scratch to adopt native JSON-based configuration and a REST Admin API on port 2019.
• xcaddy Standardization — The official compilation tool that automates adding third-party modules easily and consistently.
• Today’s Status — Caddy v1 has been declared End-of-Life (EOL). All new deployments must use Caddy v2, which continues to receive performance and security feature updates.

← Previous: What is Caddy?   Next: Caddy vs Nginx →