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.

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; 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 checks these before anything is built and hands you a fix prompt when something is off.

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.
• 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, payments and 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

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

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.

A prompt for your coding agent

Hand the agent the prompt from What runs here before the first deploy, then connect it to the platform through MCP so it can deploy, read logs and fix what the scan finds without you copying anything by hand.