measurements/cloudflare-sparrow-20260910/README.md

relay.sparrowsystems.co — public transport verified

Selected by the user on 2026-09-10. The dedicated Cloudflare connector is installed on the existing Graviton5 parent and Cloudflare reports it healthy with four connections. Production enclave 92bd475 was not restarted, replaced or reconfigured. Its ongoing in-memory warm-up is preserved.

Tunnel ID: 2f2137bf-c07d-41b9-94f0-276947c38dd6. Tunnel name: attested-relay-v2. Zone: sparrowsystems.co (0b0edf96f88433c25edae95c4694a895). Host unit: attested-relay-cloudflared.service. Connector: Cloudflare ARM64 release 2026.9.0, verified against the GitHub release asset SHA256 98aca3173f73248fad6180fc75dade2d186a6e54fa807e088108cb4345de8efe. The connector token is root-private on the parent; account OAuth credentials were not transferred. Connector logs are discarded and metrics bind to loopback.

Superseded direct-tunnel DNS plan

Historical plan only: the Worker custom domain below now owns the hostname. Do not apply this CNAME over that managed record. The earlier proposed fields were:

DNS field Value
Type CNAME
Name relay
Target 2f2137bf-c07d-41b9-94f0-276947c38dd6.cfargotunnel.com
Proxy status Proxied (orange cloud)
TTL Auto

The earlier direct-tunnel plan also required a cache rule matching hostname relay.sparrowsystems.co, action Bypass cache, after any conflicting matching cache rules. Review redirects, query transformations and WAF/browser challenges for that hostname before publishing the machine API. Existing Worker routes and account Access application lists were empty at preflight. The available credential could not inspect DNS, page rules or rulesets, so their absence must not be inferred. Do not overwrite an existing DNS conflict.

Wrangler login refreshed successfully. It can read the zone and manage tunnels, but DNS/ruleset APIs returned authentication/authorization failures. No connected browser was available for dashboard edits. The direct DNS/ruleset API path was unavailable. The subsequent Wrangler-supported Worker custom-domain path completed publication using the existing authorized Workers and connectivity permissions.

Checks and evidence

Deployed through npx Wrangler

npx wrangler vpc service create registered the existing tunnel's specific 127.0.0.1:8080 HTTP service. npx wrangler deploy published attested-relay-v2-front and provisioned its custom domain automatically. No manual DNS/cache-rule edit is required for this deployed Worker path.

Public URL: https://relay.sparrowsystems.co Worker version: 1c1a370e-a264-4718-a367-e2072848ad2a. VPC service: 01a08a5b-23c8-7492-a759-9bbb4fbddd78. Worker source and config.

The Worker permits only the selected hostname, GET and the bounded relay/artifact paths (plus a static informational root). It preserves the query and response bytes, disables caching, does not follow origin redirects or log queries, and can reach only the registered loopback service through the binding. Ordinary HTTPS protects the outer connection; client-side Nitro verification still protects the inner TLS endpoint. No enclave image, PCR pin, or warm-up changed. The connector's original hostname ingress remains configured but is not the public DNS route; the VPC binding selects the origin directly.

Public evidence from Hetzner using ordinary DNS and verified HTTPS:

Python's default urllib user agent received an edge 403 during the public TLS flight. A protocol-specific user agent succeeds. GetTransport now sets attested-relay/2, which also covers archive/follower requests sharing its opener; the mirror source sets attested-relay-mirror/2. Public attestation and rejection checks used this updated client source in an isolated directory. The published PyPI 0.2.0a2 wheel has not been republished; the source fix needs a new package release before recommending that unchanged wheel for this public route. Existing Hetzner production services still use their authenticated SSH origin.

Validation: 3 Worker tests, 64 SDK tests, 12 mirror tests and the 7 front-door configuration tests passed. The initial failed handshake was retained as an observed integration defect and fixed by identifying the application in HTTP. These checks prove public transport and authentication while warming; application forwarding and record recovery through this route await an active epoch.

At validation time public resolvers and Hetzner resolved the hostname, but the Mac system resolver retained its previous negative answer despite ordinary dig returning current records. No hosts-file override or DNS configuration change was made. This is distinct from the successful public-server checks.