Hubbry Logo
Caddy (web server)Caddy (web server)Main
Open search
Caddy (web server)
Community hub
Caddy (web server)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Caddy (web server)
Caddy (web server)
Caddy (web server)
View on Wikipedia
from Wikipedia
Caddy
Original authorMatthew Holt
Initial release28 April 2015; 10 years ago (2015-04-28)
Stable release
2.10.2[1] Edit this on Wikidata / 23 August 2025; 2 months ago (23 August 2025)
Repositorygithub.com/caddyserver/caddy
Written inGo[2]
Operating systemBSD variants, Linux, Plan 9, macOS and Windows
PlatformIA-32 (i386), x86-64, ARM, MIPS, S390X
TypeWeb server, reverse proxy server
LicenseApache 2
Websitecaddyserver.com Edit this at Wikidata

Caddy is an extensible, cross-platform, open-source web server written in Go.

The name "Caddy" refers both to a helper for tedious tasks, and a way to organize multiple parts into a simplified system.[3] At its core, Caddy is an extensible platform for deploying long-running services ("apps") using a single, unified configuration that can be updated on-line with a REST API.[4] Official Caddy distributions ship with a set of standard modules which include HTTP server, TLS automation, and PKI apps.[5] It is best known for its automatic HTTPS features.[6][7]

Architecture

[edit]

Caddy is organized into three main components: a command, the core library, and configuration modules.[8] The command is the extensible interface by which the program is executed; it can also load configuration files, run common modes, manage installed plugins, and offer relevant utility functions. The core library has APIs for loading, unloading, and managing configuration;[9] but it does nothing particularly useful on its own. Most of Caddy's functionality is provided by modules, which are plugins that extend Caddy's configuration structure; for example, the HTTP server is a module.[10] Caddy modules implement various long-running services, web standards, and other useful features.

Caddy's input is a JSON configuration document[11] which is received through an open socket via a RESTful HTTP API.[12][6] In the absence of an HTTP client, Caddy's command-line interface can be used to load configuration files.[13] Config adapters may be used to convert other configuration formats to JSON. Existing adapters include the Caddyfile, which has first-class support in the command line; and YAML, TOML, Nginx, and several other formats.[14][6]

When a configuration is received through its administration socket, Caddy decodes the configuration for all the specified modules, and starts running all the app modules.[6] When the app modules are being provisioned, they themselves may load and provision modules that they use. For example, the HTTP server is an app module which uses HTTP handler modules to handle HTTP requests; these handlers might use yet other modules to implement their functionality, and so on.[15] All these modules are provisioned during the config load phase.[8]

Plugins are installed by statically compiling them directly into the Caddy binary.[3][6] Without plugins, Caddy's native configuration structure only has some basic options for administration and logging.[11] All other functionality must be provided by app modules. Official Caddy distributions ship with dozens of standard modules;[5] others can be added from the project's website,[16] using the xcaddy command line tool, or by manually compiling a custom build.[17][18]

HTTP server

[edit]

The HTTP server is an app module that comes standard with official Caddy distributions.[10] It is primarily used as a static file server[19] and load-balancing reverse proxy.[20] While the basis of Caddy's HTTP features use the implementation found in Go's standard library,[21] a variety enhancements and customizations are available as middleware and exposed through configuration parameters:[6]

Automatic HTTPS

[edit]

By default, TLS is used automatically if any routes have a non-empty host matcher.[22] These are assumed to be site names or IP addresses that Caddy is serving, so Caddy will automatically procure and renew certificates for the configured hostnames and IP addresses. When automatic HTTPS is activated in this manner, Caddy will also redirect HTTP requests to their equivalent HTTPS location.[23]

To automatically acquire the TLS certificates, Caddy implements the Automatic Certificate Management Environment protocol, allowing it to communicate with services like Let's Encrypt.[24]

Development

[edit]

The first git commit in the Caddy project was in 2014.[25]

Caddy version 1.0 was released on the 24th of April, 2019.[25] At that point, the project had over 250 contributors.[25]

Caddy version 2 was released on May 5, 2020.[7] Reviewers from Ars Technica say that it still has a simpler configuration file syntax than the Apache Web Server, although version 2's configuration format is largely incompatible with the previous major release of Caddy.[7][26]

Derivatives

[edit]

- CoreDNS, a project of the Cloud Native Computing Foundation. [27]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Caddy (web server)

View on Grokipedia
from Grokipedia
Caddy is an open-source, extensible web server written in the Go programming language, designed primarily for serving HTTP traffic with automatic enabled by default. Developed by Matthew Holt and first released in 2015, Caddy innovated by integrating seamless TLS certificate management using ACME protocols like , allowing users to serve secure websites without manual configuration of SSL/TLS settings. At its core, Caddy functions as a configuration manager that orchestrates various modules, including an HTTP server supporting versions 1.1, 2, and 3, capabilities, and for long-running applications. Its modular architecture enables easy extension through plugins, making it suitable for diverse use cases such as static file serving, gateways, and load balancing, all while compiling to a single binary with no external dependencies for cross-platform deployment on , Windows, macOS, and more. The server emphasizes simplicity and security, with features like on-the-fly compression (including Zstandard support), customizable logging, and compliance with standards such as PCI DSS and HIPAA through enforced , even for traffic. Caddy's configuration is developer-friendly, primarily via the human-readable Caddyfile syntax that abstracts complex structures, though it also supports direct input and runtime updates through a RESTful API for zero-downtime changes. Since its inception, the project has grown through community contributions, serving trillions of requests and managing over 50 million certificates globally as of 2025, and was acquired by Apilayer in (now a project of ZeroSSL, under Stack Holdings) to further its enterprise adoption. Later versions of Caddy 2, such as 2.10 (released in 2025), have introduced advanced capabilities like Encrypted ClientHello (ECH) and support, solidifying its role as a modern alternative to traditional servers like or .

Introduction

Overview

Caddy is an open-source, extensible and that supports HTTP/1.1, , and protocols, written in programming language, and designed for simplicity, ease of use, and automation in deployment. It primarily serves static files, acts as a for backend applications, and automatically manages TLS certificates to enable secure connections without manual configuration. Key differentiators include automatic HTTPS enabled by default through integration with for certificate issuance and renewal, single-binary distribution for straightforward installation, and cross-platform compatibility across , Windows, macOS, and other operating systems. Initially released in 2015 by developer Matthew Holt, the current stable version as of November 2025 is v2.10.2. Caddy's modular allows integration of applications such as its HTTP server and certificate manager for customized functionality.

History

Caddy was founded in 2015 by Matthew Holt as a straightforward alternative to established web servers like Nginx and Apache, prioritizing automatic HTTPS through seamless certificate provisioning and management. The project's initial prototype emerged from an early commit on January 13, 2015, introducing foundational elements such as the Caddyfile configuration format and a modular plugin architecture in approximately 1,300 lines of code. The first public release followed on April 28, 2015, marking Caddy's debut as an open-source web server written in the Go programming language for enhanced performance and simplicity. From its inception, Caddy has been distributed under the permissive Apache 2.0 license, enabling broad adoption without restrictive terms. Development progressed with the stable v1 release in 2019, which established the core HTTP server capabilities and solidified automatic as a default feature, distinguishing Caddy from contemporaries that required manual TLS setup. By 2019, work on v2 began, culminating in its stable release on May 5, 2020, which overhauled the configuration to a JSON-based system for greater flexibility and transformed Caddy into a modular platform for building extensible applications beyond traditional serving. Subsequent updates built on this foundation; for instance, v2.6 in September 2022 enabled support by default via , while v2.7 in April 2023 introduced refinements including better handling of modern protocols and bug fixes for stability. In 2025, v2.10 further enhanced and implementations with features like Encrypted ClientHello and post-quantum key exchange, with ongoing 2025 efforts continuing optimizations for performance and broader protocol compatibility. To promote long-term sustainability amid growing complexity, transitioned in 2020 through its acquisition by Apilayer, a Vienna-based API infrastructure provider, allowing the project to remain independent, open-source, and under Holt's direction while securing resources for continued development. This move supported the vibrant Community, which by 2025 had amassed over 300 contributors and 100,000 lines of code across its decade-long evolution. Key milestones include production deployments by major organizations for edge services and robust integrations with container ecosystems; by 2023, official Docker images and a dedicated ingress controller facilitated seamless deployment in orchestrated environments.

Features

Core Functionality

Caddy's core functionality centers on its role as an extensible HTTP server capable of delivering static and dynamic content efficiently. It supports serving static files directly from the filesystem using the file_server handler, which allows configuration of directories and indexing when enabled. For dynamic content, Caddy integrates plugins such as php_fastcgi to process scripts over protocols like Unix sockets or TCP, enabling seamless handling of server-side languages without additional software. Built-in compression via the encode handler supports and Zstandard () algorithms to reduce response sizes and improve transfer speeds, applied ally based on client capabilities. Routing and middleware form the backbone of request and response handling in Caddy, primarily configured through site blocks in the Caddyfile. These blocks define virtual hosts by specifying site addresses (e.g., example.com), allowing multi-site hosting where requests are matched and processed in order. Middleware chains include handlers like rewrite for URI manipulation (e.g., redirecting /old to /new), header for adding or modifying HTTP headers (e.g., setting X-Content-Type-Options: nosniff), and logging directives for capturing access logs with customizable formats and outputs. This modular pipeline enables precise control over the request lifecycle, from matching to final response generation. At its foundation, Caddy operates as a unified platform for managing multiple applications, or "apps," through a single configuration file. The core HTTP server app handles web serving, while others like the process supervisor app can monitor and restart subordinate processes, facilitating tasks such as running web applications alongside automation scripts. This ecosystem allows administrators to orchestrate diverse services—such as serving web content while supervising background tasks—without separate tools, all updated dynamically via the configuration API. Automatic HTTPS is enabled out-of-the-box for secure serving. Caddy's extensibility is achieved through 92 standard modules, which plug into the HTTP handler chain or global configuration to add specialized capabilities. For instance, modules like http.authentication.providers.http_basic enforce basic auth, via community modules like http.handlers.rate_limit prevents abuse by capping requests per client, and metrics export with http.handlers.metrics integrates with for monitoring endpoints like /metrics. These modules compile statically into the binary, ensuring no runtime dependencies and high performance across platforms.

Security and Performance

Caddy's security model emphasizes automation and default-safe configurations to minimize user error and exposure risks. A core feature is its automatic HTTPS implementation, which integrates seamlessly with the ACME protocol to obtain and manage certificates from public certificate authorities like Let's Encrypt. This process handles certificate issuance for public DNS names without manual intervention, provided the server has access to ports 80 and 443 and the necessary DNS resolution. Renewal occurs in the background with exponential backoff, attempting checks up to every 30 days but no more frequently than daily, and includes fallback to alternative issuers like ZeroSSL if primary ones fail. Additionally, Caddy enables OCSP stapling by default for certificates that support it, attaching revocation status responses to TLS handshakes to enhance privacy and reduce latency from external OCSP queries. Automatic HTTP-to-HTTPS redirects are also enforced, ensuring all traffic is secured by default. Beyond TLS automation, Caddy incorporates several built-in mechanisms for web security. It supports , allowing the server to proactively send linked resources (e.g., stylesheets or scripts) to clients via the push directive, which parses Link headers to identify pushable assets and applies default client headers like Accept-Encoding for compatibility. For stricter transport security, the header directive enables (HSTS), configurable with directives like Strict-Transport-Security max-age=31536000 to enforce for a specified duration, and supports the preload flag for submission to browser preload lists when combined with appropriate max-age and subdomain inclusion. Security headers such as (CSP) and X-Frame-Options can be set via the same directive; for example, X-Frame-Options DENY prevents by blocking page framing, while CSP rules restrict resource loading to mitigate XSS risks. Mutual TLS (mTLS) is supported through the tls directive's client_auth subdirective, which verifies client certificates against trusted pools sourced from files, PKI roots, or HTTP endpoints, with modes like require_and_verify enforcing authentication. On the performance front, leverages Go's runtime for efficient handling of concurrent connections, utilizing goroutines and an event-driven I/O model to achieve low latency without traditional multi-threading overhead. This design contributes to responsive serving, particularly for I/O-bound tasks. Support for over is available via custom builds, opening UDP sockets for multiplexed, connectionless transport that reduces and connection setup overhead compared to TCP-based . In benchmarks from 2025 using custom builds with enabled, demonstrates 15–30% latency reductions over in compatible environments, making it suitable for modern, low-latency applications. Resource efficiency is another strength, with an idle of 15–25 MB and scaling to 80–120 MB under 1,000 concurrent connections, allowing deployment on resource-constrained systems. Automatic tuning for CPU-intensive operations, such as parallelized TLS handshakes during certificate management, further optimizes efficiency by distributing workloads across available cores without explicit configuration.

Architecture

Design Principles

Caddy's design is fundamentally guided by a of , aiming to eliminate common pain points in deployment and management. Central to this ethos is the "zero-config HTTPS" feature, which automatically provisions and renews TLS certificates from providers like , enabling secure connections by default without manual intervention. This contrasts with traditional servers like or , where extensive configuration files are required for HTTPS setup. Complementing this is the human-readable Caddyfile, a concise configuration format that reduces verbosity and setup complexity, allowing users to define sites and directives in a straightforward, declarative syntax. Extensibility is another core principle, achieved through a plugin-based that leverages Go's module to keep the core server minimal while allowing the inclusion of additional applications and modules by compiling custom builds using Go's module . This modular approach enables to adapt to diverse use cases, from basic file serving to advanced proxying, without bloating the base installation. Users can extend functionality by incorporating community or custom plugins, which integrate seamlessly into the server's runtime environment. Caddy employs a unified as a for all services, including HTTP handling, TLS management, and more, which supports hot-reloading to apply changes without or service interruption. This design ensures consistency across configurations and facilitates management via both the Caddyfile and a JSON-based for programmatic control. Portability is prioritized by compiling Caddy into a single static binary with no external runtime dependencies, making it suitable for deployment across architectures like and x86, as well as containerized environments such as Docker. This self-contained nature simplifies distribution and operation in varied hosting scenarios. Written in Go, Caddy benefits from the language's support for concurrent execution and efficient performance, contributing to its lightweight footprint.

Modular Components

Caddy's modular is built around a core engine that orchestrates various pluggable components, enabling extensible and efficient operation. The core engine handles the lifecycle of applications and modules, ensuring seamless integration through a standardized interface that promotes as a key design principle. This structure allows to manage configurations dynamically while maintaining high performance and reliability. The core engine serves as the central orchestrator, utilizing a directive-based parser to deserialize configurations into executable modules. It manages the loading and unloading of configurations via Run() and Stop() methods, ensuring atomic and consistent updates during runtime. Additionally, the engine includes an admin server that exposes endpoints like /config for -based updates, facilitating runtime management without service interruption. These components interact by provisioning modules from the parsed configuration, initiating their start and stop sequences as needed. Caddy employs a set of core applications (apps) that encapsulate specific functionalities, each provisioned and managed by the core engine. The HTTP app handles incoming requests through a configurable system, where matchers evaluate conditions and handlers process requests in sequence, defaulting to a 200 response for unrouted traffic. The TLS app manages connection security by loading certificates into memory for handshakes, supporting automated issuance and renewal via issuers like ACME, and features such as for enhanced security. The layer4 app enables proxying at the , configuring servers to route TCP and UDP traffic based on listen addresses and matchers, though it requires custom builds for inclusion. These apps interact via the core's lifecycle management, with the HTTP app often integrating TLS for secure request handling and layer4 for lower-level proxying. Within the HTTP app, a middleware chain processes directives sequentially in a model, where each handler executes in order and passes the request to the next, allowing responses to flow back up the chain. Directives such as for content compression, header for manipulation, and rewrite for modification are implemented as handlers, forming an extensible sequence that transforms requests and responses efficiently. This chain is provisioned by host modules that load and configure guest modules, ensuring ordered execution without tight dependencies. Storage and logging are handled through global options integrated into the configuration structure, providing foundational support for other components. Storage is managed via module-specific provisions, supporting file-based or in-memory implementations to persist data like certificates or assets, with the caddy.storage module enabling custom repositories for these needs. Logging emits structured outputs by default, using levels such as INFO and to filter messages, processed through a high-performance with encoders and writers for zero-allocation efficiency. These systems interact globally, with logging capturing events from apps and , while storage underpins persistent operations across modules.

Configuration

Caddyfile Syntax

The Caddyfile serves as the primary configuration format for , providing a human-readable, text-based to the server's native configuration. It enables users to define server behavior through a structured syntax that emphasizes simplicity and modularity, making it suitable for manual configuration of web servers. Unlike Caddy's format, the Caddyfile is less flexible but more intuitive for straightforward setups. The structure of a Caddyfile consists of an optional global options block followed by one or more site blocks. The global options block, enclosed in curly braces without a preceding , sets server-wide parameters such as debug mode or admin endpoints; for example, { debug } enables for . Site blocks begin with one or more matchers, such as domain names (e.g., example.com), IP addresses, or ports (e.g., localhost:8080), optionally followed by a block of directives in curly braces. Multiple addresses can be specified space- or comma-separated, and wildcards like *.example.com allow for matching. A basic site block might look like this:

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

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

This configuration serves static files from the specified directory for requests to example.com. Caddyfile syntax is indentation-insensitive, relying on whitespace to separate tokens, which promotes readability without enforcing strict formatting. Comments begin with # and extend to the end of the line, allowing annotations like # Enable compression for static assets. For modular configurations, the import directive incorporates external files or snippets, such as import ./common.conf, facilitating reusable setups across multiple Caddyfiles. Arguments to directives can be quoted with double quotes ("...") for multi-word values or backticks (`...`) for literals, and heredocs (e.g., <<EOF ... EOF) support multiline content. Upon loading, Caddy validates the entire configuration, reporting detailed errors for syntax issues, unrecognized directives, or invalid matchers to aid debugging. Directives within site blocks define specific behaviors and are processed in a fixed order to ensure predictable execution. The reverse_proxy directive forwards requests to upstream servers, with syntax reverse_proxy [<matcher>] <upstream>, as in reverse_proxy [localhost](/page/Localhost):9000 to proxy to a backend application. For HTTPS management, tls allows customization of certificates and settings, such as tls internal for self-signed or tls { client_auth { mode require } } to enforce client . Compression is handled by encode, which applies algorithms like or via encode [gzip](/page/Gzip) [zstd](/page/Zstd). Path-based routing uses handle, creating mutually exclusive blocks like:

handle /api/* { reverse_proxy backend:8080 } handle { file_server }

handle /api/* { reverse_proxy backend:8080 } handle { file_server }

This routes API paths to a proxy while serving files for others. Caddy v2 introduced a directive-based paradigm, shifting from v1's simpler, implicit syntax to explicit configurations for greater control and extensibility. In v1, setups like example.com { root /path } assumed automatic HTTPS and file serving, but v2 requires explicit directives like file_server and handles path matching more precisely (e.g., exact matches by default, with /* for prefixes). To assist migration, the caddy adapt command converts v1 Caddyfiles to v2 JSON, which can then be adapted back to the new Caddyfile format, though manual adjustments are often needed for complex cases.

API and Dynamic Management

Caddy's administration API provides a RESTful HTTP interface for programmatic configuration and runtime management of the server, enabling automation without requiring process restarts. Enabled by default and listening on localhost:2019, the API allows users to load, modify, and validate configurations dynamically, supporting zero-downtime operations essential for production environments. This endpoint can be customized via the admin block in the JSON configuration or the CADDY_ADMIN environment variable, with options to disable it entirely or restrict access using TLS and origin enforcement for security. Key endpoints facilitate core management tasks. The POST /load endpoint accepts JSON or adapted configurations (such as Caddyfile via text adapters) to replace the active config, performing a hot reload that atomically swaps the configuration if validation succeeds, or rolls back on failure to ensure no downtime. For granular changes, endpoints like POST /config/[path], PUT /config/[path], PATCH /config/[path], and DELETE /config/[path] enable targeted modifications to the config tree, using JSON Pointer notation to traverse elements such as apps, routes, or handlers; concurrent updates are safeguarded by headers and If-Match preconditions to prevent conflicts. Additional utilities include POST /stop for graceful shutdown, GET /config/[path] for exporting subsets of the config, and POST /adapt for validating configurations without applying them, which supports diffing and testing prior to deployment. The operates on Caddy's native configuration format, a structured comprising top-level apps (key-value pairs of module instances like http for the server), routes (arrays defining matchers and handler chains within apps), and handlers (actions such as respond or reverse_proxy fulfilled by specific modules). This enforces validation through module-specific directives, with all fields optional except required apps, allowing extensible and type-safe updates; the /adapt endpoint further aids by converting and validating alternative formats like Caddyfile before . Dynamic features extend to file watching via the caddy run --watch command, which monitors config file changes and triggers reloads automatically, complementing manual calls for file-based workflows. In practice, the API integrates seamlessly with orchestration and automation tools. For containerized deployments, it pairs with Docker Compose for scripting config updates during service scaling, using tools like curl to push JSON payloads in startup hooks. In Kubernetes environments, controllers leverage the API for runtime adjustments, such as the official Gateway API implementation that uses it to manage ingress routing without direct Caddy embedding, enabling auto-scaling and zero-downtime deploys. For CI/CD pipelines, scripts can invoke endpoints to validate and apply configs post-build, ensuring consistent deployments across environments while the Caddyfile serves as a human-readable alternative for initial static setups.

HTTP Server Capabilities

Supported Protocols

Caddy provides full support for HTTP/1.1, which includes persistent connections to maintain efficiency by reusing TCP connections for multiple requests between client and server. This version operates over TCP as the transport layer, ensuring compatibility with a wide range of legacy clients and applications. In addition, Caddy natively supports HTTP/2, featuring multiplexing to allow multiple concurrent requests over a single TCP connection and server push to proactively send resources to clients. HTTP/2 requires TLS for secure operation and uses the TCP transport layer, with protocol negotiation handled via Application-Layer Protocol Negotiation (ALPN) during the TLS handshake. For clients unable to support higher versions, Caddy falls back to HTTP/1.1 transparently. Caddy also enables HTTP/3 by default, which is built on the QUIC transport protocol over UDP, providing multiplexing similar to HTTP/2 but with reduced connection setup latency through 0-RTT resumption. QUIC integrates congestion control mechanisms, such as the default Cubic algorithm, to optimize throughput on variable networks. HTTP/3 negotiation occurs via ALPN ("h3") in the TLS handshake, and its design, leveraging TLS 1.3, positions it as post-quantum ready with Caddy's inclusion of post-quantum key exchange algorithms like x25519mlkem768 since version 2.10. As of 2025, ongoing developments address HTTP/3 stability, such as resource leak fixes in QUIC listeners. Caddy's automatic configuration facilitates secure protocol negotiation by default, ensuring all supported HTTP versions operate over TLS where required.

Proxy and

Caddy's functionality serves as a core component for directing incoming traffic to backend services, enabling efficient load distribution and request manipulation without exposing internal infrastructure. It supports a variety of transports, including HTTP, , and , allowing for seamless integration with diverse applications. The proxy operates by forwarding requests to specified upstreams while preserving or modifying headers as needed, ensuring compatibility with modern web architectures. In terms of upstream load balancing, Caddy employs policies such as round-robin, which cycles through backends in sequence, and weighted round-robin for prioritizing higher-capacity servers. Health checks are integral, with active monitoring sending periodic probes to verify backend availability and passive checks evaluating response status, latency, or failure thresholds to dynamically adjust . These mechanisms prevent overload on unhealthy upstreams and support retries within configurable durations, enhancing reliability in distributed systems. Header passing and stripping are handled through dedicated directives that add, set, delete, or replace request and response headers, including automatic insertion of for trusted proxies. WebSocket support is built-in via HTTP upgrades, enabling real-time bidirectional communication with configurable streaming timeouts and buffering to optimize performance for interactive applications. Caddy's routing logic relies on matcher-based evaluation, where conditions like host, path, or query parameters determine request handling paths. Subroutes, implemented through nested blocks, allow for hierarchical organization of directives, facilitating complex conditional flows. The try_files mechanism provides fallback serving by attempting to locate and rewrite to existing files before defaulting to an error or alternative handler, streamlining content delivery in routing chains. Advanced proxying extends to Layer 4 capabilities via the community-maintained layer4 module, which forwards raw TCP and UDP connections to upstreams with load balancing and health checks. HTTP-to-HTTPS redirects are automatically enforced for secure upstream communication, while applies distributed, zone-based throttling with Retry-After headers to mitigate abuse. Circuit breakers, integrated into passive health checks, temporarily isolate failing backends based on latency or error rates, promoting . These features position Caddy as an effective tool for gateway patterns, where and load balancing manage external access to services. In environments, health checks and circuit breakers ensure resilient traffic distribution across nodes. Integration with supports dynamic backends like applications, allowing proxying to processes such as php-fpm for efficient script execution.

Development and Ecosystem

Implementation Details

Caddy is implemented in the Go programming language, which enables efficient concurrency through its lightweight goroutines, allowing the server to handle multiple requests simultaneously without the overhead of traditional threads. The core networking functionality builds upon Go's standard net/http package, providing a robust foundation for HTTP/1.1, , and support while integrating seamlessly with Go's runtime for optimized performance. Additionally, Caddy compiles to a single static binary, eliminating runtime dependencies and enhancing portability across major platforms such as Windows, macOS, , and various architectures without requiring external libraries. The build process utilizes xcaddy, a specialized tool for creating custom Caddy binaries with selected modules, facilitating cross-compilation for multiple platforms by setting environment variables like GOOS and GOARCH, similar to standard Go tooling. This approach ensures through Go modules, where dependencies are pinned in the go.mod file to specific versions, preventing unexpected changes during compilation and supporting consistent deployment environments. Testing in Caddy encompasses comprehensive unit and integration tests that verify core functionality, concurrency handling, and protocol compliance, contributing to the project's reliability. is managed via Actions, which automate building, testing, and releasing binaries across platforms, ensuring code quality and rapid iteration on pull requests. Maintenance follows a regular release cycle with frequent updates, bug fixes, and new features while incorporating community feedback. Recent releases, such as v2.10.0 in April 2025, have introduced advanced features like Encrypted ClientHello and support. Security is upheld through community-led audits and a dedicated that encourages responsible disclosure of vulnerabilities in the core codebase. The v2 series maintains guarantees, allowing configurations and modules to remain functional across minor and patch releases without requiring user intervention. Caddy operates under the Apache 2.0 license, facilitating open contributions to its development.

Plugins and Community

Caddy's extensibility relies on a modular that allows users to incorporate plugins, known as modules, to customize functionality without modifying the core server. The primary tool for building custom Caddy binaries with selected modules is xcaddy, a command-line utility that simplifies compilation by downloading the Caddy source and integrating specified plugins during the build process. Official documentation registers 349 modules, encompassing both built-in standard modules and community-contributed non-standard ones, which extend capabilities such as file serving, issuance, and logging. Representative examples include the http.authentication.providers.basic module for implementing HTTP Basic Authentication to protect resources with username-password pairs, and the caddy.fs.git module for dynamically cloning repositories to enable automatic deployments from pushes. The Caddy community thrives around its primary GitHub repository, which has garnered over 50,000 stars as of early 2025, reflecting widespread interest and adoption among developers. Support channels include the official forums at caddy.community for discussions on configuration, troubleshooting, and feature requests, alongside an active server for real-time community interaction. The project sustains development through a sponsorship model managed via Sponsors and the Caddy website, where contributions from individuals, professionals, and organizations fund maintenance, security audits, and enhancements. Caddy sees adoption in diverse scenarios, often as a lightweight alternative to Traefik for reverse proxying in containerized environments due to its simpler configuration and automatic handling. It is commonly used for hosting sites by serving as a secure frontend proxy that manages TLS certificates seamlessly. Integrations with infrastructure tools like Terraform for declarative infrastructure provisioning and for automated configuration management further facilitate its deployment in scalable setups. Contributions to Caddy follow established guidelines outlined in the project's contributing documentation, emphasizing clear issue reporting, code quality standards, and testing requirements for pull requests. modules undergo review for inclusion in the official registry, typically through separate repositories before potential integration into the core via pull requests to the main codebase. Experimental extensions, such as support for running WASM modules as , have emerged from community efforts to enhance runtime flexibility.

References

  1. https://caddyserver.com/docs/automatic-https
  2. https://github.com/caddyserver/caddy
  3. https://caddyserver.com/docs/
  4. https://caddyserver.com/features
  5. https://caddyserver.com/docs/caddyfile
  6. https://caddyserver.com/
  7. https://www.ardanlabs.com/news/2020/08/caddy-server-is-acquired/
  8. https://github.com/caddyserver/caddy/releases/tag/v2.10.0
  9. https://caddyserver.com/download
  10. https://github.com/caddyserver/caddy/releases/tag/v2.10.2
  11. https://caddy.community/t/thanks-for-10-years-of-caddy/29615
  12. https://8grams.medium.com/caddy-a-modern-web-server-built-with-golang-7282464556f4
  13. https://arstechnica.com/gadgets/2020/05/caddy-offers-tls-https-and-more-in-one-dependency-free-go-web-server/
  14. https://linuxiac.com/caddy-2-6-web-server-brings-http-3-support/
  15. https://caddy.community/t/caddy-v2-7-5-released/21381
  16. https://hub.docker.com/_/caddy
  17. https://github.com/caddyserver/ingress
  18. https://caddyserver.com/docs/modules/http
  19. https://caddyserver.com/docs/modules/
  20. https://caddyserver.com/docs/caddyfile/options
  21. https://caddyserver.com/docs/caddyfile/directives/push
  22. https://caddyserver.com/docs/caddyfile/directives/header
  23. https://caddyserver.com/docs/caddyfile/directives/tls
  24. https://caddyserver.com/docs/architecture
  25. https://caddyserver.com/docs/json/apps/http/servers/
  26. https://onidel.com/caddy-vs-nginx-vps-2025/
  27. https://caddyserver.com/docs/caddyfile/concepts
  28. https://caddyserver.com/docs/api
  29. https://caddyserver.com/docs/json/admin
  30. https://caddyserver.com/docs/modules/tls
  31. https://caddyserver.com/docs/modules/layer4
  32. https://caddyserver.com/docs/modules/http.handlers
  33. https://caddyserver.com/docs/modules/caddy.storage
  34. https://caddyserver.com/docs/logging
  35. https://caddyserver.com/docs/caddyfile/directives
  36. https://caddyserver.com/docs/v2-upgrade
  37. https://caddyserver.com/docs/json/admin/
  38. https://caddyserver.com/docs/json/
  39. https://caddyserver.com/docs/command-line
  40. https://www.docker.com/blog/deploying-web-applications-quicker-and-easier-with-caddy-2/
  41. https://github.com/caddyserver/gateway
  42. https://caddyserver.com/docs/api-tutorial
  43. https://caddyserver.com/docs/json/apps/http/servers/protocols/
  44. https://quic-go.net/docs/quic/congestion-control/
  45. https://github.com/caddyserver/caddy/issues/7172
  46. https://caddyserver.com/docs/automatic-https/
  47. https://caddyserver.com/docs/modules/http.handlers.reverse_proxy
  48. https://caddyserver.com/docs/caddyfile/directives/reverse_proxy
  49. https://caddyserver.com/docs/caddyfile/directives/handle
  50. https://caddyserver.com/docs/caddyfile/directives/try_files
  51. https://caddyserver.com/docs/modules/layer4.handlers.proxy
  52. https://caddyserver.com/docs/caddyfile/directives/php_fastcgi
  53. https://blog.gopheracademy.com/caddy-a-look-inside/
  54. https://caddy.community/t/caddy-vs-net-http/1970
  55. https://caddyserver.com/docs/build
  56. https://pkg.go.dev/github.com/caddyserver/xcaddy
  57. https://github.com/caddyserver/caddy/actions/workflows/ci.yml
  58. https://github.com/caddyserver/caddy/security
  59. https://github.com/caddyserver/xcaddy
  60. https://caddyserver.com/docs/caddyfile/directives/basic_auth
  61. https://caddyserver.com/docs/modules/caddy.fs.git
  62. https://github.com/abiosoft/caddy-git
  63. https://caddy.community/
  64. https://caddy.community/t/caddy-community-discord/5554
  65. https://caddyserver.com/sponsor
  66. https://caddy.community/t/new-sponsorship-goals-for-2023/18313
  67. https://dev.to/mark_saward/caddy-vs-traefik-1dkp
  68. https://www.xda-developers.com/caddy-reverse-proxy-integrates-with-opnsense/
  69. https://codeofconnor.com/effortless-static-sites-with-terraform-and-caddy/
  70. https://github.com/caddy-ansible/caddy-ansible
  71. https://caddy.community/t/feedback-on-the-caddy-readme-contributing-guide-and-pr-issue-templates/1994
  72. https://github.com/brendandburns/caddy-wasm
Add your contribution
Related Hubs
User Avatar
No comments yet.