Deploy & endpoints

Deploy a project as a long-lived app and call it over HTTPS. Web functions in the app get a stable Tengsuan URL that you can drop into any client in place of your current endpoint. Requests stream in both directions, so token-by-token model output and server-sent events pass through unchanged.

Deploy

ts deploy app.py                       # name taken from the App(...) declaration
ts deploy api/server.py --name my-api   # explicit name
ts deploy app.py --dir .                # bundle a different project root

The CLI bundles the project directory (skipping .git, virtual environments, caches and files over 8 MB), uploads it, and streams the build log back. The build runs on an isolated host, never on your machine or ours. A requirements.txt in the bundle is installed before the deploy. When it finishes you get one URL per web function:

✓ my-api deployed in 41.2s
  serve                    https://tengsuan.cloud/fn/my-api

Endpoints

Each web function is served at https://tengsuan.cloud/fn/<label>/… and at https://<label>.apps.tengsuan.cloud/…, where the label is the one declared in your code. The full path and query string are forwarded and bodies up to 64 MB are accepted. Endpoints have no platform-level authentication: enforce your own, exactly as you would today.

What the gateway forwards

Only an allowlist of request headers reaches your function. In the default strict policy that is Authorization, Content-Type, Accept, Accept-Encoding and Content-Length. The standard policy adds Accept-Language, Cache-Control, Idempotency-Key, X-Request-Id, X-Api-Key and the OpenAI-* / Anthropic-* client headers. Extra names can be allowed per app. The caller's User-Agent, Cookie, Referer, Origin and any X-Forwarded-* or X-Real-IP header are never forwarded, and the gateway presents itself with a fixed user agent. Provider-specific response headers are removed before the response leaves the gateway.

What the gateway records

Per app you choose off (nothing), minimal (method, path, status, latency, bytes; the default) or full (minimal plus the client user agent). Records expire after seven days. The client IP address is never stored, and request and response bodies are never written anywhere, including on error paths. Note that the hosting edge in front of the platform keeps its own access log for its retention window, as any hosted service does; the gateway cannot switch that off.

Streaming, timeouts and cold starts

Requests and responses are streamed with no buffering, so server-sent events and chunked model output pass through as they are produced. The per-request cap is 30 minutes by default and can be set between 1 and 60 minutes per app. Connections to your functions are pooled and kept alive. The gateway never retries after a request body has been sent: a failed call returns 502 and is your client's decision to repeat.

When no container is warm, the first request waits while one starts (typically one to three minutes for a large model). If the caller disconnects during that wait, the upstream call is cancelled. Apps that prefer a quick answer can set the cold-start policy to fail fast: the gateway then returns 503 with Retry-After: 30 and {"state": "cold"} if no first byte arrives within the configured wait, while the container keeps starting.

Endpoints answer 402 when the workspace is suspended or its allowance is exhausted, and resume automatically once an invoice is settled.

Configure

ts app config my-api                                   # show policy
ts app config my-api --log-mode off --headers strict   # record nothing, forward only the four core headers
ts app config my-api --allow-header x-tenant-id         # forward one extra header
ts app config my-api --timeout 60 --cold fail --cold-wait 15

The same settings are under Gateway policy on the app page.

Manage

ts app endpoints my-api     # print the URLs
ts app sync                 # refresh state, functions and endpoints for every app
ts app stop my-api          # stop; endpoints return 404 until the next deploy

The same actions are available on each app's page in the console (Sync, Stop) and on the Apps list (Sync deployments).

Billing

Deployed apps are metered by the compute they consume (GPU, CPU and memory seconds) at the published rates. Usage is posted to your ledger once an hour as a per-app daily line item and appears on the Usage page and on invoices like any other resource. An app that is idle costs nothing.

Limits

Bundles up to 32 MB. Ship models, datasets and checkpoints through a volume instead.
Web functions only are exposed over HTTP. Scheduled and queue-triggered functions still run, but are invoked from within the app.
WebSocket upgrades are not proxied yet; use server-sent events or chunked responses for streaming.
Requests are served from one hosting region today; a second region and health-checked failover are planned.