HOSTING FOR AI-BUILT APPS
Deploy an example on Yeeted
Yeeted is a hosting platform for AI-built apps. Your coding agent deploys and manages your app, databases, logs, domains, and rollbacks from the conversation. These examples are small applications you can inspect, run locally, and deploy to learn that workflow.
Before you deploy
Use a Yeeted account with a verified email and a beta invite. Connect your coding agent using the Yeeted documentation. An authorized agent connection does not create an account. Check your plan's project and deployment limits before starting; a group needs multiple services.
Get the public examples repository:
git clone https://github.com/Yeeted-AI/examples.git
cd examples
Choose an example from the catalog. Commands in each guide run from that example's directory, unless the guide says otherwise. Deploy that directory as the source root, including its manifest, migrations, and lockfiles. Do not upload the entire platform repository or local credentials.
Ask your agent to deploy a preview
Use this prompt with the chosen example open in your workspace:
Deploy this example to a new Yeeted development project. Inspect the available tools and account limits first. Read its README and yeeted.yaml, attach the required PostgreSQL database, and upload this example directory. Follow the deployment status until it finishes, then give me the preview URL and run the documented smoke test. Diagnose any failure using the build and runtime logs.
Static examples and the Java and OS examples do not require a database. The React/Express notes example is a group: follow its guide to deploy the API and web directories separately with their shared topology. Redis is optional in the Go and notes examples; a cache declaration alone is not proof that Redis has been provisioned or tested.
Verify the running app
Use the URL returned by your deployment, not an invented sample hostname. From the example directory:
sh smoke.sh "$PREVIEW_URL"
Set PREVIEW_URL to your actual preview URL first. The notes group has its
smoke script under api/ and must be checked through the web service's URL.
Smoke tests for writable apps create test data. Use a disposable development
database and read the guide's expected results before running them.
Unit tests, a successful build, a healthy process, and a successful user flow prove different things. In-memory or SQLite tests do not establish PostgreSQL behavior. A smoke check does not establish load capacity or security readiness. These guides describe expected behavior from the source; they are not a record of a completed live deployment or a performance benchmark.
Try a change and a rollback
Record the working deployment's version. Change a visible label, deploy another preview, and repeat the checks. Ask the agent to roll back to the recorded version and verify the original behavior returns. Promote a tested version only when you intend to publish it.
An application rollback does not automatically undo database migrations or restore deleted data. Use backward-compatible schema changes and keep independent backups. Yeeted is in beta and intended for testing and development, not mission-critical workloads.
Adapt the example
The writable demos do not implement user accounts or access control. Add those before using one to collect real users' data. Local in-memory stores are lost on restart; local SQLite files are development conveniences. Use the managed database declared by the example when checking persistence on Yeeted.
When finished, remove the disposable deployment and any attached resources you no longer need. Confirm database cleanup separately rather than assuming that removing an app removes its database.