OpenWorkers lets you run untrusted JS in V8 isolates on your own infrastructure. Same DX as Cloudflare Workers, no vendor lock-in.
What works today: fetch, KV, Postgres bindings, S3/R2, cron scheduling, crypto.subtle.
Self-hosting is a single docker-compose file + Postgres.
Would love feedback on the architecture and what feature you'd want next.
- > It brings the power of edge computing to your own infrastructure.
I like the idea of self-hosting, but it seems fairly strongly opposed to the concept of edge computing. The edge is only made possible by big ass vendors like Cloudflare. Your own infrastructure is very unlikely to have 300+ points of presence on the global web. You can replicate this with a heterogeneous fleet of smaller and more "ethical" vendors, but also with a lot more effort and downside risk.
- The problem with sandboxing solutions is that they have to provide very solid guarantees that code can't escape the sandbox, which is really difficult to do.
Any time I'm evaluating a sandbox that's what I want to see: evidence that it's been robustly tested against all manner of potential attacks, accompanied by detailed documentation to help me understand how it protects against them.
This level of documentation is rare! I'm not sure I can point to an example that feels good to me.
So the next thing I look for is evidence that the solution is being used in production by a company large enough to have a dedicated security team maintaining it, and with real money on the line for if the system breaks.
- Cool project, great work!
Forgive the uninformed questions, but given that `workerd` (https://github.com/cloudflare/workerd) is "open-source" (in terms of the runtime itself, less so the deployment model), is the main distinction here that OpenWorkers provides a complete environment? Any notable differences between the respective runtimes themselves? Is the intention to ever provide a managed offering for scalability/enterprise features, or primarily focus on enabling self-hosting for DIYers?
- Perhaps it might be helpful to some to also lay out the things that don't work today (or eg roadmap of what's being worked on that doesn't currently work?). Anyway, looks very cool!
- I see anything that reduces the relience on vendor lock-in I upvote. Hopefully cloud services see mass exodus so they have to have reasonable pricing that actually reflects their costs instead of charging more than free for basic services like NAT.
Cloud services are actually really nice and convenient if you were to ignore the eye watering cost versus DIY.
- I did a huge chunk of work to split deno_core from deno a few years back and TBH I don't blame you from moving to raw rusty_v8. There was a _lot_ of legacy code in deno_core that was challenging to remove because touching a lot of the code would break random downstream tests in deno constantly.
- To the author: The ASCII-art Architecture diagram is very broken, at least on my Pixel phone with Firefox.
These kinds of text-based diagrams are appealing for us techies, but in the end I learned that they are less practical. My suggestion is to use an image, and think of the text-based version as the "source code" which you keep, meanwile what gets published is the output of "compiling" it into something that is for sure always viewable without mistake (that one is where we tend to miss it with ascii-art).
- I've decided to ditch CF because Wrangler is deployed via NPM and I cannot bear NodeJS and Microsoft NPM anymore.
I get the impression this can't be run without NodeJS right now?
- Self-hosted workers are becoming critical infrastructure for AI agent workloads. When you're running agents that need to interact with external services - web scraping, API orchestration, browser automation - you hit Cloudflare's execution limits fast. The 30s CPU time on the free tier and even the 15min on paid plans don't work for long-running agent tasks.
The isolation model here is interesting. For agents that need to handle untrusted input (processing user URLs, parsing arbitrary documents), V8 isolates give you a security boundary that's much lighter than full container isolation. But you trade off the ability to do things like spawn subprocesses or access the filesystem.
Curious about the persistence story. Most agent workflows need some form of state between invocations - conversation history, task progress, cached auth tokens. Is there a built-in KV store or does this expect external storage?
- What if we hosted the cloud... on our own computers?
I see we have entered that phase in the ebb and flow of cloud vs. self-hosting. I'm seeing lots of echoes of this everywhere, epitomised by talks like this:
- Isn't the whole point of Cloudflare's Workers to pay per function? If it is self-hosted, you must dedicate hardware in advance, even if it's rented in the cloud.
- Cool. I always liked CF workers but haven’t shipped anything serious with it due to not wanting vendor lock-in. This is perfect for knowing you always got a escape hatch.
- Good to see this! Cloudflare's cool, but those locked-in things (KV, D1, etc.) always made it hard to switch. Offering open-source alternatives is always good, but maintainign them is on the community. Even without super-secure multi-tenancy, being able to run the same code on your own stuff or a small VPS without changing the storage is a huge dev experience boost.
- Amazing work!
I have been thinking exactly about this. CF Workers are nice but the vendor lock-in is a massive issue mid to long term. Bringing D1 makes a lot of sense for web apps via libSql (SQLite with read/write replicas).
Do you intended to work with the current wrangler file format? Does this currently work with Hono.js with the cloudflare connector>
- Technically, and architecturally this is excellent. It’s also an excellent product idea. And I’m particularly a fan of the big-ass-vendor-inversion-model where instead of the big ass vendor ripping off an open source project and monetizing it, you look at one of their projects and you rip it off inversely and open source it — this is the way.
- Cool project, but I never found the cloudflare DX desirable compared to self hosted alternatives. A plain old node server in a docker container was much easier to manage, use and is scalable. Cloudflare's system was just a hoop that you needed to jump through to get to the other nice to haves in their cloud.
- Any reason to abandon Deno?
edit: if the idea was to have compatibility with cloudflare workers, workers can run deno https://docs.deno.com/examples/cloudflare_workers_tutorial/
- I am always interested in seeing alternatives in the edge compute space but self hosting does not make sense to me.
The benefit of edge is the availability close to customers. Unless I run many servers, it is simply easier to run one server instead of "edge".
- Does this actually use the cloudflare worker runtime or is this just a way to run code in v8 isolates?
- Nice project.
One thing Cloudflare Workers gets right is strong execution isolation. When self-hosting, what’s the failure model if user code misbehaves? Is there any runtime-level guardrail or tracing for side-effects?
Asking because execution is usually where things go sideways.
- This is super nice! Thank you for working on this!
Recently really enjoying CloudFlare Workflows (used it in https://mafia-arena.com) and would be nice to build Workflows on top of this too.
- This is similar to what rivet (1) does, perhaps focusing more on stateless than rivet does
- Nice. An obvious link to the compose file would be great (I assume you have prebuilt images on ghcr.io?), and if it happens to work on ARM, I will certainly give it a try.
- I wonder why V8 is considered as superior compared to WASM for sandboxing.
- This is very nice! Do you plan to hook this up to GitHub, so that a push of worker code (and maybe a yaml describing the environment & resources) will result in a redeploy?
- I don't see a single license mentioned anywhere?
- Why would I want this over just sticking Node / Deno / Bun in a Docker container?
- Could you add a kubernetes deployment quick-start? Just a simple deployment.yaml is enough.
- Interesting option to consider next to openfaas
- DX?
I'm quite ignorant on the topic (as I never saw the appeal of Cloudflare workers, not due to technical problems but solely because of centralization) but what does DX in "goal has always been the same: run JavaScript on your own servers, with the same DX as Cloudflare Workers but without vendor lock-in." mean? Looks like a runtime or environment but looking at https://github.com/drzo/workerd I also don't see it.
Anyway if the "DX" is a kind of runtime, in which actual contexts is it better than the incumbents, e.g. Node, or the newer ones e.g. Deno or Zig or even more broadly WASI?
deleted