# Before your first deploy

Source: /docs/getting-started/before-your-first-deploy

This page is the whole picture in one place. Give it to your coding agent as well: it reads the same pages you do through the [MCP docs tools](/docs/mcp/tools).

## What your app needs [#what-your-app-needs]

Your app has to follow a handful of rules so the platform can build and run it. The full list with the reasons is in [What runs here](/docs/getting-started/what-runs-here); in short:

* **Build:** a common stack (Node, Python, Go, Ruby, PHP, Java, a static site) builds on its own from the project's own scripts; anything else needs a `Dockerfile` in the root.
* **Port:** the server listens on `0.0.0.0` and the port from `PORT` (the platform sets `8080`).
* **Process:** a long-lived server, not a script that exits.
* **Configuration:** keys and URLs come from environment variables, never from the repository.
* **Data:** the database comes from `DATABASE_URL`; the container disk is wiped on every deploy and restart.

The [readiness scan](/docs/concepts/readiness-and-fixes) checks these before anything is built and hands you a fix prompt when something is off.

## What the platform sets up [#what-the-platform-sets-up]

You do not configure any of this:

* **Hosting and the address.** A container on our servers, your subdomain under `apps.orbitorca.com` with a certificate, and your own domain once you [connect it](/docs/concepts/subdomains-and-domains).
* **The database.** A managed Postgres, created at your first deploy and injected as `DATABASE_URL`. Its size follows your plan.
* **Injected variables.** `PORT`, `DATABASE_URL` and, when you switch a feature on, the `META_*` keys for payments, sign-in and analytics. You cannot set these by hand and you never see their values.
* **The switched-on features.** [Sign-in](/docs/features/auth), [payments](/docs/features/payments) and [analytics](/docs/features/analytics) run next to your app and are wired through those variables and a prompt for your agent.
* **Releases.** A redeploy starts the new version next to the old one and swaps traffic only when the new one answers; a failed redeploy leaves the old version running.
* **Watching.** The platform keeps checking the app after it is live. An app that keeps crashing shows that on its page and to your agent; a failure in a part we run is reported to us, not to you.

## What you provide [#what-you-provide]

* **The code**, from GitHub or an uploaded ZIP, following the rules above.
* **Your own integration keys** (an OpenAI key, a mail provider, anything your app calls) as [environment variables](/docs/concepts/environment-variables). Take them from your local `.env`: every key your app reads locally, except `PORT` and `DATABASE_URL`, goes into the app's Environment before the deploy. Values are write-only afterwards.
* **A Stripe account**, connected through the platform, if you take payments. Your customers pay you directly; the platform never holds your keys.
* **DNS**, one record at your registrar, if you bring your own domain.

## What happens during a deploy [#what-happens-during-a-deploy]

Every deploy runs the same stages, shown live on the app page and in the agent's `get_app_status`:

1. **Scan.** The source is checked against the rules above and for leaked secrets and risky packages. A blocking finding stops here, with a fix prompt; nothing is built.
2. **Build.** The image is built from your `Dockerfile` or from the detected stack, then scanned and pushed to the platform's registry. The build log streams on the app page. Typical time: one to three minutes; a cold `npm install` or a large image takes longer.
3. **Database.** On the first deploy of an app with a database, the database is provisioned and `DATABASE_URL` appears.
4. **Start.** The container is placed on a server, the image is pulled and the process starts. The platform waits for your server to answer on the app port. A process that exits, or one that never answers on `8080`, ends the deploy here with the reason and the last lines of your log.
5. **Route and certificate.** The address is pointed at the new container and the certificate is checked. A brand-new subdomain can take a minute or two here.
6. **Live.** The app answers at its address. On a redeploy the old version is stopped only now.

If a stage fails, the app page and `get_app_status` say which one and why, and whether it is something in your app or on our side. A failure on our side needs nothing from you; try again later or ask [support](/docs/support).

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

Hand the agent the prompt from [What runs here](/docs/getting-started/what-runs-here#a-prompt-for-your-coding-agent) before the first deploy, then connect it to the platform through [MCP](/docs/mcp/overview) so it can deploy, read logs and fix what the scan finds without you copying anything by hand.