Request flow

An approved client connects to the regional ingress. The edge evaluates the target namespace and delivery policy before forwarding a permitted request to its assigned origin path.

  1. Accept the client transport at the regional endpoint.
  2. Apply namespace and request policy.
  3. Route the accepted request to an approved origin.
  4. Return the origin response through the same controlled edge path.

Transport security

Public web surfaces use managed TLS. Certificate lifecycle and edge transport policy are operated centrally. Workspace operators remain responsible for application authentication, authorization, and sensitive response handling.

Do not send secrets in diagnostics

Remove credentials, session values, private headers, and personal data before sharing a request trace.

Origin binding

Origins are not discovered automatically. Each hostname and upstream association is reviewed during onboarding. Unrecognized hostnames and paths are not treated as valid workspace routes.

Expected operator data

  • Workspace and service reference
  • Origin hostname or internal endpoint
  • Expected response and health-check path
  • Change and rollback contact

Health checks

Edge availability and workload health are separate signals. The public status page describes the regional edge. Application-level incidents remain the responsibility of the corresponding workspace operator unless an edge advisory is published.

Service boundaries

This endpoint is not a public file host, open relay, anonymous proxy, or self-service CDN. Public registration, arbitrary origin forwarding, and unmanaged uploads are not supported.