ahmza/blog-ahmza-com
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
467 Commits 6 Branches 0 Tags
ea19586b04567f48894a273fac75174830a9e2df
Commit Graph
5 Commits
Author SHA1 Message Date
ahmza ea19586b04 add blog
Build Hugo / deploy (push) Failing after 6s
Details
Build Hugo / build (push) Successful in 16s
Details
2026-10-31 20:42:16 +00:00
ahmza 2c6f20fbc3 docs: show dynamic cloudflare trusted_proxies as primary example 
caddy-cf now bundles WeidiDeng/caddy-cloudflare-ip, so document
'trusted_proxies cloudflare { interval 12h; timeout 15s }' as the
primary (auto-refreshing) approach, with the static-list method noted
as the fallback for builds without the plugin. Also explains
client_ip_headers (Cf-Connecting-Ip preferred, X-Forwarded-For fallback).
 2026-07-25 05:04:52 +01:00
ahmza c24ed01e0a docs: document Cloudflare-fronted HTTP-only Caddy topology 
The live production setup is Cloudflare -> Caddy (HTTP :80) -> SWS, which
differed from the DNS-01 topology the doc previously assumed. Add a
'Deployment topologies' overview and a dedicated Cloudflare-fronted
section pointing at the committed root Caddyfile, covering reverse_proxy,
encode, security headers, and Cloudflare trusted_proxies. Label the
existing Compose/K8s examples as the DNS-01 alternative.
 2026-07-25 04:29:33 +01:00
ahmza 1ad79d40d8 Use caddy-cf image with Cloudflare DNS-01 challenge 
Switch the Caddy doc to the custom caddy-cf image
(ghcr.io/ahmzaa/caddy-cf) which bundles the Cloudflare DNS module, so
TLS certs are issued via the ACME DNS-01 challenge instead of HTTP-01.
This removes the need to expose ports 80/443 to the public internet,
which suits the Netbird-only infrastructure.

- Add (cloudflare) snippet + import cloudflare to both Caddyfiles
- Read CF_API_TOKEN from env (.env for Docker, Secret for K8s)
- Document token scope (Zone:DNS:Edit) and Cloudflare-hosted DNS
  requirement
- Validated Caddyfile against the caddy-cf image (caddy adapt)
 2026-07-25 01:17:35 +01:00
ahmza 7d4f1668a6 Add Caddy reverse proxy documentation 
Document running Caddy in front of the SWS origin for both deployment
targets (Docker Compose on Gimli and the Kubernetes Pi cluster), with
Caddy handling automatic HTTPS, compression, and security headers.

Explains the layer separation: SWS serves static files + Cache-Control,
Caddy owns TLS/compression/security headers (matching sws.toml where
those are disabled). Caddyfile validated with 'caddy validate'.
 2026-07-25 01:13:10 +01:00