# Caddy, Authentik, Anubis, and split-DNS playbook

Use this when modifying franksdank.cloud routes, DNS records, or auth wrapping.

Architecture:
- Single Caddy container on Dankclaw fronts services on Dankclaw and Dankserver.
- LAN DNS via Pi-hole resolves service names to 192.168.0.143.
- Public DNS via Porkbun points exposed names to WAN IP 71.227.227.172.
- TLS uses Porkbun DNS-01 wildcard certificates; ordinary A-record deletion does not break wildcard renewal.
- Porkbun credentials are machine-local secrets, never tracked.

Caddy rules:
- Keep Caddy admin enabled on 127.0.0.1:2019 inside the container so file watcher hot-reload works.
- Caddy routes by Host header; it does not care whether the name resolved via Pi-hole or Porkbun.

DNS changes:
1. If a service should be LAN-only, it is usually safe to remove its ordinary Porkbun A record while keeping Pi-hole local DNS.
2. Removing public DNS does not remove router port forwards or block direct IP access.
3. Do not casually remove public DNS for auth.franksdank.cloud; external login flows may need it.
4. Be cautious with gitea.franksdank.cloud because external git smart-HTTP use may depend on public DNS.

Auth wrapping:
- Protected via Authentik forward_auth: homepage, SearXNG, Hermes, Prometheus, RomM, Copyparty.
- Usually bypass forward_auth because they have native auth: Grafana, Gitea, OpenWebUI, Jellyfin, *arr, Pi-hole.

Verification pitfalls:
- Curl or bot-like clients may get Anubis JS challenge page with HTTP 200. That does not prove the app or outpost succeeded.
- Authentik outpost provider matching depends on exact Host header. Missing/wrong Host in CLI probes can produce misleading 404s.
- Verify end-to-end login in a real browser after solving Anubis. Use logs to debug outpost 404/provider host-match failures.