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 Temps 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, and in the normal split topology that loop is the only path by which a new or deleted route reaches the process handling requests. Expect up to a minute of staleness after any change.
- Only enabled routes are served. The snapshot skips disabled routes.
enabledis set totrueat 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 destination validation of any kind.