Yeeted
How it works Agent loop Under the hood Plans Docs Log in Get started

ACCOUNT

Your code and data

Nothing on Yeeted is locked in.

  • Download your source any time: the Source button on the Projects tab hands you a tar.gz of the code behind any deploy, including a specific past revision.
  • Clone it with git from git.yeeted.ai, with every branch and its history; see Version control.
  • Link a GitHub repo to a project (“link this project to github.com/me/my-app”, or from the project page) and the dashboard shows a browsable link to your repo alongside the project.
  • Deploy from your own repository: connect it with push-to-deploy and every push to its branch deploys. Repositories are connected over https on github.com, gitlab.com, bitbucket.org or codeberg.org, and Yeeted checks the address answers as a git repository before saving it. While a project is connected its code lives in your repository, so edit it there and push; Yeeted's own code edits for that project are turned off until you disconnect it.
  • Rewritten history is not applied automatically. If a push rewrites the branch's history (a force-push), Yeeted does not deploy it and keeps the code it already has; the project page tells you. If you meant to rewrite it, have your agent run project_repo again for the same repository with accept_rewrite=true, then push again. If you did not, restore the branch and check who can push to it.
  • Export any database except Redis as a standard dump (see Databases), or keep a live mirror on your own infrastructure on Small Business plans and up, after the beta (any engine except Redis).
  • Rollback targets: retained app images can be restored by git hash or checkpoint name. Git-hash rollback restores 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.