The 21-second production canary: pin, diff 82 bindings, roll back

The answer. To prove a new backend (here: a Cloudflare Workflow replacing an n8n pipeline) against real production traffic without leaving anything behind, don't edit production. Cut over to a candidate version and back. Record the currently deployed version id as the checkpoint. Create a candidate from that exact version, changing only the authorized bindings (for us, the three that point dispatch at the new backend). Diff the candidate against the checkpoint — script hash, runtime, every binding — and refuse if anything else differs. Deploy it, fire exactly one request through the normal producer, and roll back to the checkpoint by id from a finally block so a thrown error can't leave the candidate live. Then confirm /health reports the checkpoint version.

The pattern.

const checkpoint = await getActiveVersion(WORKER);            // record, don't assume
const candidate = await createVersionFrom(checkpoint.id, {
  bindings: { UPSTREAM_URL: NEW_URL, UPSTREAM_API: NEW_API, UPSTREAM_KEY: NEW_KEY },
});
const diff = compare(checkpoint, candidate);                  // script hash + ALL bindings
if (diff.script || diff.bindings.some((b) => !AUTHORIZED.has(b.name)))
  throw new Error(`unauthorized drift: ${JSON.stringify(diff)}`);

let deployed = false;
try {
  await deployVersion(candidate.id);
  deployed = true;
  await producer.post("/projects/:id/runs", { mode: "single", keyword: KEYWORD });
} finally {
  if (deployed) await deployVersion(checkpoint.id);           // exact version, by id
  const h = await fetch(`${API}/health`).then((r) => r.json());
  if (h.release.worker_version !== checkpoint.id) page("ROLLBACK FAILED");
}

The receipt. HarperFlow, 2026-07-25, 04:30 UTC. The candidate was diffed against the checkpoint: script and runtime identical, 82 bindings compared, exactly 3 differences, all authorized. Cutover deployed at 04:30:29, rollback at 04:30:50. Production ran the candidate for 21 seconds. One run was accepted by the normal producer and handed to the Workflow. That run surfaced the WorkflowStep RPC defect, then stopped on a rejected third-party credential; no article, CMS item, image or credit was touched, and /health confirmed the checkpoint was live again. The runbook now names that version id as the rollback target, to be re-read immediately before any future cutover.

Watch out.

Roll back to a version id, not "the previous deployment". Another deploy could land in between.
Diff the bindings, not just the code. A Worker with one different secret is a different Worker.
"Failed" and "terminal" differ. Our callbacks ignore progress for terminal runs, so retrying the old Workflow instance could have charged a customer while updating nothing. New run, new id.