Serve Warden over HTTPS with nginx

Reverse proxy

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name warden.example.com;

    ssl_certificate     /etc/letsencrypt/live/warden.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/warden.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Start Warden with WARDEN_TRUST_PROXY=true, or enable trust_proxy in its durable configuration. Warden only honors the forwarded headers when the direct peer is loopback.

Redirect HTTP

server {
    listen 80;
    listen [::]:80;
    server_name warden.example.com;
    return 301 https://$host$request_uri;
}

Terminal and agent streaming

The Upgrade headers allow Warden's terminal WebSocket to tunnel through nginx. The long read timeout and disabled response buffering are friendly to long-running coding-agent streams as well.

Forwarded-header contract

The configuration sends one X-Forwarded-Proto value and preserves the public host. Warden rejects ambiguous protocol chains, considers only the first X-Forwarded-For hop and requires terminal WebSocket origins to match both the effective request scheme and host.

Google authentication

Configure Warden and the Google OAuth client with the public callback URL, for example https://warden.example.com/api/oauth/google/callback.