Claude/eager gagarin 9eedc4#4
Conversation
Adds forwarded-headers middleware so the app sees the original https scheme behind the tunnel, and gates HttpsRedirection to Development so the in-container HTTP listener doesn't redirect-loop. New prod.docker-compose.yml runs the release image on plain HTTP (5100:80), since Cloudflare Tunnel terminates TLS upstream. No dev cert mount, restart=unless-stopped for reboot survival. docker-run.ps1 retargeted to the new compose file; also fixes pre-existing service-name mismatches in the logs/restart subcommands. PHASE_A_DEPLOYMENT.md walks the host-side checklist (prereqs, .env, cloudflared service install, verification) for the Windows rig. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Strategic plan doc for the Cloudflare Tunnel migration. Captures the decisions already made (Tunnel as edge, drop YARP/Certes, fold the trimmed model + UI into the main app), the file map for both phases, verification gates, and notes for a Claude session picking the work up on the Windows machine. PHASE_A_DEPLOYMENT.md stays as the operational host checklist; this is the higher-level companion. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
🤖 Augment PR SummarySummary: This PR updates StageZero’s Phase A deployment approach to run behind a Cloudflare Tunnel (Cloudflare terminates TLS; the container serves plain HTTP). Changes:
Technical Notes: This setup assumes Cloudflare Tunnel is the edge layer (routing + TLS) and the app is not expected to serve HTTPS directly in Production. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| { | ||
| options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; | ||
| options.KnownIPNetworks.Clear(); | ||
| options.KnownProxies.Clear(); |
There was a problem hiding this comment.
KnownIPNetworks.Clear()/KnownProxies.Clear() makes the app trust X-Forwarded-* from any direct caller, which can allow spoofed client IP/scheme if the app is reachable on the LAN/host port. If StageZero is expected to be accessed only via cloudflared, consider constraining where forwarded headers are accepted (or ensuring the container isn’t directly reachable except via the tunnel).
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| dockerfile: StageZero/Dockerfile | ||
| target: release | ||
| ports: | ||
| - "5100:80" |
There was a problem hiding this comment.
Publishing "5100:80" binds the container port on all interfaces by default, which can unintentionally expose the HTTP app directly (bypassing Cloudflare/Tunnel). If the intent is “tunnel-only,” consider limiting exposure so only the local connector can reach it.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| 'up' { | ||
| Write-Host "Starting StageZero..." -ForegroundColor Green | ||
| docker-compose -f debug.docker-compose.yml up --build -d | ||
| docker-compose -f prod.docker-compose.yml up --build -d |
There was a problem hiding this comment.
This script assumes docker-compose is available; on some Docker Desktop installs only docker compose is present, which would make up/down/logs fail at runtime. Consider ensuring the prerequisites/docs match the exact command expected on the target host.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
1 participant
No description provided.