max_lt

9 ms·

1.
by max_lt 9mo ago
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,
2.
by max_lt 9mo ago
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 thoug
3.
by max_lt 9mo ago
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.j
4.
by max_lt 9mo ago
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
5.
by max_lt 9mo ago
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 thinkin
6.
by max_lt 9mo ago
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 invocatio
7.
by max_lt 9mo ago
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.
8.
by max_lt 9mo ago
Conclusion shared. No Node required — the runtime is pure Rust + V8. The only transformation we do is transpilation for TS code.
9.
by max_lt 9mo ago
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.
10.
by max_lt 9mo ago
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
11.
by max_lt 9mo ago
CF Workers does support WASM. We do too as V8 handles it natively. Tested it, works, just hasn't been polished yet.
12.
by max_lt 9mo ago
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 p
13.
by max_lt 9mo ago
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 wh
14.
by max_lt 9mo ago
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.
15.
by max_lt 9mo ago
Thanks for the heads up! Fixed – added a simplified ASCII version for mobile.
16.
by max_lt 9mo ago
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 Cloudfla
17.
by max_lt 9mo ago
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.
18.
by max_lt 9mo ago
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 updat
19.
by max_lt 9mo ago
Great point, thanks. Just updated the site – removed "untrusted" and "secure", added a note clarifying the threat model
20.
by max_lt 9mo ago
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).
21.
by max_lt 9mo ago
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.
22.
by max_lt 9mo ago
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
23.
by max_lt 9mo ago
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.
24.
by max_lt 9mo ago
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.)
25.
Show HN: OpenWorkers – Self-hosted Cloudflare workers in Rust(openworkers.com)
500 points by max_lt 9mo ago|158 comments