# Deploy your app

The Markdown copy of <https://yeeted.ai/docs/deploying.html>.

Once your agent is connected, deploying is a sentence.

## Builds

Your agent sends your code to Yeeted, which
auto-detects the stack (Node/Next, Vite, React, Python, PHP, Ruby, Go, static sites; in beta: Angular, Vue, Svelte, Astro, Java without a Dockerfile, C#, and Composer-based PHP),
builds it, and gives you back a live URL. Auto-detection uses a custom Dockerfile synthesizer for supported
source layouts. Unrecognized source trees fail auto-detection; include your own Dockerfile to define the build.

A Vite or React project with its own server (a start script that runs a server file, or a server entry
file plus a database driver, a port other than 80 or a required database in yeeted.yaml) builds as a Node
server that also builds the frontend. A static site is served by nginx on port 80, so a yeeted.yaml port
other than 80 fails its build with a message saying what to change, and a required database the site
cannot use gets a warning in the build log.

**Conventions:** your app should listen on `0.0.0.0` and honor the
`$PORT` environment variable. Most frameworks do this out of the box. For supported source layouts,
no Dockerfile is needed; otherwise, include one. You can also supply one to take full control.

## Preview, then production

```
// just tell your agent
"Deploy my app to Yeeted."
"Ship this to production."
"Roll back to the last working version."
```

```mermaid
flowchart LR
 A["Deploy my app"] --> B[Build]
 B --> C[Preview URL<br/>try it, share it]
 C -->|"ship to production"| D[Production<br/>always-on, blue/green swap]
 D -->|"roll back"| E[Previous version]
```

Start with a **development preview** you can share, on every plan. When you're happy, ask your agent to
promote it to **production** (Small Business plan and up, after the beta) - the *exact image you tested* is shipped live under
the same `yeeted.yaml` (port, health check, env, and a production database if it requires one, provisioned
before the app starts; if that cannot be done the promote is refused and production is left alone). The swap is
blue/green, designed to keep the previous version serving until the new one passes its health check.
Swaps are not guaranteed to be downtime-free. Use `status` to watch readiness, then use
`versions_list(project_id, service_type=production)` to confirm the promoted revision is marked running now.
Probe the production URL if availability matters. Production is kept
always-on and restarted automatically if it ever crashes. Saying
“deploy to production” promotes your tested preview when a development image exists. If no development image exists,
`deploy(service_type=production)` builds production directly from the files sent.

## Rollback

A git-hash or previous-image rollback restores a retained app image without automatically rolling back
database changes. A named production checkpoint with a captured database snapshot can also restore
supported production data except Redis on plans with snapshots if the restore succeeds. A production
rollback also moves the `prod` line of your code; see [Version control](https://yeeted.ai/docs/version-control.html#prod).