Managing Projects

Once a project is live you rarely want to start over. Changing its address, parking a second hostname on it, forwarding an old URL, tearing down a throwaway, or stamping out a copy are all in-place operations — the project keeps its id, its database, and its full release history. No re-creating, no orphaned subdomains.

Every operation here has a yolo deploy CLI verb and a matching deploy.* tool, so an agent can do them on your behalf.

Rename a project

Change the subdomain a project serves on without touching anything else — same project, same bound data, same releases.


yolo deploy rename shipit

The project that was at old-slug.yolo.host now serves at shipit.yolo.host. By default the old hostname keeps working as a 308 redirect to the new one, so existing links and bookmarks don’t break — path and query string are preserved (old-slug.yolo.host/pricing?ref=x → shipit.yolo.host/pricing?ref=x). Pass --no-redirect if you’d rather free the old slug immediately instead.


CLI	`yolo deploy rename <newslug> [--no-redirect]`
MCP tool	`deploy.set_slug`

Slugs follow the same rules as at create time — 3–40 characters, lowercase letters, numbers, and hyphens, and a handful of reserved names are unavailable. A slug already in use by any other project on the platform (as its primary, an alias, or a redirect) is refused.

Add an alias

An alias is a second hostname that serves the same project. Both hostnames render identical content, and the alias automatically tracks production on every future ship, promote, and rollback.


yolo deploy alias shipit-docs
yolo deploy alias rm shipit-docs

Use this to give a project a friendlier public name while keeping its original URL alive, or to hold several names on a single deployment.


CLI	`yolo deploy alias <slug>` / `yolo deploy alias rm <slug>`
MCP tool	`deploy.add_alias` / `deploy.remove_alias`

Redirect a hostname

A redirect forwards one of your hostnames to another URL with a 308 (permanent). The target can be another yolo.host project or any external URL.


yolo deploy redirect old-name https://shipit.yolo.host

As with a rename redirect, a bare-origin target preserves the incoming path and query; a target that already carries its own path is honored exactly. This is the manual version of what rename sets up for you automatically.


CLI	`yolo deploy redirect <slug> <url>`
MCP tool	`deploy.set_redirect`

Take a project offline (and bring it back)

Unpublishing takes a live project off the public web without destroying anything — the release history, bound databases, and secrets all stay put; only the routing is pulled. Republishing repoints production at the existing release and the site is back.


yolo deploy offline   # take the site down (reversible)
yolo deploy publish   # bring it back online

Use this for “pause this site” cases — a demo you don’t want public between sessions, or content that needs to come down now while you decide what’s next — where deleting would be overkill.


CLI	`yolo deploy offline` / `yolo deploy publish`
MCP tool	`deploy.unpublish` / `deploy.republish`

Delete a project

Tear a project down completely — its Workers, every bound D1 database, KV namespace, and R2 bucket, its stored secrets, and all of its hostnames. This is irreversible and deletes the data in the bound stores, so export anything you want to keep first. A project that still has nested projects under it can’t be deleted — delete them, or detach each with yolo deploy set-parent --none, first.


yolo deploy delete

A throwaway project — one that has never been promoted to production — deletes immediately; this is what lets an agent clean up the scratch projects it spins up. A project with a live production release requires you to confirm by re-typing its slug, the same way a destructive action on any platform asks you to type the name back:


yolo deploy delete --confirm shipit


CLI	`yolo deploy delete [--confirm <slug>]`
MCP tool	`deploy.delete_project`

After deletion the hostname serves a branded “this project was removed” page (410 Gone) and the slug is freed for reuse.

Clone a project

Stamp out a new project with the same configuration as an existing one — its environment variables, its durable secrets, and a fresh, empty copy of each bound resource (a new D1 database, KV namespace, and R2 bucket with new ids and no data).


yolo deploy clone --name "Staging" --slug myapp-staging

A clone has no release — your code isn’t copied, because you re-ship into the clone from your workspace to populate it. This is the clean way to spin up a staging or per-customer copy of a project without hand-recreating its bindings and secrets. The new resources are empty; if you need the data too, see the note below.


CLI	`yolo deploy clone [--name <name>] [--slug <slug>]`
MCP tool	`deploy.clone_project`

Copying database contents. Clone gives the new project empty databases. Moving the rows from one project’s D1 into another’s is a separate operation that isn’t part of clone — use your app’s own export/import, or read them with yolo deploy db query and write them with the deploy.db_query MCP tool (allowWrite: true).

Nest a project under another

Group related projects — say, a site and the API it calls — by nesting one under the other. Each keeps its own subdomain, releases and resources; the parent shows its nested projects together in the hosting console.

Nesting is one level deep: a nested project can’t have projects of its own, and a project that has nested projects can’t be nested.


yolo deploy set-parent mysite     # nest the linked project under mysite
yolo deploy set-parent --none     # detach it back to the top level

yolo deploy init nests a new project for you when a parent directory is already linked to a top-level project. Pass --parent <id|slug> to choose the parent, or --no-parent to keep the new project at the top level.

The family goes offline together: taking a parent offline takes its nested projects offline first. Moving a project between parents is refused while any project involved is offline or unpublished, and a parent can’t be deleted until its nested projects are deleted or detached.


CLI	`yolo deploy set-parent <id\|slug>` / `yolo deploy set-parent --none`; `yolo deploy init --parent <id\|slug>` / `--no-parent`
MCP tool	`deploy.set_parent`

Doing it with agents

All of the above are exposed as deploy.* MCP tools, so an agent managing your hosting can rename, alias, redirect, clone, nest, and clean up projects directly:

Tool	Purpose
`deploy.set_slug`	Rename a project’s subdomain in place (old URL 308s by default).
`deploy.add_alias` / `deploy.remove_alias`	Attach or detach an extra hostname that serves the same project.
`deploy.set_redirect`	Forward a hostname to another URL (308).
`deploy.unpublish` / `deploy.republish`	Take a live project offline (reversible — keeps releases, data, and secrets), or bring it back online.
`deploy.delete_project`	Tear down a project and its resources. Throwaways delete directly; a live project requires the slug as confirmation.
`deploy.clone_project`	Duplicate a project’s config + secrets into a new, empty project.
`deploy.set_parent`	Nest a project under another, or detach it back to the top level.

These are routing and lifecycle changes, so an agent can perform the reversible ones on its own. Deleting a project that’s serving live production traffic still needs the slug as an explicit confirmation, so an agent can’t tear down a live site without that intent being stated.

Overview — what managed hosting is and the deploy flow
Custom Domains — point a domain you own at a project
Managed Data — databases, KV, object storage, and FlexDB
Secrets & Env — environment variables and durable secrets