Requests hairpin through the cloud droplet: home → Cloudflare → pg-grand → back home to the vxrail (77 ms RTT per hop); serve vxrail-hosted apps from a vxrail ingress #4576

Measured 2026-10-21 19:55Z. The owner sees "330 ms lag" on the arm. The page's lag figure is the time to first byte of a small GET through the public URL (viewer.html timed()).

• The cause: the ingress (cloudflared plus the single traefik) runs on pg-grand, the DigitalOcean droplet. The forge pod and its apps run on the vxrail at home, about 3 ms from the arm's Pi.
• The hop between them: pg-grand ↔ vxrail over the tailnet is 77 ms RTT (ping 100.84.55.62).
• The result: every request hairpins home → Cloudflare → cloud droplet → home. Each new connection pays several 77 ms round trips, and so does every WebSocket message from a driver.

Done when:

• Traffic for hosts served from the vxrail enters at the vxrail: a cloudflared connector or a separate tunnel on the vxrail, with an ingress (a traefik replica or the forge directly) on the vxrail for *.open-platform.sh hosts whose pods live there.
• pg-grand-hosted things keep their path.
• Zero-downtime cutover: the new path is proven on a test host first, then the DNS or tunnel route moves (owner rule: no dark roll).
• Target: public GET /link ttfb under 80 ms from the owner's network, and arm command-to-motion dominated by the user's own internet hop.
• Report: before and after, the table above.

Owner's call on the cutover window. Measured by the steward; nothing changed yet.

Parked by the crew: the run ended without a pull: declined: this is a change to live infrastructure, not to this app, and I can't do it or check it from here.

Parked by the crew: the run ended without a pull: declined: The work this issue asks for happens on the platform, not in this repository, and I can't do or check any of it from here.

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the run ended without a pull: declined: this is a change to live infrastructure, not to this app, and I can't do it or check it from here
2. the run ended without a pull: declined: The work this issue asks for happens on the platform, not in this repository, and I can't do or check any of it from here

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Deferred behind the Later gate (#595). Serving vxrail-hosted apps from a vxrail ingress is a change to the cluster and network, not to this repository; the crew declined it twice because nothing here can make or check it, and the planner rules forbid touching the chart. It waits for the owner to do or scope the infrastructure side; once there is a repository-side piece (e.g. the forge reading its ingress from config), it can be planned under P0.

Done, 2026-10-22 00:25Z (owner's go). Steward.

What changed:

• New Cloudflare tunnel forge-home (288cdfda-…), with connectors standby/cloudflared-forge-home (2 replicas, pinned to the vxrail with its plat.sh/site toleration). Credentials are only in the secret cloudflared-forge-home-credentials.
• Routes: forge.open-platform.sh, arm--forge-trevato-apps.open-platform.sh and the test host forge-home-test.open-platform.sh go straight to forge.trevato-apps--forge--prod.svc:80, with no droplet and no traefik. *.open-platform.sh falls back to traefik; anything else gets 404.
• DNS: three new proxied CNAMEs to the new tunnel. The wildcard *.open-platform.sh (old tunnel) and every other record are untouched. Rollback is to delete one of the new records; that host falls back to the wildcard at once.

Measured (TTFB minus TLS, the owner's network, 20 interleaved samples):

The forge home page, /api/v1/health (0.7.242), git over HTTPS and the authenticated API all work. On the arm page the camera is live and the arm link is live.

Left:

• Other app hosts and pull previews still use the wildcard. Covering every --forge- host needs a DNS record per app; the forge could create it when an app goes public, but that needs a scoped Cloudflare token in the cluster (owner's call).
• The remaining ~185 ms on the owner's network is the house uplink, crossed twice when the browser is also at home. A LAN-local path (a hostname resolving to the vxrail on the LAN) would remove it for home use.