“I am not blaming the innovation. I am blaming the chaos of innovation. Everything feels DISJOINTED.” That’s the author of “Cloudflare’s AI psychosis”, on Hacker News this weekend, after the essay reached the front page. The essay itself is wider and angrier than that. Cloudflare used to be boring infrastructure run by engineers and is now a product-management organisation with a posting habit; too many overlapping primitives, still no proper Postgres, a developer experience bolted on as an afterthought, observability that never ships, more outages than ever, 1,100 people made redundant under an “agentic” banner. It opens by missing the old company, the one that “sat in front of your site, ate the attacks, cached the static stuff, did the DNS, and that’s it. No BS.” I agree with most of what it lists. I think the diagnosis is wrong, and I want to say why at some length, because the essay is being passed around as if the two were the same thing.
I work for a Cloudflare partner, I build on the Developer Platform most working days, and I wrote a book about it this year, independent and unendorsed, so discount accordingly. In my defence, the book has a chapter called When Not to Use Cloudflare, and I’ll be quoting it against Cloudflare a few times, because several of the essay’s best points are ones I’d already conceded in print.
The dashboard, and the rest of it
If “developer experience” means the dashboard, then yes, it’s a mess, and I haven’t opened it in anger for about a year. yodon on the thread called it “the densest collection of UI anti-patterns known to man” and I’m not going to argue. The outage the essay leads with, the 12 September 2025 dashboard and API failure, was the dashboard’s fault: a React useEffect with an object in its dependency array, recreated on every render, calling the Tenant Service API “many times during a single dashboard render instead of just once” until it fell over. A React hook took the control plane down for over an hour. The postmortem is candid about it.
The developer experience I actually use is a terminal, a config file and a runtime, and I think that part is the best local story of any serverless platform I’ve worked on. wrangler dev runs your code in workerd, built from the same source as the production runtime. To be fair to Lambda, sam local runs the real Lambda image too; what both simulate is the services around the runtime, and Miniflare’s stand-ins for KV and D1 and R2 and Queues are the vendor’s own and cover more of the platform. What Cloudflare has that Lambda doesn’t is one path: wrangler deploy is seconds, wrangler rollback is seconds, and there’s no fast-but-unsafe route sitting next to a slow-but-safe one. What’s left is the gap I spend most of Chapter 5 on: you can simulate the runtime but you cannot simulate the network. Local D1 answers in microseconds and production D1 in tens of milliseconds, and that difference causes more works-on-my-machine bugs on this platform than anything else. You can’t fix it in Wrangler.
Look at where the money went this year. In April Cloudflare started rebuilding the CLI as cf, generated from one schema across nearly three thousand API operations. In June it bought VoidZero, Evan You’s company, the people behind Vite and Vitest, and You’s own post says what for: “cf dev should be a superset of vite dev”. An acquisition is also an announcement, yes. It’s also a large cheque and a team, and you don’t spend either on an afterthought.
One animal, different coats
The essay’s central exhibit is storage. D1, Durable Object SQLite, KV, R2, Queues, Hyperdrive: “too many ways to do the same thing, none of them great”. They aren’t the same thing. Map them and you get a SQLite, an eventually consistent cache, an S3, an SQS and a connection pooler, and nobody calls AWS disjointed for having RDS, ElastiCache, S3, SQS and RDS Proxy. Hyperdrive is a marketing name, granted. So is Lambda. Cloudflare doesn’t have fewer products because it’s tidier; it has fewer because it offers less, no VMs, no Kubernetes, no GPUs by the hour. What it does have is one programming model. Four general-purpose ways to run code, on two substrates, V8 isolates and Linux containers, and everything that isn’t an isolate is fronted by a Durable Object, configured in the same file, deployed by the same command, reached through the same bindings. A Durable Object is a Worker with state. A Container is a Durable Object with a bigger body. A Dynamic Worker is a Worker whose code another Worker hands it at request time. D1 is a Durable Object you didn’t have to build. If you know what a Worker is, the rest isn’t a zoo. It’s one animal in different coats. The book calls it unbundling and is blunt about the cost: derived data needs explicit code, you build your auth instead of configuring it, and the first week feels like being handed a bag of parts. You might not want that trade. But it’s a design, not a symptom, and it’s been the design since KV in 2018.
The compute side is where the essay has a point. There is no single page that puts Workers, Dynamic Workers, Sandboxes and Containers next to each other and tells you which to reach for; I looked. That’s a real documentation failure, and Cloudflare more or less admitted it on 3 August by shipping @cloudflare/computer, which hands the model a single exec tool and lets it choose between a shell inside an isolate and a real container, so that you don’t have to. That is exactly the pattern the essay is complaining about. Look at who wrote the newest layer, though. Dynamic Workers and Code Mode came out of a September 2025 post by Kenton Varda and Sunil Pai; Varda designed the Workers runtime and is the one engineer the essay names approvingly. If product managers have taken the pen from the infrastructure engineers, it’s odd that the infrastructure engineer keeps writing the new things.
The database
The Postgres point is the strongest one in the essay, and it’s true. There is no first-class Cloudflare-run PostgreSQL. I said so in Chapter 12: “A native serverless PostgreSQL offering would fill an obvious gap.” The closest thing is PlanetScale. In April Cloudflare wired PlanetScale Postgres into Workers through Hyperdrive, and since 18 June you can create one from the Cloudflare dashboard and it lands on your Cloudflare invoice at PlanetScale’s prices. You get Cloudflare billing and Cloudflare wiring; the database is still a PlanetScale database in a PlanetScale region.
The essay reads Hyperdrive as an admission that Cloudflare never built the database serious apps want. I read it differently. A managed Postgres is the one product that would contradict the platform’s own architecture, and they haven’t built it. Varda, announcing SQLite in Durable Objects in 2024: “Traditional cloud architecture favors large distributed databases that live separately from application servers.” In 2020, Durable Objects were “the missing piece in the Workers stack that makes it possible for whole applications to run entirely on the edge, with no centralized ‘origin’ server at all.” A managed Postgres in one region is an origin, and the platform was founded on the idea that the origin is the problem. I’ve overstated that idea myself. For most SaaS the origin isn’t the problem; the origin is where the customers are, users cluster in one to three regions, reads dominate, and a replica handles the read path. Hyperdrive is a pooler and a read cache in three hundred cities. It pays the connection handshakes once; every query still crosses the ocean, writes always do, and the cache is time-based, so the fast reads are the ones that might be stale. What it buys is that a Worker at the edge talks to a regional Postgres at roughly the cost a regional Lambda would, so the work that belongs at the edge can happen before or instead of the query. In the book I call that a permanent architecture rather than a bridge, and I still think that, but it’s a claim about the topology being reasonable, not about latency going away.
The real difference isn’t that Cloudflare distributes data and the hyperscalers don’t. Aurora Global Database, DynamoDB Global Tables and DSQL distribute data fine, across a few dozen regions, by configuration. Cloudflare partitions it by key and moves the code to the partition, per object, across a few hundred cities. A Durable Object is a single writer in a single place with its SQLite in the same thread as the code, wonderful for a chat room or a per-user agent and useless for an ad-hoc join across tenants. D1 has an origin too, a primary in one location with read replicas behind it. So it depends what you mean by Postgres. If you mean SQL, you get D1, fifty thousand databases by default, one per tenant, 10 GB each, and you pay for that in fleet migrations and cross-tenant reporting you write yourself. If you mean Postgres, the extensions and pgvector and twenty years of tooling, you keep it where it lives and put Hyperdrive in front. Neither is the “first-class managed PostgreSQL that feels native” the essay asks for, and the red flags chapter says plainly that if your data model assumes a single large database you should use Hyperdrive or go somewhere else, because “Cloudflare isn’t a general-purpose cloud. It’s a specific bet on a specific model.”
Here’s the awkward part. I’d bet on a Cloudflare-run Postgres arriving. They bought Outerbase for the database experience, they put PlanetScale on the invoice, and it isn’t hard to see where that goes. That’s a guess from the public record; every source is linked and I have no inside knowledge. You can’t believe both that “no origin” is doctrine and that they’re about to ship one, so one of those is posture, and I think it’s the first. “No origin” was a preference the platform could hold while partners met the demand, and PlanetScale on the Cloudflare invoice is that preference already bending. If they build their own, the essay gets to say it told me so. I don’t think it’ll look like RDS when it comes; I think it’ll be many small ones near the code, because that’s the bet, and the bet is what you’re buying when you buy Cloudflare. And if “feels native” means what I think it means, that’s the database the essay is asking for as well. We want the same thing. Where we differ is whether not having it yet means the company has lost its mind.
Ryan Dahl, who is building a competitor to it, shipped celld this week, a self-hosted Durable Objects clone on S3, and called the model “one of the best primitives distributed systems has been handed in years”. That cuts against me too: the primitive is right and Cloudflare’s terms for it, the price and the lock-in, are what people actually object to. That’s the argument I’d rather be having. It’s a better one than psychosis.
0.x with an operating system on top
The agents section lists Agents SDK, Flue, Project Think and Cloudflare OS as “another harness or framework instead of finishing the one they already have”. Cloudflare’s own Flue announcement sets out the layering: Flue is a framework, Project Think and Pi are harnesses, “the agentic loop”, and the Agents SDK is “the compute, state, and storage primitives everything above depends on”. Flue came from the Astro team, who joined Cloudflare in January; it grew out of the triage pipeline that took Astro’s own open issues from over two hundred to about thirty. Cloudflare OS, which I spent last week reading, is an application built on all of that. One runtime with things stacked on it, not four harnesses. None of that answers the actual complaint, though. The SDK everything depends on is still on version 0.x eighteen months after launch. Think is labelled experimental. The SDK, the Agents dashboard that arrived on 4 August, and Agents Week, which has now happened twice this year, all share a name. A tidy diagram doesn’t make the base reliable, and I’d rather have a 1.0 of the SDK than another thing on top of it. That part of the essay is right.
Some of the rest was out of date by the time it was published. AI Search “lags proper RAG platforms … on quality, filtering, hybrid search”: hybrid search shipped on 16 April, custom metadata filtering on 23 March, reranking last October. What’s left is five metadata fields, one reranker, and a product still in open beta with billing not switched on a year and a half in, which makes it an unpriced dependency; I’d keep it out of the critical path until it has a price. The docs ship without “even basic SKILL.md stuff for agents”: the cloudflare/skills repository has been up since December, next to an llms.txt and a docs MCP server from May 2025. The docs complaint that does stick is the Matrix post. In January a Cloudflare TPM published a personal project on the company blog as a “serverless, post-quantum Matrix homeserver”, and Matrix developers found the signature checks were TODOs and the README said production-grade; Matthew Hodgson: “the code doesn’t yet implement any of Matrix’s core features which allow you to federate safely, and so doesn’t yet constitute a functional Matrix server”. Cloudflare added a proof-of-concept note the same day. That’s embarrassing for the blog, and the tracing docs carried a billing start date that had already passed for months, so docs rot is a fair charge, and so is the narrower one that new products arrive without versioned reference material. Docs-for-agents being absent isn’t. Workers AI does trail on speed: when I checked on 15 August, Artificial Analysis had Cloudflare well behind Fireworks and Baseten on throughput for Kimi K2.6, and the book says flatly that these aren’t the best models available and that edge inference “optimises the rounding error”. But the essay’s line that this forces “a lot of teams to send the hard inference somewhere else and treat Cloudflare as plumbing again” is meant as a dig, and it’s what the product is for. On the day the essay was published, Cloudflare merged Workers AI into AI Gateway: one wallet, spend it on OpenAI or Anthropic or their own GPUs, five per cent on top. Running an agent on Cloudflare means holding its state, sandboxing its code and surviving its restarts. It has never meant running the frontier model.
Where the essay is right
Observability. Workers tracing has carried a beta badge since October 2025, and the known limitations page says the three things the essay says: some spans report zero milliseconds because the runtime doesn’t advance the clock between I/O events, a Spectre mitigation; trace IDs “are not propagated to services outside of Cloudflare”; span attributes are incomplete. Cross-binding propagation was fixed in May, custom spans in June, local tracing this month, so it’s moving, but ten months is a long open beta for the thing you use to find out why production is broken. Chapter 20 says the same as the essay in politer language, “where Cloudflare still trails is full APM instrumentation”, which spelled out means no service map, no SLO objects, no alarms on custom dimensions without building them yourself, so what you’d actually compare is Cloudflare plus Honeycomb or Datadog against CloudWatch and X-Ray on their own. If you’re on Workers and reading this to decide whether to leave: don’t, but stop waiting for the beta badges to come off and ship your traces out through the OTLP export now. The 1% sampling bug on paid accounts the essay cites I couldn’t verify either way, because the source is behind a bot wall. The community thread I could read, an account on what looks like the Free plan whose logs vanished from the dashboard in March while wrangler tail kept showing them, has zero replies. Zero. That’s the bit that stings, and it isn’t unrelated to what happened in May.
The volunteer Community Champions said in May that Cloudflare had let go of many of its community team, that they’d lost their contacts inside the company, and that the programme was dissolved without a clear reason. Cloudflare hasn’t said so itself, but the replacement, announced the same day as the essay, says of itself that it is “not about being on hand to perform moderation and admin tasks” because they’re building automation to do that “with far less human intervention”. An unanswered thread is what that looks like from the outside. That one made me angry, and I don’t get angry at Cloudflare much.
And the redundancies are real. More than 1,100 people on 7 May, about a fifth of the company. The 8-K calls it a plan “to further accelerate its evolution to an agentic AI-first operating model”. That phrase is Cloudflare’s, not the essay’s. It’s grim. Matthew Prince’s defence in Fortune was that “the vast majority of those we laid off last week were measurers”, his word for middle management, finance, legal and audit. I have no way to know whether that’s true, and neither does the essay. What I can check is the talent-drain claim, and it’s one name: Kate Reznykova, an engineering manager on the Agents and Sandboxes team, went to OpenAI in July, the one departure the essay could actually have cited. I couldn’t find anyone who went to Anthropic. Varda is still there and shipped Dynamic Workers and Cloudflare OS this year. The stock fell 24% the next day, on the same call as the earnings, so whatever the cuts were for, the market didn’t read them as a gift.
What fell over
On reliability I have to be careful, because the essay’s own line is that “the core network, reliability, and simplicity that made Cloudflare different get less consistent attention”, and the two big outages of 2025 were in the core network. So the essay gets to say the boring layer fell over. It did. On 18 November a ClickHouse permissions change made the Bot Management feature file more than double in size, past a hard-coded limit, and the Rust proxy hit an unwrap() and panicked across the network for about three hours; Prince called it “Cloudflare’s worst outage since 2019” and apologised “for the pain we caused the Internet”. On 5 December a WAF change tripped a global kill switch and the older Lua proxy threw a nil error for 25 minutes across 28% of HTTP traffic. Their own words: “how closely they are clustered together” is “not acceptable for a network like ours”. No argument from me. The same autumn took out us-east-1 for about fifteen hours and Azure Front Door for about eight, both from automated configuration changes with too little staging, so the boring cloud that doesn’t fall over isn’t on offer anywhere. The difference, and it’s the essay’s strongest card, is that those were regional. Cloudflare’s are global by design.
The cause is where I disagree. Neither November nor December was a new failure mode that arrived with the AI products. They were the same class as Cloudflare’s oldest one: something propagated to every machine on earth in seconds, with no staged rollout, and a proxy that fell over hard on the result. That’s how the July 2019 outage happened, a bad WAF regex pushed globally, in the boring era the essay misses, and that postmortem names the gap in one sentence: “The SOP for a rule change specifically allows it to be pushed globally. This is very different from all the software we release at Cloudflare”. Cloudflare’s own Fail Small post says of the 2025 pair that “both outages followed a similar pattern. In the moments leading up to each incident we instantaneously deployed a configuration change in our data centers in hundreds of cities around the world.” They promised staged rollouts for WAF rules in 2019. Nobody widened the promise to feature files and kill switches until it hurt. It’s the failure mode I warn readers about in Chapter 2: the property that makes a global deploy valuable is the property that makes a global mistake instant. If attention drifted, and I think the clustering says it did, it drifted from a discipline the company had already learned once, in one place, and had to relearn everywhere.
And relearn it they did, in the least exciting engineering Cloudflare has published in years. Code Orange: Fail Small in December committed to “controlled rollouts for any configuration change that is propagated to the network, just like we do today for software binary releases”, which is the 2019 sentence with the fix applied, and the completion post on 1 May reports health-mediated config rollout on most production systems, a break-glass drill with over two hundred people, and a Rust rule that reads, in full, “Do not use .unwrap() outside of tests and build.rs.” Companies optimising for announcement cadence don’t publish that rule, and if you want the writing about hard trade-offs that the essay says Cloudflare no longer does, the postmortems are it. That’s a company that got frightened in November and spent the winter on rollout discipline. Whether it stays frightened I can’t tell from the public record.
I’ve now spent a chapter and three thousand words explaining why the missing Postgres is doctrine. I’d still like the database.