Releases — test first, then promote

Deploying on qubepods is one command — and shipping is a second, deliberate one. Every app has two release slots (blue and green): one serves your traffic, the other stages the next release.

$ ./deploy.sh          # or: qube deploy
{
  "ok": true,
  "slot": "green",
  "served": false,
  "slotPreviewUrl": "https://…/production/?slot=green",
  …
}

The flow

Deploy. The very first deploy of an app goes straight live. Every deploy after that lands in the idle slot at 0% traffic — the response says so: "served": false.
Test the future release. slotPreviewUrl is the staged release at a real URL, running against the project’s real stores — everything except traffic. Your current version keeps serving, untouched.
Promote. Flip the tested slot live with the same project token you deployed with:
Terminal window
```
$ curl -X POST "https://api.qubepods.com/api/projects/<project>/apps/<app>/promote" \
    -H "Authorization: Bearer $QUBEPODS_TOKEN"
{"ok":true,"activeSlot":"green"}
```
The flip is atomic — a pointer change, not a redeploy. The previous version stays in the other slot, so rolling back is just promoting again.

Canary — ramp instead of flip

Instead of promoting all at once, send a percentage of visitors to the staged slot from the console (your app → Releases): each visitor is pinned to a slot for their session, so nobody flips versions mid-visit. Ramp the weight up, watch, then promote; set it back to 0 to abort.

Tips

Put a version marker in your app (the thermo example shows one in its status line) — it makes preview-vs-live unambiguous while testing.
A deploy’s slotPreviewUrl works for one release at a time per app: the next deploy to the same slot replaces what’s staged there.
Backend twins don’t split: a twin is one running instance per project, so a stateful app’s deploy activates directly. Stage those changes the platform way — a second project (see Deploy a Qube).