You can definitely run workerd in production on your own machines and some people do.

The biggest catch is that workerd's implementation of Durable Objects currently doesn't work across multiple machines, but I'm working on fixing that: https://github.com/cloudflare/workerd/pull/6780

crypto.randomBytes is definitely in Workers' node compat layer. Is it possible you didn't enabled the node_compat flag?

https://developers.cloudflare.com/workers/runtime-apis/nodej...

I guess maybe it's time we turned this on by default...

If, when I visit your site, your site causes my browser to participate in a DDoS attack without my knowledge, your site is malicious.

Stop using it.

https://arstechnica.com/tech-policy/2026/02/wikipedia-bans-a...

> I gave it a direct link to openclaw.ai and the chat instantly ended and hit my 5hr usage limit.

Again, go to claude.ai yourself and try it. It works fine. It happily tells you about OpenClaw.

Whatever happened to jrflo must have been a coincidence. It frankly doesn't make any sense for Anthropic to be trying to block this.

LLMs have a knowledge cutoff date. Opus 4.7's documented cutoff date is in January. Older Claude models are earlier than that.

OpenClaw didn't have the name OpenClaw until January 30th. So indeed, even the latest Claude model does not know what OpenClaw is, unless you have it do a web search. If you have it search, it'll happily tell you all about it.

Honestly I find it bizarre that there are people at Cloudflare who have this attitude. Without Dane, the company wouldn't be half the size it is today.

We did, however, determine that at least one of them (and perhaps all) would have been easily caught by AI code reviewers, had AI code reviewers been in use. So now we mandate that. And honestly, I love it, the AI reviewer spots all sorts of things that humans would probably miss.

(We also fixed a number of problems around configuration that would roll out globally too fast, leaving no time to notice errors and stop a bad rollout, as well as cases where services being down actually made it hard to revert the change... should be in a much better place now. But again, none of that had to do with LLMs.)

Pet peeve: When the original source had only one significant figure ("20 degrees", probably the scientist rounded to the nearest 10 because it's approximate), but the reporter translates it to another unit with more ("68 degrees", makes it sound more exact).

This shows up all over the place. Temperatures quoted in Fahrenheit always seem more exact, just because naturally whatever science they originate from was inevitably done in Celsius and then someone else converted the number without understanding significant figures.

68°F in particular shows up all over the place (like, it's the recommended thermostat setting in the winter to save energy), and it sounds like it's some sort of exact thing, but usually "about 70°F" would be a more accurate representation of the original source.

Also we say that human body temperature is 98.6°F, and a fever is 100.4°F or higher. Wow those numbers are so exact! Four significant figures on the second one! But actually these just map to 37°C and 38°C. Americans are constantly unsure if 99.0°F counts as a fever but the rest of the world probably understands 37.2°C is not...

That's for the free plan.

Limits are documented here:

https://developers.cloudflare.com/workers/platform/limits/#w...

Also note that as of recently, the concurrent limit applies only up to the point that response headers are received, not during body streaming.

D1 is a simplified wrapper around DO, but D1 does not put your DB on the same machine. You need to use DO directly to get local DBs.

https://developers.cloudflare.com/durable-objects/

(I am the lead engineer for Cloudflare Workers.)

https://github.com/cloudflare/kumo

You can actually still create new Pages projects, but it is de-emphasized in the UI in favor of Workers.

We've done a lot of work to make static sites on Workers just as easy to configure as Pages was. Have you tried it lately? Would love to hear what aspects you feel are still more complicated than Pages.

Just to be clear, we will not break existing sites using Pages. We will either auto-migrate them to Workers once we have all the tools in place to do so, or we'll keep supporting Pages forever.

With Durable Objects[0], you can create and orchestrate millions of sqlite databases that live directly on Cloudflare's edge machines. The 10GB limit applies to one database, but the idea is you design your system to split data into many small databases, e.g. one per user, or even one per document. Since the database is literally a local file on the machine hosting the Durable Object that talks to it, access is ridiculously fast. Scalability of any one database is limited, but you can create an unlimited number of them.

If you really need a single big database, you can use Hyperdrive[1], which provides connection management and caching over plain old Postgres, MySQL, etc. Cloudflare itself doesn't host the database in this case but there are many database providers you can use it with.

[0] https://developers.cloudflare.com/durable-objects/

[1] https://developers.cloudflare.com/hyperdrive/

(I'm the lead engineer on Cloudflare Workers.)

But in practice, we almost never receive major contributions from outside the team. Which is fine. We're happy just to have our team working in the open.

The reasons we open sourced it are:

1. Support a realistic local dev environment (without binary blobs).

2. Provide an off-ramp for customers concerned about lock-in. Yes, really. We have big customers that demand this, and we have had big customers that actually did move off Cloudflare by switching to workerd on their own servers. It makes business sense for us to support this because otherwise we couldn't win those big customers in the first place.

The recently released Dynamic Workers directly provides an API for capability-based sandboxing: https://developers.cloudflare.com/dynamic-workers/usage/bind...

But the platform has used caps internally all along. Cloudflare makes heavy use of Cap'n Proto (https://capnproto.org/), a capability-based RPC protocol, and recently released Cap'n Web (https://capnweb.dev/), a JavaScript-oriented version of the same idea. The "Cap'n" in both is short for "Capabilities and". (Dynamic Workers sandboxing is based around Cap'n Web capabilities.)

Most successful sandboxes use capabilities, though it's not often something you hear about. Android's IPC system, Binder, is a capability system. And Chrome has a capability-based IPC system called "Mojo".

Capabilities really shine when used for sandboxing, but here's a blog post I wrote that tries to explain the benefits beyond sandboxing: https://blog.cloudflare.com/workers-environment-live-object-...

(I am the lead developer of Cloudflare Workers, and the creator of Cap'n Proto and Cap'n Web.)

You could certainly set it up to allow the AI to import arbitrary npm modules if you want. We even offer a library to help with that:

https://www.npmjs.com/package/@cloudflare/worker-bundler

What you would do is give the Worker a TypeScript RPC interface that lets it read the files -- which you implement in your own Worker. To give it fast access, you might consider using a Durable Object. Download the data into the Durable Object's local SQLite database, then create an RPC interface to that, and pass it off to the Dynamic Worker running on the same machine.

See also this experimental package from Sunil that's exploring what the Dynamic Worker equivalent of a shell and a filesystem might be:

https://www.npmjs.com/package/@cloudflare/shell

Comments URL: https://news.ycombinator.com/item?id=47502448

Points: 52

# Comments: 13