Files
Auree Aubert 53a1a86a7f Add cargo-hosting skill for app and worker deployment (#40)
* Add cargo-hosting capability skill

Document the `hosting` CLI domain (apps, workers, deployments) as a
dedicated capability skill, following the one-skill-per-CLI-domain
convention.

- cargo-hosting/SKILL.md: init -> create -> deploy -> promote lifecycle
  for Vite SPA apps (*.cargo.app) and edge workers, with critical rules
  and async polling.
- references/examples/{apps,workers,deployments}.md, response-shapes.md,
  troubleshooting.md.
- Register in the cargo router (skill count 10->11, capability table row,
  recap, removed hosting from the no-skill-yet table, synced frontmatter
  count) and bump cargo 1.4.0 -> 1.5.0.
- README capability table + skill count (11 -> 12).
- CHANGELOG entries for cargo-hosting 1.0.0 and cargo 1.5.0.

https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup

* Add hosting terms to glossary

Add app/appUuid, deployment/deploymentUuid, hosting, worker/workerUuid
entries to cargo/references/glossary.md, and correct the capability-skill
domain list (was missing content and hosting). CHANGELOG updated.

https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup

* Pin hosting response shapes from backend types

Replace inferred shapes/caveats in cargo-hosting with the authoritative
App/Worker/Deployment structures: kind app/worker discriminant,
promotedDeployment, chargedUntil, and the deployment status enum
(pending/building/success/error/cancelled, terminal at the last three).
Polling + build-failure docs now cite the real status/errorMessage/
buildLogS3Filename fields, and a critical rule notes monthly hosting
credits per resource.

https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-06-15 10:30:32 +02:00

2.2 KiB

Deployment examples

A deployment is one build+upload of a local source directory to an app or worker. Two facts drive everything below:

  1. A deployment belongs to exactly one app or worker — --app-uuid and --worker-uuid are mutually exclusive.
  2. Building is not promoting. deployment create builds; the live URL only moves when you deployment promote.

Create a deployment

# App: backend runs `npm ci && vite build` in a sandbox
cargo-ai hosting deployment create --app-uuid <app-uuid> --source ./my-app

# Worker: backend bundles the entrypoint
cargo-ai hosting deployment create --worker-uuid <worker-uuid> --source ./my-worker
  • --source is the package root (where package.json lives), not a pre-built dist/. The build happens server-side.
  • Default ignore list: node_modules,dist,build,.git,.next. Override the whole list with --ignore:
cargo-ai hosting deployment create --app-uuid <app-uuid> --source ./my-app \
  --ignore "node_modules,dist,build,.git,.next,coverage,.turbo"

Poll the build, then promote

# Builds are async — poll until the status field is terminal
cargo-ai hosting deployment get <deployment-uuid>
# when terminal (built/succeeded), promote:
cargo-ai hosting deployment promote --uuid <deployment-uuid>

If the build failed, inspect the deployment record for the error and fix the source before re-running deployment create. See ../response-shapes.md for the fields to check.

List deployment history

cargo-ai hosting deployment list --app-uuid <app-uuid>       # newest first
cargo-ai hosting deployment list --worker-uuid <worker-uuid>

See what's currently live

cargo-ai hosting deployment get-promoted --app-uuid <app-uuid>
cargo-ai hosting deployment get-promoted --worker-uuid <worker-uuid>

Roll back to a previous deployment

Promotion just points the live URL at a deployment, so rolling back is promoting an older one — no rebuild needed.

# 1. Find the deployment you want to go back to
cargo-ai hosting deployment list --app-uuid <app-uuid>

# 2. Promote it
cargo-ai hosting deployment promote --uuid <older-deployment-uuid>

# 3. Verify
cargo-ai hosting deployment get-promoted --app-uuid <app-uuid>