AI APP DEPLOYMENT GUIDE

Test an AI-built app before you promote it

AI coding agents move quickly. A deployment workflow needs a safe place to validate their changes before real users see them. Yeeted AI deploys a development preview first, then promotes the exact image you tested to production.

Preview first

Ask your MCP-enabled agent to deploy the current project to Yeeted. The returned preview URL is the place to check the user flow, API response, health check, and logs. If the build or runtime fails, use diagnostics to distinguish a code error from a platform or dependency issue before editing.

Promote the tested version

After a preview passes your checks, tell the agent to promote it to production. Production apps need the Small Business plan or higher (after the beta); every plan can deploy previews. Yeeted uses a versioned deployment model, so the build is not recreated between test and release. If a regression appears, ask the agent to restore app code from a named checkpoint or retained git hash. A git-hash rollback changes app code only; database changes are not automatically rolled back. 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. Check the rollback result.

Make your app deployable

Listen on 0.0.0.0 and use the supplied $PORT.
Use a health-check endpoint when your framework needs one.
Request a managed database or configure runtime settings in yeeted.yaml. For an unrecognized source layout, include your own Dockerfile; yeeted.yaml does not add build support.
Store credentials as secrets rather than in source code.

Yeeted is currently a beta service. Maintain independent backups and use it for testing and development rather than mission-critical applications.

Continue

Start with the MCP deployment guide, then consult the full deployment documentation.