Cloudflare Tunnel

Purpose

Exposes internal homelab services, including Hermes, to the public internet without opening inbound firewall ports.

Location

• Runs on: ct207 “webserver” (Tailscale 100.82.40.23), not on this host.
• Binary: /bin/cloudflared
• Service: cloudflared.service (systemd, active/running on ct207)
• Tunnel name / ID: ct207-tunnel / 339a6757-5574-4723-a16c-da4769535caa
• Config: /etc/cloudflared/config.yml on ct207; credentials file 339a6757-5574-4723-a16c-da4769535caa.json in the same directory (not read/copied here — credential material, not a fact to mirror).

Current configuration

• originRequest: noTLSVerify: true, disableChunkedEncoding: true, http2Origin: false (global defaults; some hostnames override per-entry)
• Ingress is a flat list of hostname → service mappings ending in service: http_status:404 catch-all — see domains-and-tunnels for the full list and the entries specific to Hermes.
• Two Hermes-relevant entries point at this host’s Tailscale IP (100.118.5.51): hermes.martinwa.org (port 19119) and hermes-desktop.martinwa.org (port 5174).

Connected systems

• hermes-agent — the service actually reached through this tunnel
• domains-and-tunnels — full hostname table
• network-map

Known issues

• This host cannot restart or inspect the tunnel directly (no cloudflared installed here); a tunnel-side problem requires access to ct207.
• mcp-portal.martinwa.org, referenced in Hermes’s own config as an MCP endpoint, was not found in the ct207 ingress list captured 2026-07-22 — unresolved, may be on a different tunnel/host.

Relevant runbooks

• diagnose-docker (closest existing runbook; no dedicated tunnel-restart runbook exists yet — worth writing one that documents systemctl restart cloudflared on ct207, since Hermes has no direct access to perform it)