At SpiderPublish, no content reaches production without passing through our two-phase deploy gate. This isn’t bureaucracy — it’s the result of a near-miss incident that could have affected every tenant on our platform.
The Incident
Six months before launch, a routine component update contained a CSS rule that matched elements outside its intended scope. In a Shadow DOM world, this shouldn’t happen — but the component was being tested without shadow isolation. The rule would have broken navigation on 200+ tenant sites.
How It Works
Phase 1 (Dry Run): Every deploy starts with dry_run: true. The system validates all content, checks for broken references, runs CSS scope analysis, and returns a preview URL plus a confirm_token.
Phase 2 (Confirm): Only after reviewing the preview can you submit the confirm_token to atomically flush content to the edge. The token expires after 10 minutes.
Why Atomic
We use Cloudflare KV’s bulk write API to update all affected keys in a single operation. This means tenants never see a partially-deployed state. Either all changes go live, or none do.