Serve Warden over HTTPS with Caddy

Recommended setup

Point a DNS record such as warden.example.com at the server, allow ports 80 and 443 to reach Caddy, and run Warden on its default 127.0.0.1:8080 listener with trusted local proxy support enabled:

WARDEN_TRUST_PROXY=true warden

caddy reverse-proxy   --from warden.example.com   --to 127.0.0.1:8080

Caddy obtains and renews the public TLS certificate and supplies standard forwarded headers. Warden accepts those proxy headers only when proxy trust is enabled and the direct peer is loopback.

Caddyfile

warden.example.com {
    reverse_proxy 127.0.0.1:8080
}

For a persistent service, set trust_proxy to true in Warden's durable configuration (or bootstrap with WARDEN_TRUST_PROXY=true) and run both services under your normal service manager.

Secure cookies and WebSockets

When Caddy forwards an HTTPS request, Warden recognizes X-Forwarded-Proto: https from the trusted local proxy and marks newly issued session cookies Secure. Warden's terminal WebSocket uses the browser's current wss: scheme automatically when the page is HTTPS.

Forwarded-header contract

Send one unambiguous X-Forwarded-Proto value. Warden fails closed on comma-separated protocol chains and considers only the first X-Forwarded-For hop. Terminal WebSockets must present an Origin matching the effective scheme and host, so keep the public Host header intact.

Google authentication

If Google sign-in is enabled, configure its authorized redirect URI with the public HTTPS origin, for example https://warden.example.com/api/oauth/google/callback. The same value must be authorized in the Google OAuth client.