# What runs here

Source: /docs/getting-started/what-runs-here

The platform builds your app from a `Dockerfile` and runs it in a container behind a gateway. Follow these rules and it deploys. The [readiness scan](/docs/concepts/readiness-and-fixes) checks most of them before you ship.

## The rules [#the-rules]

### A Dockerfile in the root [#a-dockerfile-in-the-root]

There must be a `Dockerfile` in the **root** of your repository or ZIP, not in a subfolder. It starts with a `FROM` line and has a `CMD` or `ENTRYPOINT` that starts your server. Without it there is nothing to build.

### Listen on the port the platform gives you [#listen-on-the-port-the-platform-gives-you]

The platform starts your container with the environment variable `PORT` set to `8080` and routes traffic to it. Your app **must** listen on `0.0.0.0` on that port — read `process.env.PORT` (or your language's equivalent) rather than hardcoding.

Listening on `127.0.0.1` or `localhost` makes the app unreachable and the deploy fails. `EXPOSE` in the Dockerfile does not affect routing; the real listening port is what counts.

### Be a long-lived server [#be-a-long-lived-server]

The process must keep running. A script that starts, does its work and exits is treated as a failed deploy. This is a web server, not a one-shot job.

### Configuration from environment variables, no secrets in the repo [#configuration-from-environment-variables-no-secrets-in-the-repo]

Read keys, passwords and URLs from environment variables. Set your own integration keys (like `OPENAI_API_KEY`) in the app's [environment variables](/docs/concepts/environment-variables); the platform stores them and injects them at deploy. Never commit secrets.

Some keys are reserved and injected for you — `PORT`, `DATABASE_URL`, and the `META_*` keys. You cannot set those by hand.

### Use the database the platform provides [#use-the-database-the-platform-provides]

If your app needs a database, read the connection string from `DATABASE_URL`. The platform provisions a managed Postgres and injects it. Do not run your own database inside the image, do not point at `localhost`, and do not commit credentials.

`DATABASE_URL` appears at your **first deploy**, not the moment you create the app. Keep your own tables and migrations in the `public` schema; you have full rights there. An app that needs no database (a static site) can turn the database off in settings.

### The `/__meta/*` path is reserved [#the-__meta-path-is-reserved]

The path `/__meta/*` on your app's domain belongs to the platform and is handled before the request reaches your app. Do not define routes under it.

### The `auth` schema belongs to the platform [#the-auth-schema-belongs-to-the-platform]

If you turn on user accounts, an `auth` schema appears in your database with the end-user tables. Your app has read-only access there — you can join your records by `user_id`, but not write. Keep your own tables in `public`.

### The container disk is temporary [#the-container-disk-is-temporary]

Your app is stateless. The container filesystem is a scratch space: every deploy and restart starts from a clean image, and anything written to disk is lost. Store everything that must survive in your database. Writing to `/tmp` during a request is fine — it just will not persist.

### Optional: a health endpoint [#optional-a-health-endpoint]

A `/healthz` endpoint helps diagnostics. By default the platform does a TCP check on port `8080`.

## A prompt for your coding agent [#a-prompt-for-your-coding-agent]

Paste this into the agent that builds your app (Cursor, Lovable, and similar):

```text
Prepare this app for deployment on the platform:
1. Add a Dockerfile in the root: FROM, install dependencies, CMD that starts the server.
2. The server must listen on 0.0.0.0 and the port from process.env.PORT (the platform sets PORT=8080). Do not hardcode another port.
3. It must be a long-lived HTTP server, not a one-shot script.
4. Read all keys and secrets from environment variables. Do not commit them.
5. If the app uses a database, connect via process.env.DATABASE_URL (a managed Postgres). Do not run your own database in the container, do not point at localhost, keep your tables in the public schema.
6. Do not define any routes under /__meta/*; that prefix belongs to the platform.
7. Do not write persistent data to disk (uploads, SQLite, files); the container filesystem is ephemeral and resets on every deploy. Keep everything that must survive in the database.
Then commit and push.
```

## Checklist before every deploy [#checklist-before-every-deploy]

* `Dockerfile` in the root, with `FROM` and `CMD`/`ENTRYPOINT`
* App listens on `0.0.0.0:8080` (reads `$PORT`)
* Long-lived server (the process does not exit)
* No secrets in the repo; config from environment variables
* Database, if used, via `DATABASE_URL` — not your own, not `localhost`
* No routes under `/__meta/*`
* Persistent data in the database, not on disk