Public exposure request flow

When a route is exposed, public requests arrive at the routeup server and travel back down an outbound tunnel to your local agent. Your service never opens a port to the internet.

The path

The example below assumes a root-tier token allowing *.routeup.dev.

external browser / webhook provider
  -> https://example-app.routeup.dev
  -> public DNS -> routeup server
  -> authorization and active-claim lookup
  -> tunnel stream (WebSocket + yamux)
  -> local agent
  -> 127.0.0.1:8080  (your service)
  -> response returns over the same path

Step by step

1. DNS. The wildcard *.routeup.dev points at the server, so every public host resolves there.
2. Server TLS. The server terminates HTTPS with a wildcard certificate for the namespace base (*.<base>). .dev is HSTS-preloaded, so the public side is HTTPS-only by design.
3. Claim lookup. The server maps the host to an active claim and its tunnel, rejecting unknown or unauthorized hosts.
4. Tunnel. Each public HTTP request becomes one yamux stream inside the client’s outbound WebSocket connection on 443. The connection is outbound from your machine, so it survives NAT and most corporate, hotel, and mobile networks.
5. Local delivery. The local agent receives the stream and reverse-proxies it to the local target, exactly as in the local flow.

Why a tunnel

The outbound connection means your service never needs an inbound port, a public IP, or a firewall change. Cancellation and timeouts propagate end-to-end, and the agent’s tunnel client reconnects with backoff for transient drops. If the agent restarts or a tunnel terminates permanently, the live CLI owner restores the exposure from its retained desired state.

See Public server and the tunnel transport for the components involved.