Deploy your app

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.

Preview, then production

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

flowchart LR
  A["Deploy my app"] --> B[Build]
  B --> C[Preview URL
try it, share it]
  C -->|"ship to production"| D[Production
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.