---
title: What a deployed application needs
description: What your application's code and files must provide to deploy and run: the port, the start, the health path, the database settings, and where data lasts.
slug: /concepts/what-a-deployed-application-needs
order: 23
visibility: public
redirects_from: []
---

# 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](/concepts/what-the-deploy-zip-holds) gives the zip's contents and limits, and [Node.js Runtime](/backend-packages/nodejs-runtime#what-an-application-must-do) 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](/concepts/glossary#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](/concepts/the-deploy-health-check) describes the check, and [Choosing the health path](/guides/author-the-manifest#choosing-the-health-path) the choice.

## The manifest

The manifest requires `manifest_version`, `services`, `health`, `region`, `egress`, `audience`, and `packages`. [The manifest](/concepts/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](/concepts/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](/getting-started/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](/guides/add-a-database#4-keep-the-schema-as-migrations) 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](/guides/store-files) 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](/concepts/how-the-plans-differ-technically#start-after-idle-and-response-time) gives the timing of the first request after a stop.

## Related

[Deploy an application](/getting-started/deploy-an-application) walks through a first deploy. [Bring an existing application](/guides/bring-an-existing-application) checks code written for another host against these needs.