Reverse Proxy Routes

Publish a service that Temps does not deploy by mapping its hostname to an upstream host:port. Routes are managed with the load-balancer commands or from the dashboard, and the Pingora route table picks up changes on its next refresh.

What is a reverse proxy route

A reverse proxy route is for an unmanaged service that already runs on your server or private network. Examples include a sidecar from another Docker Compose stack, an object-storage console, or a legacy application on a fixed port.

Use a normal project domain for applications that Temps builds and deploys. Use a reverse proxy route only when Temps should forward traffic without managing the upstream lifecycle.

Each route stores:

Field	Purpose
Domain	Public hostname matched by HTTP `Host` or TLS SNI
Host	Upstream host, stored exactly as supplied
Port	Upstream port
Type	`http` for TLS termination or `tls` for SNI passthrough
Enabled	Whether the route is active — `true` when created

Reading routes requires the load-balancer read permission; creating, updating and deleting them requires load-balancer write.

Create a route

bunx @temps-sdk/cli load-balancer create \
  --domain status.yourdomain.com \
  --target upstream.yourdomain.com:9300

--domain has the short form -d and --target has -t. The group is also aliased to lb, so bunx @temps-sdk/cli lb create is equivalent.

--target accepts either a bare host:port or a full URL. It is parsed as a URL, so a value with no scheme is treated as http://, and a value with no port falls back to 443 for https:// and 80 otherwise. Give the port explicitly unless you want that default.

Creating a route for a domain that already has one is rejected. Anything else you supply is stored as given — see Upstreams are not validated below.

Choose HTTP or TLS

Type	Proxy behavior	Certificate owner
`http`	Temps terminates TLS and routes by the HTTP `Host` header	Temps needs a certificate for the route hostname
`tls`	Temps routes by SNI without terminating TLS	The upstream presents and manages its certificate

HTTP is the default, and it is the only type the CLI can create — load-balancer create sends no route type, so the server applies http.

A TLS route cannot be created from the CLI. There is no --type flag. Use Settings → Load balancer → Add route in the dashboard, which offers an HTTP/TLS choice, or POST /lb/routes directly with route_type: "tls" in the body.

After creating an HTTP route, provision or import its certificate with the domains commands. A TLS route needs no certificate in Temps, because the upstream terminates TLS itself.

Upstreams are not validated

Pointing a route at a private or loopback address works, and needs no extra flag:

bunx @temps-sdk/cli load-balancer create -d sentry.yourdomain.com -t 127.0.0.1:9300

Temps does not validate the upstream. The host and port are stored exactly as supplied — there is no destination allow-list, no rejection of link-local or cloud-metadata addresses, and no resolution of a hostname to a checked literal address. Creating a route is therefore a way to publish anything reachable from the server, including services on loopback and the private network.

Treat load-balancer write as a privileged permission and grant it only to operators you would trust to expose an internal service to the public internet.

The upstream is stored, never resolved at creation time, so a hostname upstream is whatever DNS resolves it to when the proxy connects.

Inspect, update and delete routes

bunx @temps-sdk/cli load-balancer list
bunx @temps-sdk/cli load-balancer list --json
bunx @temps-sdk/cli load-balancer show --domain status.yourdomain.com
bunx @temps-sdk/cli load-balancer show --domain status.yourdomain.com --json
bunx @temps-sdk/cli load-balancer update --domain status.yourdomain.com --target upstream.yourdomain.com:9400
bunx @temps-sdk/cli load-balancer remove --domain status.yourdomain.com --yes

update changes an existing route's target; it takes the same -d / -t pair as create.

Aliases: list accepts ls, create accepts add, and remove accepts rm. Removal prompts for confirmation unless you pass --yes (or --force), so a script needs one of them to run unattended.

Limits and behaviour

Changes take up to 60 seconds to reach live traffic. The proxy serves from an in-memory snapshot refreshed on a 60-second loop. Route writes from the API and dashboard update a different in-memory copy from the one that serves traffic, so that loop is the only path by which a new or deleted route reaches live requests. Expect up to a minute of staleness after any change.
Only enabled routes are served. The snapshot skips disabled routes. enabled is set to true at creation, and there is no CLI command to toggle it.
One route per domain. Creating a second route for a domain that already has one is rejected.
Wildcards are supported. A domain beginning with *. is treated as a wildcard. Exact matches are looked up first; wildcards are then scanned in turn, so keep the set small.
The upstream is not checked. See the warning above — there is no hostname or destination validation of any kind. The only check is the one-route-per-domain rule.
Route changes are not audit-logged. Creating, updating or deleting a route does not write an audit log entry, so keep your own record of who changed what.

For how the proxy handles ports, timeouts and load balancing for the apps Temps does deploy, see Networking. For certificates and DNS, see Domains and SSL.