Why we're moving off Cloudflare Durable Objects
1–10 of 16 posts
Re: Why we're moving off Cloudflare Durable Objects
#2Well 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
Re: Why we're moving off Cloudflare Durable Objects
#3I 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!
Re: Why we're moving off Cloudflare Durable Objects
#4> 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
For reference, part of where the thought exercises are for is in terms of replicating what might have been a traditional BBS message net, but a massive hub for such activity on Cloudflare hosting. Some pieces burrowed from FTN (Fidonet technology) but some rethinking in terms of more modern capabilities in practice.
Re: Why we're moving off Cloudflare Durable Objects
#5> 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
On availability, Cloudflare is the gold standard, no argument. We get a lot more control with this setup, including the failure path. With a DO you're at the mercy of the platform's placement and migration. With ours, when a host or region goes sideways, we can deliberately reroute and rehydrate the org elsewhere instead of waiting on the platform. That doesn't beat CF's raw availability and uptime, but it's a recovery lever we didn't have before.
It also unlocks something DO structurally couldn't: running the whole stack in a customer's own cloud (BYOC). For the regulated teams we're building for, that requirement alone was worth the trade.
Re: Why we're moving off Cloudflare Durable Objects
#6Took 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…
Re: Why we're moving off Cloudflare Durable Objects
#7> 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
Re: Why we're moving off Cloudflare Durable Objects
#8Re: Why we're moving off Cloudflare Durable Objects
#9Why do all this work and then let an ai write the blog post.