[SUB_THREAD 1]
Most static-site setups stop at "it loads." But the build pipeline encodes assumptions the web server doesn't know: hashed asset names, HTTPS-only, no iframes, no auth. The config that bridges those assumptions to actual server behavior is the last layer most setups never touch.
#Astro #Caddy #SelfHosting #WebPerf #StaticSite
[SUB_THREAD 2]
Three security headers, three real attack vectors:
- Strict-Transport-Security (no HTTPS-to-HTTP downgrade on public WiFi, including subdomains, with preload)
- X-Content-Type-Options nosniff (no MIME guessing)
- X-Frame-Options DENY (no iframe embedding)
Static site, no auth, no forms. Nothing else needed.
[SUB_THREAD 3]
Four headers evaluated and skipped:
- Referrer-Policy (already the major browser default)
- Permissions-Policy (blocks APIs the site doesn't use)
- Cross-Origin-Opener-Policy (no auth, no popups, no tokens)
- CSP (deferred until the audit fits the schedule)
Each one would have raised the scanner score. None would have made the site safer.
[SUB_THREAD 4]
Cache strategy follows the build output:
- _astro/* (hashed filenames): immutable, 1 year
- HTML (stable URLs): no-cache, revalidate every visit
- Favicons (no hash but rarely change): 1 hour, must-revalidate
Hashed filenames are what makes "cache forever" safe. The URL itself changes whenever content changes.
[SUB_THREAD 5]
Smaller pieces: www to apex 301, encode zstd gzip as a fallback path (CI pre-compresses sidecars), ACME email so silent TLS-renewal failure becomes a warning instead of a customer report.
Generic defaults cover the hard parts. The parts only you can configure (caching, headers, redirects) are the parts that signal intentionality.
Javed Arshad Butt
Caddy Config for Astro Static Sites
Security headers, cache strategy, and compression for an Astro site on Caddy. What to add, what to skip, and why each decision depends on your buil...
