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/Vue/Angular/Svelte, Astro, Python, PHP, Ruby, Go, Java, C#, static sites), builds it, and gives you back a live URL.

// 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, zero-downtime swap]
  D -->|"“roll back”"| E[Previous version]
      

Every deploy starts as a preview you can share. When you're happy, ask your agent to promote it to production - the exact image you tested is shipped live with a zero-downtime blue/green swap, kept always-on, and restarted automatically if it ever crashes. Saying “deploy to production” promotes your tested preview; “roll back” returns to the previous version in one step.

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.

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
• Engine-specific vars like POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB

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

Mirror to your own database

On Business plans and up, 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):

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

Test against real data

On Business plans and up, 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.”

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 Business and up
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 — blue/green, no downtime
rollback      // one call restores a known-good version by name

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

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 as a standard dump (see Databases), or keep a live mirror on your own infrastructure on Business plans and up.
• Stored safely: your code and data are kept redundantly across regions, and every production deploy can be rolled back to a previous version in one step.

Environments & domains

Development previews

A development deploy is a preview: perfect for trying a change. Previews sleep after a period of inactivity to save resources — the next request wakes it automatically (you'll see a brief “starting…” page). You can also Extend or Relaunch a preview from the dashboard.

Production

Promote to production for an always-on service with a stable URL that never sleeps and is automatically restarted if it crashes.

Your URLs

• Default: your-app-you.gateway.yeeted.ai — serves whatever you have deployed.
• Production: your-app-you.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 see what you see and fix things with you. Everything they do is recorded in your Activity feed, labelled Support — nothing happens to your account invisibly.

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, more replicas, multi-region with failover, 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.
• Developer — $10/mo: 5 projects, one live preview, a small managed database, and no deployment budget. Build and test.
• Pro — $20/mo: 30 projects, 3 running previews, managed databases across two engine types. Development only.
• Business — $50/mo: 50 projects, one production app, and larger 2 GB databases.
• High Availability — $199/mo: 50 projects, everything in Business plus redundant replicas, and your apps and databases run in two regions with automatic failover.
• Enterprise: dedicated capacity and custom terms — talk to us.

FAQ

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

No. Yeeted auto-detects your stack and runs it. A Dockerfile or yeeted.yaml is optional if you want more control.

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 roll back, or redeploy a previous build from the dashboard.

Can I take my code and data somewhere else?

Always. Download your source as a tar.gz from the Projects tab, export any database as a standard dump file, or keep a live mirror of your database on your own infrastructure (Business and up). 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