> versions & rollback
Cloudflare splits uploading a Worker version from deploying it, and that split is the whole point of this category. Upload creates an immutable version, deploy routes traffic to one or more versions (optionally split for a gradual rollout), and rollback pins production back to a known-good build. Master these commands and a bad deploy becomes a ten-second fix instead of a scramble.
// versions & rollback
7 commands$ wrangler versions list$ wrangler versions upload --message "fix checkout bug"$ wrangler versions deploy <new-version-id>@10 <old-version-id>@90$ wrangler versions deploy <version-id>@100 -y$ wrangler rollback --message "revert bad deploy"$ wrangler deployments status$ wrangler versions upload -e production --message "release v2"// faq
What's the difference between `wrangler deploy` and `wrangler versions upload`?
`wrangler deploy` uploads a new version AND immediately routes 100% of production traffic to it. `wrangler versions upload` only creates the version (reachable on a preview URL) without touching production — you promote it later with `wrangler versions deploy`. Reach for the split flow when you want to canary or stage a change before it goes live.
How do I quickly roll back after a broken deploy?
Run `wrangler rollback` with no arguments to revert to the previous deployment, or `wrangler rollback <version-id>` to pin a specific known-good version pulled from `wrangler versions list`. It only reverts the code/version pointer — it will not undo secret changes, KV/D1/R2 data, or a database migration.
Does a gradual rollout keep the same user on the same version?
No. Traffic splitting via `wrangler versions deploy <id>@10 <id>@90` is random per request, not sticky per user, so one user can hit different versions on different requests. Only use it for stateless changes, never session-dependent behavior.