# 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](https://yeeted.ai/docs.html).
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:

```sh
git clone https://github.com/Yeeted-AI/examples.git
cd examples
```

Choose an example from the [catalog](index.md). 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
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.