For most applications 1 location is probably good enough.I assume HN is single location and I am a lomg way from CA but have no speed issues.

Cavaet for high scale sites and game servers. Maybe for image heavy sites too (but self hosting then adding a CDN seems like a low lock in and low cost option)

Honestly, for my own stuff I only need one PoP to be close to my users. And I've avoided using Cloudflare because they're too far away.

More seriously, I think there's a distinction between "edge-style" and actual edge that's important here. Most of the services I've been involved in wouldn't benefit from any kind of edge placement: that's not the lowest hanging fruit for performance improvements. But that doesn't mean that the "workers" model wouldn't fit, and indeed I suspect that using a workers model would help folk architect their stuff in a form that is not only more performant, but also more amenable to edge placement.

> But do you need 300 pops to benefit from the edge model? Or would 10 pops in your primary territory be enough.

I don't think that the number of PoPs is the key factor. The key factor is being able to route requests based on a edge-friendly criteria (latency, geographical proximity, etc) and automatically deploy changes in a way that the system ensures consistency.

This sort of projects do not and cannot address those concerns.

Targeting the SDK and interface is a good hackathon exercise, but unless you want to put together a toy runtime to do some local testing, this sort of project completely misses the whole reason why this sort of technology is used.

I agree, latency is very important and 300 pops is great, but seems more for marketing and would see diminishing returns for the majority of applications.

many apps are fine on a single server

If you have a central database, what benefits are you getting from edge compute? This is a serious question. As far as I understand edge computing is good for reducing latency. If you have to communicate with a non-edge database anyway, is there any advantage from being on the edge?

I think you should consider adjusting the marketing to reflect this. "untrusted JavaScript" -> "JavaScript", "Secure sandboxing with CPU (100ms) and memory (128MB) limits per worker" -> "Sandboxing with CPU (100ms) and memory (128MB) limits per worker", overhauling https://openworkers.com/docs/architecture/security.

Over promising on security hurts the credibility of the entire project - and the main use case for this project is probably executing trusted code in a self hosted environment not "execut[ing] untrusted code in a multi-tenant environment".

Have you tried Opus 4.5?

I didn’t know this, but there are also security downsides to being ahead of chrome — namely, all chrome releases take dependencies on “known good” v8 release versions which have at least passed normal tests and minimal fuzzing, but also v8 releases go through much more public review and fuzzing by the time they reach chrome stable channel. I expect if you want to be as secure as possible, you’d want to stay aligned with “whatever v8 is in chrome stable.”

Completely agree. There are some apps that unfortunately need to care about some level of security isolation, but with an open workers they could just put those specific workers on their own isolated instance.

In terms of a one off product without active support - the only thing I can really imagine is a significant use of formal methods to prove correctness of the entire runtime. Which is of course entirely impractical given the state of the technology today.

Realistically security these days is an ongoing process, not a one off, compare to cloudflare's security page: https://developers.cloudflare.com/workers/reference/security... (to be clear when I use the pronoun "we" I'm paraphrasing and not personally employed by cloudflare/part of this at all)

- Implicit/from other pieces of marketing: We're a reputably company with these other big reputable companies who care about security and are juicy targets for attacks using this product.

- We update V8 within 24 hours of a security update, compared to weeks for the big juicy target of Google Chrome.

- We use various additional sandboxing techniques on top of V8, including the complete lack of high precision timers, and various OS level sandboxing techniques.

- We detect code doing strange things and move it out of the multi-tennant environment into an isolated one just in case.

- We detect code using APIs that increase the surface area (like debuggers) and move it out of the multi-tennant environment into an isolated on just in case.

- We will keep investing in security going forwards.

Running secure multi-tenant environments is not an easy problem. It seems unlikely that it's possible for a typical open source project (typical in terms of limited staffing, usually including a complete lack of on-call staff) to release software to do so today.

Something like "all code is run with no permissions to the filesystem or external IO by default, you have to do this to add fine-grained permissions for IO, the code is run within an unprivileged process that's sandboxed using standard APIs to defend in depth against possible v8 vulnerabilities, here's how this system protects against obvious possible attacks..." would be pretty good. Obviously it's not proof it's all implemented perfectly, but it would be a quick sign that the project is miles ahead of a naive implementation, and it would give someone interested some good pointers on what parts to start reviewing.

That's the problem! It's really hard to find trustworthy sandboxing solutions, I've been looking for a long time. It's kind of my white whale.

Other response address how you could go about this, but I'd just like to note that you touch on the core problem of security as a domain: At the end of the day, it's a problem of figuring out who to trust, how much to trust them, and when those assessments need to change.

To use your example: Any cybersecurity firm or practitioner worth their salt should be *very* explicit about the scope of their assessment.

- That scope should exhaustively detail what was and wasn't tested.

- There should be proof of the work product, and an intelligible summary of why, how, and when an assessment was done.

- They should give you what you need to have confidence in *your understanding of* you security posture as well as evidence that you *have* a security posture you can prove with facts and data.

Anybody who tells you not to worry and take their word for something should be viewed with extreme skepticism. It is a completely unacceptable frame of mind when you're legally and ethically responsible for things you're stewarding for other people.

Automatically running LLM-written code (where the LLM might be naively picking a malicious library to use, is poisoned by malicious context from the internet, or wrongly thinks it should reconfigure the host system it's executing code on) is an increasingly popular use-case where sandboxing is important.

Question: Do you support WASM workers? How does the deployment experience compared to Wrangler? If I have a wasm worker and only use KV, how identical will be the deployed worker to that of Cloudflare?

True, workerd is open source. But the bindings (KV, R2, D1, Queues, etc.) aren't – they're Cloudflare's proprietary services. OpenWorkers includes open source bindings you can self-host.

the pricing is so insane it will always be cheaper to self host by 100x, that's how bad it is.

Presumably they're talking about the egregious price of NAT on AWS.

It's next to free self hosting considering even the crappiest consumer router has hardware accelerated NAT and takes a tiny amount of power. You likely already have the hardware and power since you need routing and potentially other network services

salesforce had their hosting bill jump orders of magnitude after ditching their colocation, it did not save anything and colocation staff were replaced with AWS engineers

nat is free to provide because the infrastructure to have NAT is already there and there is never anything maxing out a switch cluster(most switches sit at ~1% usage since they're overspeced $1,000,000 switches), so other than host CPU time managing interrupts (which is unlikely since all network cards offload this).

sure you could argue that regional NAT might should be priced, but these companies have so much fiber between their datacenters that all of nat usage is probably a rounding error.

They said “charging more than free” - i.e., more than $0, i.e., they’re not free. It was awkwardly worded.

Thanks! Now I can make more sense of it! Very cool project by the way, thanks for posting it

That's why we need to test websites on multiple browsers.

nice, KV + Postgres covers most of our use cases. the TTL on KV is useful for caching auth tokens between invocations without worrying about cleanup.

for long-running tasks we've been using a queue pattern anyway - worker picks up task, does a chunk, writes state to KV, exits. next invocation picks up where it left off. works around timeout limits and handles retries gracefully. websockets would be nice for real-time feedback but polling works fine for now.

will keep an eye on the durable objects progress. that's the main thing missing for stateful agent workflows where you need guaranteed delivery.

It will be a very small cloud.

I think it would be worth it to keep the D1 compatibility, Sqlite and Postgres have different SQL dialects. Cloudflare has Hyperdrive to keep the connection alive to Postgres/other dbs, what D1/libSql/Turso brings to the table is the ability to run a read/write replica in the machine, this can dramatically reduce the latency.

This makes a lot of sense. Recording execution + replay is exactly what’s missing once you move past simple logging.

One thing I’ve found tricky in similar setups is making sure the trace is captured before side-effects happen, otherwise replay can lie to you. If you get that boundary right, the prod → replay → fix → verify loop becomes much more reliable.

Really like the direction.

Theoretically yes, but CF workers or this project doesn't support it. Indeed none of the cloud providers support WASM as first-party support yet.

Sure thing. Got sidetracked this weekend with pre-work cleaning, will get back to it soon, hopefully.

I'm also working on execution recording/replay – the idea is to capture a deterministic trace of a request, so you can push it as a GitHub issue and replay it locally (or let an AI debug it).

k3s is a good non overkill alternative while benefiting from everything k8s offers.

Neat, thanks for taking the time to explain!

Indeed "global edge network and cache" is not my interest. I do prototyping so I don't care about scale or super low latency Worldwide. If I want to share a prototype I put on my small server in Germany, share the URL and voila, good enough.

That being said I understand others do, so this helps me understand the broader appeal of cloud workers and now some limits of this project.

Thanks for the clarification!

Damn I read "DevEx" before but not DX until today, damn I'm outdated!

Anyway, back to vim ;)