Managed Hosting

Managed hosting puts your project on the public web at https://<slug>.yolo.host in one move — straight from a workspace, with no separate hosting account, no DNS, and no infrastructure to wire up. Static sites and dynamic Workers ship through the same path.

What it is

You build a project inside a workspace, then run yolo deploy. YOLO detects the project shape, bundles it, uploads it, and serves it at a yolo.host subdomain. Behind the scenes every deploy is backed by Cloudflare Workers running in YOLO’s own account — you never touch a Cloudflare dashboard or manage credentials.

Each ship produces an immutable release with its own preview URL. Your production hostname (<slug>.yolo.host) is just a pointer to one release, so promoting a verified release to production (the deploy.ship MCP tool with that release’s releaseId), or rolling back, is a metadata change with no rebuild. Nothing re-uploads.

Every successful deploy automatically captures a screenshot thumbnail of the deployed site. The thumbnail appears on the release card in the hosting console and in the deploy history, giving you a visual snapshot of what was live at each release without having to re-open old preview URLs.

The deploy flow

# Once per project: allocate a slug and write the link file
yolo deploy init
 
# Build if your project needs it, then ship a preview
yolo deploy
 
# Verify the preview URL, then ship to production
yolo deploy --env prod

yolo deploy init allocates your subdomain and writes a .yolo/deploy.json link file into your repo. Commit that file — it carries no secrets and it’s how future sessions, teammates, and CI ship to the same project instead of forking a new subdomain.

A bare yolo deploy is the ship command: it detects the project, builds it if needed, bundles it, and uploads it as a preview release at <slug>--r<n>--<ns>.yolo.host (<n> is the release number, <ns> a short per-project token). Open the preview URL, confirm it works, then go to production.

yolo deploy --env prod is a fresh ship straight to production: it rebuilds and bundles the current working directory (only changed assets upload) rather than promoting the preview you just checked. To put the exact preview release live with no rebuild or re-upload, promote it by releaseId with the deploy.ship MCP tool (see Deploying with agents).

Core commands

Add --json for machine-readable output — every subcommand accepts it except yolo deploy link and yolo deploy dev.

Production approvals

Operator approval for production ships is built in but not currently enabled on YOLO Host: today a production ship (or promote) goes live as soon as it finishes, and the release records that it was auto-approved.

When approvals are switched on, shipping to production (yolo deploy --env prod) does not fail — it parks awaiting confirmation (the CLI prints PENDING and exits with code 3). You approve the production ship in the YOLO Studio webapp (a notification card or the approvals panel), then rerun yolo deploy --env prod; the staged bundle is finalized without being rebuilt or re-uploaded. Approvals are single-use and expire after 45 minutes. Preview ships are never gated, so iterate freely on a preview URL.

Incremental redeploys are cheap

The ship protocol only uploads assets whose contents have changed since the last release — unchanged files never leave the workspace. Re-shipping after a small edit is the intended hot loop, so deploy early and often.

Supported projects

YOLO auto-detects most projects from a wrangler config, a package.json build script, or a static output directory. When detection is ambiguous, yolo deploy init --type static|worker pins the shape in .yolo/deploy.json.

The .yolo/deploy.json link file

yolo deploy init and yolo deploy link write this file; you normally never edit it by hand. Commit it — it carries no secrets (the credential is your session, and projectId is ownership-checked server-side on every call) and it’s how future sessions, teammates, and CI ship to the same project. Schema (only $version is required by the schema; a ship additionally needs projectId, which init / link write for you; everything else is optional and filled in by detection or your flags):

{
  "$version": 1,                      // schema version — always 1
  "projectId": "66f1c0e2a9…",         // the durable link to your project (24-char hex id)
  "slug": "sushi-rescue",             // informational; the server is source of truth
  "type": "static",                   // "static" | "worker" — pins detection
  "build": {
    "command": "npm run build",       // build run before bundling
    "outputDir": "dist"               // static output dir (relative to repo root)
  },
  "worker": {
    "entry": ".vinext/worker.js",     // worker module (built or source)
    "prebuilt": true,                 // ship `entry` as-is, skip esbuild
    "assetsDir": ".vinext/assets"     // static assets shipped alongside the worker
  },
  "compatibilityFlags": ["nodejs_compat"],  // e.g. Next.js needs this
  "bindings": [                       // expected resource bindings (advisory)
    { "kind": "d1", "binding": "DB" }
  ]
}

Fields are written in that fixed order. A static project uses build + omits worker; a worker project uses worker (and optionally build).

Limits worth knowing

• 25 MiB per file is a hard limit — host large media in an R2 bucket or external storage instead of shipping it as a static asset.
• Worker bundles must be 10 MiB or less uncompressed. A module over 1 MiB gzipped still ships, but the CLI warns that cold starts will suffer.
• Up to 20,000 files and 256 MiB of total assets per deploy (the CLI refuses a larger bundle before uploading). Plan-based caps (releases per day, project and data-store counts) exist but are not currently enforced.
• Slugs are 3–40 characters, lowercase letters, numbers, and hyphens (no leading or trailing hyphen). A handful of reserved names (www, api, admin, …) are unavailable.
• First ship of a new slug takes about a minute to propagate worldwide — a brief 404 right after the very first ship is normal, and the page auto-retries. Later releases repoint near-instantly.

Deploying with agents

Everything above is also available to agents through the deploy.* MCP tools, so an agent can build and ship a project on your behalf without you running the CLI:

For real project bundles the agent uses the yolo deploy CLI inside the workspace (it has the files and the build toolchain); the MCP tools cover everything that doesn’t depend on the working directory. If an agent created the project with deploy.create_project and then runs yolo deploy init, the CLI recognises the slug as one you already own and links to it (no “slug taken” dead-end) — or it can run yolo deploy link explicitly. When production approvals are enabled, production ships requested by an agent route to you for approval — no token an agent holds can self-approve.

Related pages

• Managing Projects — rename, alias, redirect, delete, and clone projects
• Custom Domains — point a domain you own at a project
• Managed Customers — give a customer a read-only portal for a project
• Managed Data — databases, KV, object storage, and FlexDB
• Secrets & Env — environment variables and durable secrets
• Workspaces — the cloud environment you deploy from
• Workspace MCP Server — agent-driven workspace control