Design pillars
Every Cloudflare design deliverable addresses all six platform pillars. Here they are, as the pipeline satisfies each.
The pipeline is a deployment control, so the Deployment and Observability pillars carry the most weight. The others are addressed as they apply to a CI/CD pipeline rather than to a running Worker.
Redundancy
Section titled “Redundancy”The pipeline is not a runtime dependency of the Worker. Once a Worker is deployed, it runs on Cloudflare’s edge independent of Bitbucket. A Bitbucket outage blocks new deploys, not live traffic. The deploy path itself is redundant against operator error through the manual production gate and the two-key separation of staging and production tokens.
Resiliency
Section titled “Resiliency”A failed gate step short-circuits the pipeline and blocks the deploy, so a broken change cannot reach an environment. A failed smoke test after a production deploy triggers automatic rollback to the previous version. The pipeline degrades safely: the worst case is a blocked deploy, never a silently broken production Worker.
Disaster recovery
Section titled “Disaster recovery”Recovery from a bad deploy is wrangler rollback, which restores the previous Worker version at the edge in seconds. The pipeline wires this in automatically on smoke failure and it is available manually at any time. For Workers backed by persistent state, code rollback does not undo data changes; schema changes follow the expand and contract pattern from the QA and Deployment SOP so that step one is always rollback-safe. RTO for a code-only regression is effectively the rollback command’s runtime.
Backup
Section titled “Backup”The deployable artifact is the git history in Bitbucket; every deployed state is reconstructable from a commit or tag. Cloudflare retains prior Worker versions, so the last one hundred uploads are re-deployable without a rebuild. Bitbucket repository backups follow the organization’s existing Bitbucket data-protection posture and are out of scope for this document.
Deployment
Section titled “Deployment”This document is the deployment pillar. The release flow is: gate on every branch and pull request, automatic deploy to dev and staging, and a manually gated, tag-triggered deploy to production with a mandatory staging soak between. Rollback is a first-class step, not an afterthought. Promotion is one direction only, dev to staging to production, and production credentials are scoped so a lower environment cannot reach it.
Observability
Section titled “Observability”Three layers. The pipeline emits build logs and per-environment deployment records in Bitbucket Deployments. Each deploy ends in a smoke test that verifies the health endpoint and confirms the deployed commit SHA round-trips. At runtime, every Worker carries the mandatory OpenTelemetry to New Relic instrumentation behind OTEL_ENABLED, so the effect of a deploy is visible in New Relic and in Workers analytics during the soak window. A new error class during soak blocks promotion.