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 checks most of them before you ship.

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

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

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

Read keys, passwords and URLs from environment variables. Set your own integration keys (like OPENAI_API_KEY) in the app's 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

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 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

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

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

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

A prompt for your coding agent

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

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

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