Yeeted deployment docs

Yeeted hosts your AI-built app - database, logs, domains, the lot. You never touch a server: just tell your agent to deploy. This guide covers everything you need to ship and run an app.

There are two ways to get going:

// your agent's MCP config
{
  "mcpServers": {
    "yeeted": { "type": "http", "url": "https://mcp.yeeted.ai/mcp" }
  }
}

Example applications

Run and deploy a FastAPI polling API, a Next.js blog, or a React and Express service group. Each guide includes source, local setup, verification, and limitations. Browse the full example catalog.

Deployment guides for AI coding agents

Choose the guide that matches how you build. Each one explains the MCP connection, preview-first deployment flow, and production promotion.

• MCP deployment hosting
• Deploy with Claude Code
• Deploy with Cursor
• AI app previews and production deployment

Deploy your app

Once your agent is connected, deploying is a sentence. 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.

// 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. 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.

The yeeted.yaml file

Add an optional yeeted.yaml to your project's root to tell Yeeted exactly how to run your app, instead of relying on auto-detection. Every field is optional. If you're using an AI agent, ask it to “add a yeeted.yaml” and it will generate one for you.

name: my-app
port: 8000                 # the port your app listens on
service_type: development  # development (test preview - start here) or production (always-on)
replicas: 2                  # production instances (clamped to your plan; dev is always 1)

database:                  # request a managed database
  required: true
  engine: postgres         # postgres | mysql | mariadb | mongodb | redis

depends_on:                # other Yeeted projects this one needs (see Project dependencies)
  - my-api

env:                       # config injected into your app
  LOG_LEVEL: info

health_check:              # how Yeeted knows your app is healthy
  path: /healthz
  initial_delay_seconds: 5

When you deploy, Yeeted reads the file, creates any database you asked for and injects its connection details, applies your env and port, and waits for your health check to pass before sending traffic. If the file has a mistake, your agent gets a clear message telling it what to fix.

Databases

Yeeted runs managed databases for you - MySQL, Postgres, MariaDB, MongoDB, and Redis. Each project gets its own database and credentials; you never provision or patch a server. Databases come with the Beta plan, and with the Developer plan and up once paid plans open; the Free plan has none.

Attach one

Ask your agent, or declare it in your yeeted.yaml (above). For example:

"Give my app a Postgres database."
"Attach Redis for caching."

Connect to it

Yeeted injects the connection details into your app as environment variables, so your code just reads them:

• DATABASE_URL - a ready-to-use connection string for Postgres, MySQL and MariaDB; MongoDB and Redis get MONGODB_URL and REDIS_URL instead
• Engine-specific vars like POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB
• Redis only: every key your app uses must start with REDIS_KEY_PREFIX; the instance refuses any other key

You can see and manage every database from the Databases tab in your dashboard. Storage and memory limits depend on your environment and plan (see Plans & limits).

Export a database

Your data is yours to take anywhere. Click Export on a Postgres, MySQL, MariaDB or MongoDB database (or ask your agent to “export my database”) and you get a download link to a standard dump file that imports into any compatible database - on Yeeted or anywhere else. Links expire after an hour, and each database can be exported about once an hour. Available on every plan that includes a database. Redis can't be exported: one instance holds every project's keys, so it can't dump yours on their own.

Mirror to your own database

On Small Business plans and up (after the beta), Yeeted can keep a database of your own - your RDS instance, your own server, another provider - continuously up to date with your Yeeted database. Set a target connection URL and a sync interval (every 15 minutes by default). Postgres, MySQL, MariaDB and MongoDB can be mirrored; Redis cannot be mirrored, because it has no per-project dump:

"Replicate my postgres to postgres://user:[email protected]:5432/mirror"

flowchart LR
  A[(Your Yeeted database)] -->|"sync every 15 min"| B[(Your own database
RDS · your server · anywhere)]
      

Each sync refreshes only your project's own tables on the target - anything else living in that database is left alone. Check sync status any time from the Databases tab or by asking your agent to list databases; stop any time with “stop replicating” (your copy keeps whatever was last synced).

Rotate a password

Click Rotate password on a database (or ask your agent) whenever a credential may have leaked — or just as routine hygiene. A new credential is issued immediately and the old one stops working; redeploy right after so your app picks up the new connection details. The new password is shown once, in case you use it outside Yeeted.

Delete a database

Click Delete on a database (or ask your agent, which uses the database_delete tool and must get your go-ahead first). Deleting drops that project's database, its user and all of its data from the server, permanently, so download a copy first if you may need it (Export works for every engine except Redis). You confirm by typing the database's name. Only the database goes: the database server keeps running and other projects' databases are untouched. Copies taken earlier are not deleted with it: an export link lasts about an hour, automatic pre-restore and pre-move snapshots are kept for 14 days, and checkpoint snapshots stay with their checkpoint, so you can attach a new database and restore one while it exists. If your yeeted.yaml still asks for the database, the next deploy creates a new, empty one.

A live app of the project in that environment (running, starting, deploying or building, crashlooping, a failed deploy whose previous version still serves, or held) has to be stopped first: Delete is refused while one is live and tells you which. Stop the service with Stop on the dashboard's Services page, or one version with its Stop in the Versions table on the service page (no MCP tool stops a deployment). A held app was stopped by Yeeted's enforcement and comes back when the hold is released: contact support to resolve the hold first. A stopped app does not block, but a stopped development app wakes on its next request and any stopped app can be started again, and then it comes back without this database (or with a new, empty one if its yeeted.yaml asks for one). Delete is also refused, with nothing deleted, while the database syncs to a database of your own (stop the sync first), while it is busy with another operation or its server is under maintenance or failing over, under a legal hold, or while the server's standby copy is unreachable. On a server with a standby, the database's login is removed there too.

Test against real data

On Small Business plans and up (after the beta), every development preview gets its own test database seeded with a snapshot of your production data — so you test against real-shaped data while real users are never touched. Refresh it on demand: “refresh my test data.” Redis is not copied from production.

Yeeted in AI development loops

Yeeted isn't just reachable by an agent — it's designed to be the deploy-and-verify half of an autonomous coding loop. Every tool result is structured for a model to act on, so an agent can build, ship, test, diagnose, fix, and promote without a human unblocking it.

The loop

The intended cycle, all over MCP:

// the agent's iteration cycle
validate      // dry-run: stack detection, port, missing-database warnings — before any build
deploy        // to development (default): a safe test space, seeded from prod data on Small Business and up (after the beta)
smoke_test    // platform-side HTTP probes against the live dev URL
diagnose      // one internally-consistent verdict + recommended_action when anything looks off
promote       // the EXACT tested image goes live under its yeeted.yaml; health-gated blue/green
rollback      // retained git hash: app only; data-bearing production checkpoint: data may restore too

Blameless failure classification

The most expensive agent failure mode is misattribution: a platform hiccup that the agent "fixes" by rewriting healthy code. Every Yeeted failure carries two machine-readable fields:

{
  "cause_category": "build_error | crash | health_check | image_missing | platform | dependency",
  "self_fixable":   true | false
}

self_fixable: false means do not touch the app — retry or wait, it's ours. When it's the code, the failure includes the file and line parsed from the stack or compiler output, so the agent's next edit is aimed, not guessed. Errors are also flagged new since the last deploy, which is the signal for "roll back" versus "fix forward."

Safe retries, safe batches

Deploys are idempotent by content: re-sending identical files returns the existing deploy instead of stacking a second build, so an agent retry loop can't stampede the pipeline. For batch work, project_context reports the platform's live capacity headroom ("development: room for ~6 more instances") so an agent can pace itself — and a deploy sent with queue_on_capacity: true parks on a capacity miss and places automatically when a slot frees (bounded wait), instead of failing the tail of the batch.

Memory for the loop

Every deploy is a numbered version with its source snapshotted. versions_list is the agent's deploy log, whats_changed diffs any two versions, and checkpoint names a known-good state to return to. A fresh agent session starts with one project_context call and has the whole picture: status, URL, versions, databases, secret names, health, and capacity.

Secrets

API keys, signing secrets, that SECRET_KEY_BASE your framework wants — store them as secrets instead of hard-coding them. Secrets are injected into your app as environment variables on its next deploy.

"Set a secret STRIPE_API_KEY on my app."
"List my secrets."
"Delete the STRIPE_API_KEY secret."

Or use the Secrets tab in the dashboard. Two things to know:

• Values are write-only - not even Yeeted can read them. Once set, a secret's value can never be read back: not from the dashboard, not by your agent, and not by anyone at Yeeted - support engineers and administrators included. No one at Yeeted can ever view a secret's value or your database passwords. You'll see the name, when it changed, and what uses it; never the value. Keep your own copy if you'll need it elsewhere.
• Names become env vars, so they're UPPER_SNAKE_CASE (e.g. STRIPE_API_KEY). Setting an existing name replaces the value; the change lands on your next deploy.

The Secrets tab also shows the credentials Yeeted manages for you - your database passwords and platform-held keys - so you always know what exists, even though no one can view the values.

Project dependencies

Apps that need each other can say so. Add depends_on to your yeeted.yaml (or ask your agent to “make this app depend on my-api”), and when you deploy, Yeeted brings the dependencies up first — including dependencies of dependencies, all the way down — as far as your plan's running-app capacity allows.

depends_on:
  - my-api
  - my-worker

flowchart TD
  shop[my-shop] --> api[my-api]
  shop --> worker[my-worker]
  api --> db[(managed postgres)]
  worker --> queuecache[(managed redis)]
      

The full dependency tree is visible on each service's page in the dashboard. If a dependency can't start — say you're out of capacity — the deploy tells you exactly which one and why, so you can stop something else, or switch to the Beta plan if you are on Free.

Your code & 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.
• 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.
• 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.

Environments & domains

Development previews

A development deploy is a preview: perfect for trying a change. A preview runs for 15 minutes after each deploy or wake, and traffic does not extend it. When the time is up it stops to save resources, and the next request wakes it automatically (you'll see a brief “starting…” page). From the dashboard you can Extend a running preview to restart its timer, or Relaunch a stopped one.

Production

Promote to production for an always-on service with a stable URL that has no timer and is automatically restarted if it crashes. Production is included on Small Business (1 app) and High Availability (10 apps); neither is on sale during the beta.

Your URLs

Every app gets a hostname made of its project name and your account's short id, such as your-app-a1b2c3d. Each deploy hands your agent the exact URL.

• Default: your-app-a1b2c3d.gw.yeeted.ai: serves whatever you have deployed.
• Production: your-app-a1b2c3d.prod.yeeted.ai: always serves your production deployment, never a preview, so it's safe to share with real users.

Logs & metrics

Every service has a full observability page: click any service in the dashboard to open a tabbed view with everything about it in one place.

• Logs — build output, your app's console, system messages, and a request log of the traffic hitting your service (method, path, status, latency) without adding any instrumentation.
• Service metrics — CPU, memory, and disk I/O for your deployment, per environment.
• HTTP traffic — your 2xx/4xx/5xx counts, split into responses your app gave versus responses Yeeted answered for it (like the brief “starting…” page while a preview wakes). When a graph goes red, you can immediately tell whether it's your code or not.
• Builds — the build history behind the service, newest first.

Your agent can read logs too — just ask “show me the logs” or “why did that build fail?” and it can pull them to help debug and ship a fix.

Managing your app

From the dashboard you can:

Open your dashboard →

Activity & support

The Activity tab is a complete record of your account: every deploy, delete, secret change, database action, and login-adjacent event, with who did it, from where, and whether it succeeded. If something looks unfamiliar, you'll see it here.

When you ask Yeeted for help, a support engineer may open a temporary support session on your account to look at your projects and fix things with you. Your code, data, logs and metrics stay hidden in that session unless you allow them (see below). Everything they do is recorded in your Activity feed, labelled Support, with one exception: an administrator's abuse or legal override is recorded in our staff audit trail but not shown to the account under investigation.

Data access is your choice, and it is off by default. On the dashboard's Profile page, under Data access, you decide whether Yeeted staff may see your code, data, logs and metrics, and why: not at all (the default), for support purposes only (to diagnose and fix problems you report or that affect your service), or also for platform enhancements that better support your code, such as speeding up your builds and deployments or running test deployments to verify reliability. Without it, our support tools refuse to show us that content, even in a support session, and we may need you to allow it before we can help with a problem in your app. A change takes effect immediately. Running your apps, and showing you and your agent your own logs and metrics, is not affected. An administrator can override the choice only for abuse or legal reasons, with a recorded reason. The Privacy Policy has the details.

Plans & limits

One flat monthly price per plan — no hourly billing, no bandwidth charges, no overages. Bandwidth is unmetered under a fair-use policy: we monitor per-project traffic, and a project sustaining exceptionally high egress (order of 100 GB/day) may be throttled to protect other tenants — you will see a notice on your Logs tab first, and you will never receive a bandwidth bill. Higher plans allow more projects, always-on production (Small Business and up, after the beta), more replicas, and larger databases. Each plan caps how many projects you can have (project records — apps you've created), separately from how many can be running at once. See the full breakdown on the pricing page.

• Free ($0): 5 projects, one live preview, and a budget of 5 deployments and builds. No card. Every account starts here, and cancelling any plan returns you here.
• Beta ($0): the plan to pick while we are in beta. Pro's scope at no cost and with no card: 30 projects, 3 running previews, managed databases across two engine types, on a smaller 500 MB build image allowance. Development only. Choose it on the Billing page after you sign up.
• Yeeted is for testing and development, so please don't run anything mission-critical on it yet. While we're in beta, expect occasional downtime, and we may need to reset projects or data. Keep your own copy of anything you can't afford to lose. We can't promise support response times during the beta, but we read every piece of feedback and are happy to help where we can. The free plans (Free and Beta) come with no SLA or uptime guarantee during the beta. See the Terms.
• Developer ($10/mo, not available during the beta): 5 projects, one live preview, a small managed database, and no deployment budget. Build and test.
• Pro ($20/mo, not available during the beta): 30 projects, 3 running previews, managed databases across two engine types. Development only.
• Small Business ($50/mo, not available during the beta): 50 projects, one production app, and larger 2 GB databases.
• High Availability ($199/mo, not available during the beta): not yet available to buy. 50 projects, up to 10 production apps with up to 2 replicas each, larger 4 GB databases, and everything in Small Business.
• Enterprise: dedicated capacity and custom terms; talk to us.

FAQ

Do I need to know how to use a server or Docker?

For supported source layouts, your agent can deploy without a Dockerfile. Yeeted auto-detects common stacks; unrecognized layouts need a Dockerfile. An optional yeeted.yaml configures runtime settings, but does not add support for an unrecognized stack.

Which AI agents work with Yeeted?

Any MCP-compatible agent — Claude, Cursor, and others. Paste the connection URL from Getting started and you're set.

Can I roll back?

Yes. Ask your agent to restore a retained app image by git hash or named checkpoint, or redeploy a previous build from the dashboard. A plain image or git-hash rollback does not automatically roll 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. Check the rollback result.

Can I take my code and data somewhere else?

Always. Download your source as a tar.gz from the Projects tab, export any database except Redis as a standard dump file, or keep a live mirror of your database on your own infrastructure (Small Business and up, after the beta; not Redis). No exit permission required.

Can support see my secrets or passwords?

No one can see secret values or passwords - they're write-only, for everyone. Support can see which secret names exist to help you debug, and anything support does shows up in your Activity feed.

Can real users hit my app?

Yes. Promote to production and share your prod.yeeted.ai URL — it always serves your production deployment.

Get started Back to home