Caddy Fundamentals
Caddy is a modern web server written in Go that automatically provisions and renews TLS certificates via ACME. It serves static files, reverse-proxies to backends, and handles HTTPS by default with minimal configuration.
itWeb servers, proxies, and traffic management | OpenSkills.info
Intro
Caddy Fundamentals
Caddy is a web server and reverse proxy with automatic HTTPS. You give it a site address and request-handling rules. It listens for traffic, secures qualifying sites, and either returns a response or forwards the request to another service.
Use this mental model: Caddy is a programmable front door. The site address chooses the door. Matchers classify each request. Directives decide what happens next. Automatic HTTPS secures the public path to that door when the domain and network are ready.
Why Caddy exists
A web-facing application needs more than application code. Something must accept connections, negotiate TLS, serve static assets, route requests, and keep configuration changes safe. Caddy combines those edge responsibilities in one extensible server.
Caddy is especially useful when you want:
- automatic certificate provisioning, renewal, and HTTP-to-HTTPS redirects;
- a readable Caddyfile for hand-managed configuration;
- native JSON and an HTTP administration API for automation;
- static file serving;
- reverse proxying to one or more application servers;
- configuration reloads without planned downtime.
Caddy is not your application runtime or database. It usually sits in front of those systems. It handles the connection and routing layer while your application handles business behavior.
The request path
A common deployment looks like this:
client → DNS → Caddy → application service
↘ static files
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://caddyserver.com/docs/
Supports
- Caddy as an extensible platform commonly used as a web server or proxy
- Native JSON, the administration API, config adapters, and the Caddyfile relationship
- Self-contained binary and module-oriented scope
- https://caddyserver.com/docs/getting-started
Supports
- Foundational configuration workflow and the relationship between JSON and Caddyfile approaches
- Initial administration API and configuration-loading model
- https://caddyserver.com/docs/caddyfile
Supports
- Caddyfile as a human-friendly format for site addresses and behavior
- Caddyfile suitability for hand-maintained configuration and native JSON suitability for automation
- https://caddyserver.com/docs/caddyfile/concepts
Supports
- Site blocks, site addresses, directives, matchers, placeholders, snippets, and tokens
- Default sorting of HTTP handler directives by the adapter
- Literal ordering within route blocks
- Address forms and their listener or host meaning
- https://caddyserver.com/docs/caddyfile/directives
Supports
- Standard HTTP Caddyfile directive catalog
- Default directive order and request-handler categories
- https://caddyserver.com/docs/automatic-https
Supports
- Certificate acquisition and renewal plus HTTP-to-HTTPS redirects
- Activation and prevention rules
- Public DNS, ports 80 and 443, bind access, and persistent writable storage requirements
- Local HTTPS, local CA operation, and client trust requirements
- ACME testing, challenges, retry behavior, certificate storage, and wildcard constraints
- https://caddyserver.com/docs/quick-starts/static-files
Supports
- Minimal command-line and Caddyfile static server patterns
- root and file_server usage
- High-port alternative and browse option
- https://caddyserver.com/docs/caddyfile/directives/file_server
Supports
- Static path construction from request URI and site root
- Canonical URI behavior, browse mode, precompressed files, and error routing
- Filesystem permission guidance and symlink boundary warning
- https://caddyserver.com/docs/quick-starts/reverse-proxy
Supports
- Minimal reverse proxy command and Caddyfile patterns
- Client-facing Automatic HTTPS behavior and public-domain prerequisites
- Reload requirement after Caddyfile changes
- https://caddyserver.com/docs/caddyfile/directives/reverse_proxy
Supports
- Static and dynamic upstreams
- Load balancing, health checks, transports, header handling, and retries
- Preservation of request method and URI unless rewritten
- X-Forwarded header behavior and trusted proxy considerations
- https://caddyserver.com/docs/config-adapters
Supports
- Native JSON as Caddy's configuration language
- Adapter conversion from other formats to native JSON
- Command-line and API adapter usage and compatibility caveats
- https://caddyserver.com/docs/api
Supports
- Default administration address at localhost port 2019
- Endpoint isolation guidance and autosave behavior
- Atomic configuration load, zero-downtime activation, and rollback on failure
- Config path operations, identifiers, ETag, and If-Match concurrency control
- https://caddyserver.com/docs/command-line
Supports
- run, start, adapt, fmt, validate, reload, stop, list-modules, and version commands
- Validate loading and provisioning without activation
- Reload as the semantic production configuration-change path
- Signal behavior and graceful shutdown connection draining
- https://caddyserver.com/docs/running
Supports
- Benefits of service managers and official systemd units
- Service reload, journal logs, service user, and persistent data paths
- Local HTTPS trust considerations for services and containers
- Linux, Windows, and container operation patterns
- https://caddyserver.com/docs/architecture
Supports
- Single binary deployment model
- Command, core library, and module architecture
- Extensibility through compiled modules