first version of the knowledge base :)
This commit is contained in:
63
70 - Tools/caddy/caddy.md
Normal file
63
70 - Tools/caddy/caddy.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: Caddy
|
||||
description: Tool overview for Caddy as a web server and reverse proxy with automatic HTTPS
|
||||
tags:
|
||||
- caddy
|
||||
- reverse-proxy
|
||||
- web
|
||||
category: tools
|
||||
created: 2026-03-14
|
||||
updated: 2026-03-14
|
||||
---
|
||||
|
||||
# Caddy
|
||||
|
||||
## Summary
|
||||
|
||||
Caddy is a web server and reverse proxy known for automatic HTTPS and a simple configuration model. In self-hosted environments, it is often used as an easy-to-operate edge or internal reverse proxy for web applications.
|
||||
|
||||
## Why it matters
|
||||
|
||||
For many homelab and small infrastructure setups, Caddy offers a faster path to a secure reverse proxy than more manual alternatives. It is especially effective when a small team wants readable configuration and low TLS management overhead.
|
||||
|
||||
## Core concepts
|
||||
|
||||
- Caddyfile as the high-level configuration format
|
||||
- Automatic HTTPS and certificate management
|
||||
- `reverse_proxy` as the core upstream routing primitive
|
||||
- Site blocks for host-based routing
|
||||
- JSON configuration for advanced automation cases
|
||||
|
||||
## Practical usage
|
||||
|
||||
Caddy commonly fits into infrastructure as:
|
||||
|
||||
```text
|
||||
Client -> Caddy -> upstream application
|
||||
```
|
||||
|
||||
Typical uses:
|
||||
|
||||
- Terminating TLS for self-hosted apps
|
||||
- Routing multiple hostnames to different backends
|
||||
- Serving simple static sites alongside proxied services
|
||||
|
||||
## Best practices
|
||||
|
||||
- Keep hostnames and upstream targets explicit
|
||||
- Use Caddy as a shared ingress layer instead of publishing many app ports
|
||||
- Back up Caddy configuration and persistent state if certificates or ACME state matter
|
||||
- Keep external base URLs aligned with proxy behavior
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Assuming automatic HTTPS removes the need to understand DNS and port reachability
|
||||
- Mixing public and private services without clear routing boundaries
|
||||
- Forgetting that proxied apps may need forwarded header awareness
|
||||
- Leaving Caddy state or config out of the backup plan
|
||||
|
||||
## References
|
||||
|
||||
- [Caddy documentation](https://caddyserver.com/docs/)
|
||||
- [Caddy: `reverse_proxy` directive](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy)
|
||||
- [Caddyfile concepts](https://caddyserver.com/docs/caddyfile/concepts)
|
||||
Reference in New Issue
Block a user