The settings a deployed copy receives

A setting is an environment variable a deployed copy reads: a named value the platform places in the copy's environment, which your code reads from process.env. This page lists every setting a deployed copy receives, and describes the image and the controls the copy runs under.

Settings and environment variables a deployed copy receives

This section is the one list of the settings, the environment variables, the platform injects into a deployed copy. A deploy sets these settings on the copy of the environment it reaches, and a promote sets them on the production copy. A platform redeploy and a restart_application set them again on the copy they re-create. Your code may read every setting in the table.

A platform re-creation made while the plan's connection limit is not set includes no APP_DATABASE_CONNECTION_LIMIT, and your log gets a warn event saying so. A pool reading the setting as the Database package's composer does then uses one connection until the next deploy, promote, or restart_application.

Setting What it contains When it is present Code may read it
TURNZERO_CLOUD_API The platform origin, for sign-in, management calls, and read_account. Always. Yes.
TURNZERO_CLOUD_APPLICATION The application's identifier, the value create_application returned. Always. Yes.
TURNZERO_CLOUD_GATEWAY_URL The origin for storage, egress, and logging calls. Without it, send those calls to TURNZERO_CLOUD_API. Where the platform gives a separate origin. Yes.
TURNZERO_CLOUD_REALM_KEYS The end-user realm's public key set, as JSON. Where the environment has a realm. Yes.
TURNZERO_CLOUD_TOKEN The environment's platform credential, the bearer for storage, egress, and logging calls. It is kept secret. Always. Yes.
APP_DATABASE_URL The database connection string, with its password. It is kept secret. Where the environment has a database. Yes.
APP_DATABASE_CONNECTION_LIMIT The plan's connection_limit, the database connections each process may hold open at once: set the client pool's maximum to it. The role accepts twice that number. Where the environment has a database. Yes.
APP_ENVIRONMENT development or production. Always. Yes.
APP_VERSION The version applied, the integer read_status and list_versions show. Always. Yes.
APP_PUBLIC_HOST The environment's public hostname, never the request's Host. After a rename, the rename's restart writes the new hostname; where the restart is refused, it keeps the old one until the next deploy or promote. Always. Yes.
PORT 8080, the port the server listens on. Always. Yes.
HTTPS_PROXY, HTTP_PROXY, NO_PROXY The proxy settings, in upper and lower case, for a client that needs an explicit proxy agent. The runtime harness sets them at start, so read them at run time. Where outbound calls go through the platform's proxy. Yes.

A running copy keeps the values it started with. After set_plan moves the plan, or platform staff change the plan's value, APP_DATABASE_CONNECTION_LIMIT takes the new value at each environment's next deploy, promote, or restart_application. Add a database says what a move to a smaller plan does before then.

No setting contains an issue-tracking space or its token. A backend reaches its application's space through the egress gateway, which presents the space's token for it; the Issue Tracking package states how.

The platform sets other settings for its own use, and your code never reads them: HOSTING_WINDOW_REQUEST_SECONDS, HOSTING_WINDOW_SCHEDULE_SECONDS, HOSTING_WINDOW_GRACE_SECONDS, HOSTING_SCHEDULE_PATHS, EGRESS_PROXY, EGRESS_PLATFORM_ENDPOINTS, APP_ASSETS_BASE, NODE_OPTIONS, and npm_config_update_notifier.

The router mark's setting, ROUTER_MARK_SECRET, is the platform's too. In a version built with the current harness, the harness removes it from the environment before your request listener runs. Where the harness cannot write its file, it keeps the setting and writes one router_mark_setting_kept line under container.

A version built with an earlier harness keeps the setting until a new deploy. On two environments, production keeps it until that new version is promoted. read_status and list_versions return harness_current per version, which shows the versions behind.

A value you store with store_secret is not a setting unless the manifest binds it. The egress gateway applies an upstream's key at its edge on a call to the upstream declared with its name, and the key never enters the copy.

The manifest's settings member adds your own settings to the table's. Each gives a setting and the stored name whose value the setting receives, and your code may read it. The deploy and the promote read the value stored for their environment and inject it, kept secret like the platform credential.

A platform redeploy re-applies the settings the running copy was started with, and leaves out one whose stored name is gone, writing a warning to the application's log. Where the name still exists and the store does not respond, the redeploy ends failed bound_setting_unreadable, and the running copy keeps running. Store a secret states how to bind one.

A declared upstream's settings add one or two more, and your code may read them. The base-URL setting contains the gateway's address for that upstream. The key setting contains an egress key, kept secret: a credential the platform creates for that upstream and this copy alone. The deploy, the promote, and a platform redeploy each create fresh egress keys from the upstream declarations existing then. Call an external API with an API key shows how an unchanged SDK uses them.

What the application runs under

The deployed backend runs under the platform's hosting and network controls. An application can return APP_VERSION, its version number, on its health path to show which version responds. The copy receives its own identifier as TURNZERO_CLOUD_APPLICATION, so code that declares a storage area bound to the application reads it there, not from a copy in the code.

The running image is Docker Hub's node:24-bookworm-slim, pinned by digest: Node.js 24 and its npm, /bin/sh for npm start, and a minimal Debian 12 on Linux x64 with glibc. It contains no compiler, git, Python, or curl.

It runs JavaScript, code compiled to JavaScript or WebAssembly, and native modules. A native module is compiled on node:24-bookworm at the image build or prebuilt for Linux x64 with glibc, and can use only the slim image's shared libraries. The build loads each one and fails on one that does not load (the load check). A module opening a library only at first use fails at that use.

Egress firewall and request limits explains the network controls, the request deadline, the limits, and the diagnostic records.