max_lt

Yes, I see this is a popular request. Will add it soon. For now, compose files are in the infra repo: https://github.com/openworkers/openworkers-infra

Fun fact: I tried K8s early on but found it overkill for my setup, so I stayed on Compose. Will revisit it properly now.

Docker compose is here: https://github.com/openworkers/openworkers-infra

Images are on ghcr.io. I code on ARM myself and the runner build image is multi-platform, so it should work. Haven't tested in a while though, let me know how it goes!

Wrangler file format: not planned. We're taking a different approach for config but we intend to be compatible with Cloudflare adapters (SvelteKit, Astro, etc). Assets binding already has the same API. We just need to support _routes.json and add static file routing on top of workers, data model is ready for it.

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).

WASM is supported, V8 handles it natively. Tested it briefly, works, but not user-friendly at all yet.

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.

This is exactly where we see things heading. The trust model is shifting - code isn't written by humans you trust anymore, it's generated by models that can be poisoned, confused, or just pick the wrong library.

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.

Workers that hit limits (CPU, memory, wall-clock) get terminated cleanly with a clear reason. Exceptions are caught with stack traces (at least it should lol), logs stream in real-time.

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.

Good use case. For state between invocations, we have KV (key-value with TTL), Storage (S3) and DB bindings (Postgres). Durable Objects not yet but it's on the roadmap.

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.

Conclusion shared. No Node required — the runtime is pure Rust + V8. The only transformation we do is transpilation for TS code.

The DX is great: simple deployment, no containers, no infra to manage. I build a lot of small weekend projects that I don't want to maintain once shipped. OpenWorkers gives you the same model when you need compliance or data residency.

Thanks for the clarification on CF's V8 patching strategy, that 24h turnaround is impressive and exactly why I point people to Cloudflare when they need production-grade multi-tenant security.

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.

CF Workers does support WASM. We do too as V8 handles it natively. Tested it, works, just hasn't been polished yet.

Thanks for that work! deno_core is a beautiful piece of work and is still an option for OpenWorkers: https://github.com/openworkers/openworkers-runtime-deno

  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.

Deno core is great and I didn't really abandon Deno – we support 5 runtimes actually, and Deno is the second most advanced one (https://github.com/openworkers/openworkers-runtime-deno). It broke a few weeks ago when I added the new bindings system and I haven't had time to fix it yet. Focused on shipping bindings fast with the V8 runtime. Will get back to Deno support soon.

Thanks! Workflows is definitely interesting – it's basically durable execution with steps and retries. It's on the radar, probably after the CLI and GitHub integration.

Thanks for the heads up! Fixed – added a simplified ASCII version for mobile.

Thanks! Main differences: 1. Complete stack: workerd is just the runtime. OpenWorkers includes the full platform – dashboard, API, scheduler, logs, and self-hostable bindings (KV, S3/R2, Postgres). 2. Runtime: workerd uses Cloudflare's C++ codebase, OpenWorkers is Rust + rusty_v8. Simpler, easier to hack on. 3. Managed offering: Yes, there's already one at dash.openworkers.com – free tier available. But self-hosting is a first-class citizen.

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.

Agreed. Cloudflare has dedicated security teams, 24h V8 patches, and years of hardening – I can't compete with that. The realistic use case for OpenWorkers is running your own code on your own infra, not multi-tenant SaaS. I will update the docs to reflect this.

Great point, thanks. Just updated the site – removed "untrusted" and "secure", added a note clarifying the threat model

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).

Not yet, but it's one of the next big features. I'm currently working on the CLI (WIP), and GitHub integration with auto-deploy on push will come after that. A yaml config for bindings/cron is definitely on the roadmap too.

Fair point. The V8 isolate provides memory isolation, and we enforce CPU limits (100ms) and memory caps (128MB). Workers run in separate isolates, not separate processes, so it's similar to Cloudflare's model. That said, for truly untrusted third-party code, I'd recommend running the whole thing in a container/VM as an extra layer. The sandboxing is more about resource isolation than security-grade multi-tenancy.

Good idea! Main things not yet implemented: Durable Objects, WebSockets, HTMLRewriter, and cache API. Next priority is execution recording/replay for debugging. I'll add a roadmap section to the docs.

It's a custom V8 runtime built with rusty_v8, not the actual Cloudflare runtime (github.com/openworkers/openworkers-runtime-v8). The goal is API compatibility – same Worker syntax (fetch handler, Request/Response, etc.) so you can migrate code easily. Under the hood it's completely independent.

I've been working on this for some time now, starting with vm2, then deno-core for 2 years, and recently rewrote it on rusty_v8 with Claude's help.

  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.