Why we're moving off Cloudflare Durable Objects
jitpal
57 points
13 comments
July 09, 2026
Related Discussions
Found 5 related stories in 55.6ms across 5,215 title embeddings via pgvector HNSW
- Cloudflare Durable Objects, Ported to Rails necrodome · 13 pts · August 13, 2026 · 59% similar
- When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers shahartal · 12 pts · August 10, 2026 · 44% similar
- How GitHub gave every repository a durable owner ascertain · 21 pts · July 09, 2026 · 44% similar
- Cloudflare's new AI traffic options for customers alphabetatango · 84 pts · July 25, 2026 · 44% similar
- Cloudflare: Machine Traffic Could Hit 1,000x Human Traffic in 5 Years avgarrison · 14 pts · August 17, 2026 · 43% similar
Discussion Highlights (5 comments)
zuzululu
> What we built > Each organization gets one host process (Bun) on Fly Machines for all its containers. Well that is an instant nope from me. Fly.io's uptime/availability isn't something I trust and I am not alone. Part of what makes cloudflare durable objects great is the sheer availability and consistency at a true global scale
chandureddyvari
Took me a bit to understand what Wire does, but then it clicked. we’ve built something similar at a smaller scale inside R2, though right now it’s only for .md files. I can see this becoming much more useful once the docs get heavier: large PDFs, XLSX files, images, etc. At that point you probably need embeddings, reranking etc. But I think agents are smart enough to write scripts to retrieve what they want if we run them on a sandbox(which we are trying to do currently). bookmarking this for now. Good write-up though!
stephantul
Why do all this work and then let an ai write the blog post.
debo_
The objects are durable, but not endurable.
PUSH_AX
The thought of moving back to Fly after CF is completely absurd to me, each to their own. May your downtime be minimal...