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.
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.
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)
If your usecase doesn't require redundancy or high-availability, why would you be using something like Cloudflare to start with?
Having a local backup user is a viable backup path then. If you wire up pam enough you can even use MFA for local login.
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.
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.
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.
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".
> Recently, with Claude's help, I rewrote everything on top of rusty_v8 directly.
worries me
As for beta vs. stable, Cloudflare Workers is generally somewhere in between. Every 6 weeks, Chrome and V8's dev branch is promoted to beta, beta branch to stable, and stable becomes obsolete. Somewhere during the six weeks between verisons, Cloudflare Workers moves from stable to beta. This has to happen before the stable version becomes obsolete, otherwise Workers would stop receiving security updates. Generally there is some work involved in doing the upgrade, so it's not good to leave it to the last moment. Typically Workers will update from stable to beta somewhere mid-to-late in the cycle, and then that beta version subsequently becomes stable shortly thereafter.
(I'm the lead engineer for Cloudflare Workers.)
OpenWorkers is really aimed at a different use case: running your own code on your own infra, where the threat model is simpler. Think internal tools, compliance-constrained environments, or developers who just want the Workers DX without the vendor dependency.
Appreciate the work you and the team have done on Workers, it's been the inspiration for this project for years.
"Hello, we are a serious cybersec firm and we have evaluated the code and here are our test with results that proof that we didn't find anything, the code is sound; Have we been through? We have, trust us!"
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.
We're thinking about OpenWorkers less as "self-hosted Cloudflare Workers" and more as a containment layer for code you don't fully control. V8 isolates, CPU/memory limits, no filesystem access, network via controlled bindings only.
We're also exploring execution recording - capture all I/O so you can replay and audit exactly what the code did.
Production bug -> replay -> AI fix -> verified -> deployed.
As a TinyKVM / KVM Server contributor I'm obviously hopeful our approach will work out, but we still have some way to go to get to a level of polish that makes it easy to get going with and have the confidence of production level experience.
TinyKVM has the advantage of a much smaller surface area to secure as a KVM based solution and the ability to offer fast per-request isolation as we can reset the VM state a couple of orders of magnitude faster than v8 can create a new isolate from a snapshot.
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.
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?
OpenWorkers CLI is in development. We're at the pre-wrangler stage honestly. Dashboard or API for now, wrangler-style DX with Github/GitLab integration is the goal.
We maintained it until we introduced bindings — at that point, we wanted more fine-grained control over the runtime internals, so we moved to raw rusty_v8 to iterate faster. We'll probably circle back and add the missing pieces to the deno runtime at some point.Cloud services are actually really nice and convenient if you were to ignore the eye watering cost versus DIY.
10% is the number I ordinarily see, counting for members of staff and adequate DR systems.
If we had paid our IT teams half of what we pay a cloud provider, we would have had better internal processes.
Instead we starved them and the cloud providers successfully weaponised extremely short term thinking against us, now barely anyone has the competence to actually manifest those cost benefits without serious instability.
GCP pricing is absolutely wicked when they charge $120/month for 4vcore 16gb ram, can get around 23 times more performance and 192gb ram for $350/month with Xtbps-ish ddos protection.
I have 2 2x7742 1tb ram each, 3 9950x3ds 192gb ecc, 2 7950x3d's all at <$600/month obv the original hardware cost in the realm of $60k - the epyc cpu's were bought used for around $1k each so not a bad deal, same with ram overall the true cost is <20k. This is entirely for personal use and will last me more than a decade most likely unless there are major gains in efficiency and power cost continues to grow due to AI demand. This also includes 100tb+ hdd of storage and 40tb of nvme storage all connected with 100gbps switch pair for redundancy for a cheap cheap price of $500 for each switch.
I guess I owe some links: (Ignore minecraft focused branding)
https://pufferfish.host/ (also offers colocation)
telegram: @Erikb_9gigsofram direct colocation at datacenter (no middlemen / sales) + good low cost bundle deal
anti-ddos: https://cosmicguard.com/ (might still offer colocation?)
anti-ddos: https://tcpshield.com/
I don't think after the fact that ram prices spiked 4-5x that its gonna be cheaper to self host by 100x, Like hetzner's or ovh's cloud offerings are cheap
Plus you have to put a lot of money and then still pay for something like colocation if you are competing with them
Even if you aren't, I think that the models are different. They are models of monthly subscription whereas in hardware, you have to purchase it.
It would be interesting tho to compare hardware-as-a-service or similar as well but I don't know if I see them for individual stuff.
People need to realize that when you selfhost you can choose to follow physical business constraints. If no one is in the office to turn on a computer, you're good. Also consumer hardware is so powerful (even 10 year old hardware) that can easily handle 100k monthly active users, which is barely 3k daily users, and I doubt most SMBs actually need to handle anything beyond 500 concurrent users hardware wise. So if that's the choice it comes down to writing better and more performant software, which is what is lacking nowadays.
People don't realize how good modern tooling + hardware has come. You can get by with very little if you want.
I'd bet my years salary that a good 40% of AWS customers could probably be fine with a single self hosted server using basic plug in play FOSS software on consumer hardware.
People in our industry have been selling massive lies on the need for scalability, the amount of companies that require such scalability are quite small in reality. You don't need a rocket ship to walk 2 blocks, and it often feels like this is the case in our industry.
If self hosting is "too scary" for your business, you can buy a $10 VPS but after one single year you can probably find decade old hardware that is faster than what you pay for.
That’s the key. If you need one person or 3 persons doesn’t matter. The point is the salaries are fixed costs.
But all the stateful crap (like databases) gets trickier and harder the more machines you have.
I searched hetzner and honestly at just around the 500 mark (506.04) seeing it on their refurbished auction for sale, I can get around 1024 GB of ram AMD EPYC 7502 2 x 1.92 TB Datacenter SSD
In this ramflation imagine getting so much ram would cost a bank.
Like I love homelabbing too and I think that an old laptop sometimes can be enough for basic things to even more modern things but I did some calculations and colocrossing or the professional renting model or even buying new hardware model in this ramflation would probably not work.
It's sad but like, the only place it might make sense is if you can get yourself a good firewall and have an old laptop or server and will do something like this but even then I have heard it be described as not worth it by many but I think its an interesting experiment.
Also regarding the 1024 GB of ram's, holy.. I wonder how many programs need so much ram. I will still do homelabbing and things but like, y'know I am kinda hard pressed in how much we can recommend if ramflation is so much and that's when I saw someone originally writing saying 100x I really wondered how much is enough and at what scale or what others think
But I don't know much about how it is a real world and normal 9 to 5 I have taken up jobs from system administration to reverse engineering and to even making plugins and infrastructure for minecraft I generally only work these days when people don't have any other choice and need someone who is pretty good at everything so I am completely out of the loop.
small clusters can be run with minimal knowledge which means the added cost is $0.
It would be interesting to see the scale of basecamp. I just saw right now that hetzner offers 1024 GB of ram for around 500$
Um 37signals spent around 700k$ I think on servers so if someone has this much amount of money floating around, perhaps.
Yea I looked at their numbers and they mentioned a 1300$/month for just hardware for 1.3 TB and so hetzner might still make economically more sense somehow.
I think the problem for some of these is that they go too hard on the managed services and those are good sometimes as well but like, there are cheaper managed cloud than aws etc. as well (upcloud,ovh etc.) but at the end of the day, it's good to remember that if it bothers you financially, you can migrate.
Honestly do whatever you want. Start however you want because like these things definitely interest me (which is why I am here) but I think most compute providers have really gone the path of the bottom.
The problem usually feels to me when you are worried that you might break the term of service or anything similar if you are at scale or anything, not that this stops exactly being a problem with colo but that still brings more freedom
I think if one wants freedom, they can always contact some compute providers and find what can support their use case the best while still being economical. And then choose the best option from the multitude of available options.
Also vertical scaling is a beast.
I really went into learning a lot about cloud prices recently etc. so I want to ask a question but can you tell me more about the servers that 37signals brought or any other company you know of, I can probably create a list when it makes sense and when it doesn't perhaps and the best options available in markets.
How is the cost of NAT free?
> Cloud services are actually really nice and convenient if you were to ignore the eye watering cost versus DIY.
I don't doubt clouds are expensive, but in many countries it'd cost more to DIY for a proper business. Running a service isn't just running the install command. Having a team to maintain and monitor services is already expensive.
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
Maybe. I agree AWS is over-priced. However it shouldn't be "free".
> It's next to free self hosting considering even the crappiest consumer router
That's not the same product / service is it? We're discussing networking products and this "crappiest" consumer router wouldn't even push real world 100m of packets.
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.
So it should be free? The bank already has "money". It's already there so you can take it?
That's not how it works.
Do you not get a managed service where someone upgrades it, deals with outages etc? Are those people that work 24/7 free or is it another "already there"?
And there are things that come for free when you have instrastructure this big and expansive - one-time configuration and you either monetize it or pass down the savings and since every cloud service is in agreement that profits should be maximized you end up with cloud providers which have massive datacenters at very cheap cost due to economies of scale providing it at a value far exceeding normal hosting practices due to their ability to monopolize and spend vasts amount of money onboarding businesses with false promises which errodes the infrastructure for non-cloud solutions and makes cloud providers the only choice for any business as the talent and software ends up going into maintenance mode and/or turns towards higher profitability to keep themselves afloat.
Please read it again.
> Please read it again.
There’s no need to be rude.
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 get the impression this can't be run without NodeJS right now?
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>
For D1: our DB binding is Postgres-based, so the API differs slightly. Same idea, different backend.
Hono should just work, it just needs a manual build step and copy paste for now. We will soon host OpenWorkers dashboard and API (Hono) directly on the runner (just some plumbing to do at this point).
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:
To me, the principal differentiator is the elasticity. I start and retire instances according to my needs, and only pay for the resources I've actually consumed. This is only possible on a very large shared pool of resources, where spikes of use even out somehow.
If I host everything myself, the cloud-like deployment tools simplify my life, but I still pay the full price for my rented / colocated server. This makes sense when my load is reasonably even and predictable. This also makes sense when it's my home NAS or media server anyway.
(It is similar to using a bus vs owning a van.)
The value proposition of function-as-a-service offerings is not "cloud" buzzwords, but providing an event-handling framework where developers can focus on implementing event handlers that are triggered by specific events.
FaaS frameworks are the high-level counterpart of the low-pevel message brokers+web services/background tasks.
Once you include queues in the list of primitives, durable executions are another step in that direction.
If you have any experience developing and maintaining web services, you'll understand that API work is largely comprised of writing boilerplate code, controller actions, and background tasks. FaaS frameworks abstract away the boilerplate work.
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".
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?
Wall-clock timeout is configurable (default 30s), CPU limits too. We haven't prioritized long-running tasks or WebSockets yet, but shouldn't be hard to add.
Having options that mimic paid services is a good thing and helps with adoptability.
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.
What's next: execution recording. Every invocation captures a trace: request, binding calls, timing. Replay locally or hand it to an AI debugger. No more "works on my machine".
I think the CLI will look like:
# Replay a recorded execution:
openworkers replay --execution-id abc123
# Replay with updated code, compare behavior:
openworkers replay --execution-id abc123 --worker ./dist/my-fix.js
Production bug -> replay -> AI fix -> verified -> deployed. That's what I have in mind.
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.
edit: if the idea was to have compatibility with cloudflare workers, workers can run deno https://docs.deno.com/examples/cloudflare_workers_tutorial/
Recently really enjoying CloudFlare Workflows (used it in https://mafia-arena.com) and would be nice to build Workflows on top of this too.
The last time I tried it, the cold start was over 10 seconds, making it unusable for any practical use case. Maybe the tech is not there but given that WASM guarantees the sandboxing already and supports multiple languages, I was hoping we would have providers investing in it.
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?
Damn I read "DevEx" before but not DX until today, damn I'm outdated!
Anyway, back to vim ;)
I'm not the blogger, I'm just a developer who works professionally with Cloudflare Workers. To me the main value proposition is avoiding vendor lock-in, and even so the logic doesn't seem to be there.
The main value proposition of Cloudflare Workers is being able to deploy workers at the edge and use them to implement edge use cases. Meaning, custom cache logic, perhaps some pauthorization work, request transformation and aggregation, etc. If you remove the global edge network and cache, you do not have any compelling reason to look at this.
It's also perplexing how the sales pitch is Rust+WASM. This completely defeats the whole purpose of Cloudflare Workers. The whole point of using workers is to have very fast isolates handling IO-heavy workloads where they stay idling the majority of the time so that the same isolate instance can handle a high volume of requests. WASM is notorious for eliminating the ability to yield on awaits from fetch calls, and is only compelling if your argument is a lift-and-shift usecase. Which this ain't it.
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.