Features in this color are provided by available plugins.
Overview
Caddy is essentially a configuration management system that can run various apps like an HTTP server, TLS certificate manager, PKI facilities, and more. It can be extended with plugins known as config modules.
Caddy sports a flexible and powerful HTTP reverse proxy, on-line configuration API, and a robust, production-ready static file server, and serves all sites over HTTPS by default with automagic TLS certificates.
Overall program technical specifications
Language
The language choice is crucial for a web server. Most servers (NGINX, Apache, HAProxy, etc.) and their dependencies are written in C, which are vulnerable to catastrophic memory safety bugs like Heartbleed. Go programs like Caddy are impervious to a whole class of security vulnerabilities.
Go
Build artifacts
Caddy compiles directly to native CPU instructions. There is no interpreter required; and many instructions are architecture-optimized.
Platform-native static binary
Runtime dependencies
Caddy is statically compiled. Dynamically-linked applications can easily break in production and may be less secure as shared executable resources are loaded from various places around the system. Generally, Caddy binaries do not necessarily require external libraries — not even libc.
None
Compile time
On consumer hardware, standard Caddy builds compile in just a few seconds. This is crucial for rapid iteration, plugin development, and low-cost deployments.
5 seconds
Deployment environments
Caddy can go practically anywhere and be deployed a variety of ways. In general, upgrading is as simple as replacing the binary.
- Command line interface
- System service
- Containers
- Kubernetes
- Embedded
Supply chain and releases
Go modules verify the integrity of our dependencies and we cryptographically sign our release artifacts so you know what you can trust.
Cryptographically verified
Operating systems
Caddy runs on every major platform for which Go compiles.
- Linux
- Windows
- macOS
- FreeBSD
- OpenBSD
- NetBSD
- Android
Microarchitectures
Run Caddy with native code on numerous CPU platforms.
- x86 (i386, i686)
- x86-64 (AMD64)
- ARM
- ARM 64 (AArch64)
- MIPS
- MIPS64[LE]
- PPC64[LE]
- RISCV64
- S390X
- Apple Silicon (Apple ARM; M1, M2, etc.)
Regular expression engine
Caddy's regular expression language is based on the Thompson NFA and has numerous performance improvements over PCRE used by other web servers. It guarantees the runtime cost increases linearly instead of exponentially. This is ideal when evaluating untrusted input.
RE2
Concurrency model
Go's runtime optimizes scheduled CPU time in smarter ways than the operating system can using lightweight user-space threads called goroutines. Caddy easily handles hundreds of thousands of requests per second.
Goroutines (epoll + kqueue)
Plugin model
Caddy can be extended by compile-time plugins, which compile as native code, in a way that cannot be broken during deployments or by system upgrades. With no IPC or RPC calls, Caddy extensions perform equally well with native code.
Compile-time static
High-level capabilities
Configuration changes
With zero-downtime graceful reloads, Caddy's configuration can be changed while it is running. It's programmable/scriptable for powerful automation.
- RESTful HTTP API
- Config files
- Secure remote access
App modules
Top-level configuration structures are called app modules, or Caddy apps. They provide the bulk of Caddy's functionality. Anyone can write app modules, and Caddy comes with several standard apps built-in.
- HTTP
- TLS
- PKI
- Events
- Raw TCP & UDP
- SSH
- PHP
- Dynamic DNS
- Security
- Process supervision
- Profiling
Logs
Caddy's logging can be configured as to format, verbosity, output, and more.
- Leveled
- Structured
- High efficiency, zero-allocation
Storage
Assets and state, including certificates and OCSP staples, are stored in configurable storage backends. In fact, multiple instances of Caddy configured with the same storage are considered part of a cluster and can coordinate automatically.
- File system
- Embedded (in-memory)
- Postgres
- Redis
- Vault
- Consul
Command line interface
Caddy's CLI is not only useful—it's helpful. While most server CLIs merely run the process and reload config, Caddy's CLI goes the extra lightyear to help make administering your modern web server a breeze.
Plugins can register their own subcommands to extend Caddy's CLI.
Command help
If you misspell a command or flag, miss an argument, or don't know the subcommand, help text is automatically printed. You can also access overall command help or subcommand help with
caddy help or -h.
Built-in, automatic (
man pages can also be generated)
Admin API wrappers
Several subcommands use administration API endpoints for use with the CLI to help you perform common tasks like loading config from files or stopping the server.
- Adapt config to JSON
- Start the server, optionally with config
- Gracefully reload configuration
- Stop the server
Binary utilities
Since custom builds of Caddy are so common, several commands exist to help you manage and get detailed information about your build.
- Detailed build metadata
- List installed config modules
- List dependencies
- Add and remove plugin packages
- Print the version
- Upgrade the Caddy binary
Configuration utilities
If you choose to use configuration files, Caddy's CLI helps you manage them.
- Format Caddyfile
- Validate configuration
- List dependencies
- Add and remove plugin packages
- Print the version
Module utilities
Modules may register their own subcommands to provide common functionality that can be utilized without a config document.
- Static file server
- HTTP reverse proxy
- Static HTTP responses (templateable)
- Storage import/export (backup/restore)
- Hash password for use with HTTP basic auth
- Export file browse template
Integration utilities
Several subcommands can help you integrate Caddy into your shell environment.
- Generate shell completion script
- Print the environment
- Generate
manpages - Install Caddy-managed root CA into trust stores
- Remove Caddy-managed root CA from trust stores
System signals
Caddy has support for common operating system signals/interrupts, with subtle differences in behavior for each one.
- INT (graceful stop)
- QUIT
- TERM
Exit codes
Whether Caddy exits successfully or with an error, the exit code can give a hint to your process supervisor or script how to handle that.
Configuration
We've designed Caddy so that its configuration not only provides access to features, but it IS a feature in and of itself.
No more quibbling over which config file format is the best: use whatever you want! Caddy's config adapters allow you to use whatever config format you prefer.
Native config format
Caddy's native configuration format is ubiquitous: it has tooling in nearly every operating system, platform, programming language, and API ecosystem. Almost all other formats can be translated down into JSON, which balances human readability and programmability. You'll find it a powerful ally of your web server.
JSON
Config adapters
You can always write your config in another format and with config adapters, Caddy will implicitly translate it into JSON for you so you can work with what you like.
- Caddyfile
- JSON 5
- JSON-C
- NGINX Conf
- YAML
- CUE
- TOML
- HCL
- Dhall
- MySQL
Human-friendly config
The Caddyfile is most users' favorite way to write their web server config by hand because its syntax is forgiving while also being designed with a structure that makes it easy to read and write. It is translated to JSON automatically.
Caddyfile
Export
Caddy's administration API allows you to have runtime access to the current configuration in JSON format with a simple GET request.
Config API
Caddy receives its configuration through an API endpoint, which can accept JSON or any other format it has a config adapter for.
Config files
If you prefer normal commands to manage configuration, Caddy's CLI wraps the API endpoints for you.
HTTP File Server
Caddy's file server is best-in-class.
TODO...
TODO...
TODO...