What a deployed application needs #
This page lists, in one place, what the platform needs from your application's code and files. Each section names the page that gives the detail.
The server #
Your server listens on the port in PORT, which the platform's image sets to 8080. The manifest cannot set PORT.
The platform starts the application with npm start. So the root package.json declares scripts.start, or the folder holds a server.js at its top. The application runs on Node.js 24, whatever its engines field says.
What the deploy zip holds gives the zip's contents and limits, and Node.js Runtime what the running server must do.
The health path #
The manifest's health member names an absolute path that answers 200. At each deploy, promote, restart, and platform redeploy, the platform requests it every 3 seconds for up to 180 seconds. Three 200 answers in a row pass the check, and no redirect is followed.
A deploy to an environment that serves no version yet is refused health_path_unserved where no file of the code holds the path's last segment. The deploy health check describes the check, and Choosing the health path the choice.
The manifest #
The manifest requires manifest_version, services, health, region, egress, audience, and packages. The manifest describes each member.
Settings your code reads #
A deployed copy receives the platform's own settings, such as TURNZERO_CLOUD_API and TURNZERO_CLOUD_APP_TOKEN, as environment variables. The settings a deployed copy receives lists each one.
A value that is not secret, such as a site title, belongs in your application's own code or files, which every deploy includes. The manifest's settings member binds only stored secrets (Store a secret).
A database #
Where the manifest declares a database, each running copy receives APP_DATABASE_URL, its connection string, and APP_DATABASE_CONNECTION_LIMIT, the most connections its pool may hold.
The schema lives as ordered .sql files in the application's migrations/ folder. Your application's start code applies them before the server listens, and the platform runs no migration itself. Add a database shows both ways to apply them: the Database package, or code of your own on the pg driver.
Where data lasts #
Anything the code writes to the copy's disk, /tmp and its home folder included, is lost when the copy is replaced or stops. That happens at a deploy, a promote, a rollback, a restart, and an idle stop, and whenever the platform replaces a copy. Keep files in a storage area and records in a database.
On the Free plan, production stops its copy after 30 minutes with no request. The next request, scheduled run, or deploy starts it again. The stop touches only the copy: the database and its data, stored files, and stored secrets stay as they are. How the plans differ technically gives the timing of the first request after a stop.
Related #
Deploy an application walks through a first deploy. Bring an existing application checks code written for another host against these needs.