It raises the interesting question of what is the best isolation for a browser side sandbox.
Running a worker.
Running a worker running a js implementation.
Running a worker running a wasm module running a js implementation (quickjs) running some passed code.
Running a worker running what kyu build runs.
And then of course the possibility of a environment where you pass it an integer n and it geneates n levels of. Nested layers with a randomly chosen implementation at each layer.
Security by obfuscurity, is that a thing?
Might be fun to implent the kyu wasm files as an executable format on my dumb cli idea. https://lerc.neocities.org/
(Kyu seems to fight my autocorrect wanting to turn it into you)
I'm not sure if service workers are particularly amenable to having Developer A provide an interface for User B to run untrusted code made by Developer C, D and E.
ELI5: Imagine you want to run a heavy, powerful 3D video game engine inside a standard web browser or a lightweight desktop app, without making it slow or unsafe.
JavaScript alone can't handle that kind of heavy lifting efficiently. That’s where Wasm comes in. It lets you run high-performance native code (like C++) at near-native speed safely in the sandbox.
For example, I'm currently using Wasm to run a complex 3D geometry engine (Manifold) inside a lightweight CAD app (Nasscad). It gives you web flexibility with desktop power.
I think they are asking about the tool itself, not WASM.
This tool seems useful for running 0 dependency JavaScript with isolation through web assembly as an alternative to the isolation and ease of use provided by tools such as cloudflare workers.
I think that this is a plugin library for teams that want to offer a platform for the public (or an LLM-AI) to submit code to. If your team writes some code, you don't generally sandbox it from yourself, you just amend your program: you don't need a sandbox. But, if you want to run code that you don't trust, you should run it in a way that prevents it from causing problems if it is actually dangerous (like a virus or accidentally overwrites your files with blank files). That's what a sandbox like kyushu promises to do.
So, with a sandbox library like this, you could - say - write a website that hosts games (like itch.io or newgrounds) that hosts games on the world wide web. The sandbox part can give you confidence that, if a villain's programmer henchmen uploads a virus instead of a game, it can't infect your platform or other games on the website. Or, if a LLM-AI written game is accidentally tries to take up all the memory of the computer, it can't ask the operating system for more than is in the sandbox.
Firecracker launches small, but otherwise general purpose virtual machines. Containers, at least the standard implementations that most of us use, use kernel features like namespaces to isolate workloads, but still share a kernel so the sandboxing is not as strong.
Wasm is a virtual machine, just like for example the jvm is, that is designed around only allowing the executed program access to the host runtime via specific apis that are subject to security policies. It does not run arbitrary software, but rather only software built to target specifically wasm.
The software this post is about is just bundling a wasm runtime with other software for convenience.
Others mentioned better use cases than I could probably come with. Not sure it's a strong use case but, one thing I could maybe mention too is the fact that it ships as a standalone artifact. It's portable and, if reproducible, can provide some sort of guarantee on what's effectively running for those who care.
What approach are you using? Been working on a similar in-browser node runtime based on Rust/WASM kernel + Service-Worker HTTP intercept + CJS→ESM transform.
Feature wise, does this compare to StackBlitz webcontainers?
I had previous experience with QuickJS - respectively using the rquickjs crate (awesome project) - so my approach was first asserting whether it was possible to run a Wasmtime binary that both executes the JS code and handles HTTP requests and responses.
Then, the second part which was really important to me, was figuring out if I could find a way to embed the developer's JS code within the worker without requiring them to install Cargo. (thanks to Wizer it's possible, love it).
Once I had those two, the rest was basically execution (not saying it was straightforward though ;)
I was also a bit lucky: at the same time as I was developing it, Rolldown announced the version 1 of their standalone crate. So it was the perfect timing to use it as well.
As for StackBlitz WebContainers, I actually don't know much about it. They run in the browser as I understand, so fundamentally different but, feature wise I'm sure this project is way more mature and therefore offers way more features.
Awesome, thanks for detailing the thought flow and choices that led you here. I chose not to go the QuickJS route for performance reasons but I think it's a solid choice depending on the use case.
> They run in the browser as I understand, so fundamentally different
Yes, runs entirely in the browser, while this is a hosted product. StackBlitz technology is really good but it is closed source.
Yeah I was surprised by this when I opened their website.
Your setup - Rust/WASM kernel + Service worker - sounds really sweet. If already public, please do share the link, else looking forward to your launch!
- 九州: Largest island mass of southwest Japan comprising 7 states. Currently undergoing a real estate boom (and agricultural worker shortage) because of TMSC opening factories
Great use case for edge functions and plugin systems. How does the startup latency compare to running the same code in a V8 isolate like Cloudflare Workers?
I haven't benchmarked it yet but, guts feeling, would expect it to be (a bit?) slower. Cloudflare has likely spent quite some effort optimizing it and also runs fast machine. Kyushu uses QuickJS which adds a layer that needs to be loaded but, it's pre-initialization in memory which should mitigate the cost.
I’ve worked with Wasm for about 6 years now (founded a company around it that got acquired, even)
Even though our product was not a commercial success ~3 yrs ago I still believe something like this should succeed and give people choice when it comes to isolation/virtualization (containers, microVMs, Wasm). They are each useful and appropriate for different things.
I started working on Nasscad back in early March with the assistance of Claude AI, and it led to Nasscad: a lightweight, powerful, and uncompromising CAD tool. I used to be allergic to HTML, Node.js, and the like. But we have to face the reality that the web stack dominates now—bringing along HTML, CSS, JavaScript, Wasm, frontend, and backend.
Thx! I thought about adding a context to the fetch handler, could be handy for local testing. Likewise, local commands (e.g. dev or watch mode) are not yet there. Those would be next on the line if the CLI starts getting used by others than me.
You can definitely run workerd in production on your own machines and some people do.
The biggest catch is that workerd's implementation of Durable Objects currently doesn't work across multiple machines, but I'm working on fixing that: https://github.com/cloudflare/workerd/pull/6780
I wouldn't rush and jump straight to it at this point, as mentioned it's early and relatively experimental at this point, but technically, at least for relatively simple function, yes.
Thanks! It's actually the first time I started "designing" (I'm definitely not one) everything by picking the theme for the code snippets first. That's why the same colors are reused on the site and even in the logo.
It raises the interesting question of what is the best isolation for a browser side sandbox.
Running a worker.
Running a worker running a js implementation.
Running a worker running a wasm module running a js implementation (quickjs) running some passed code.
Running a worker running what kyu build runs.
And then of course the possibility of a environment where you pass it an integer n and it geneates n levels of. Nested layers with a randomly chosen implementation at each layer.
Security by obfuscurity, is that a thing?
Might be fun to implent the kyu wasm files as an executable format on my dumb cli idea. https://lerc.neocities.org/
(Kyu seems to fight my autocorrect wanting to turn it into you)
The best isolation is inside a Service Worker, where the script is served with Content-Security-Policy: sandbox header.[1]
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
I'm not sure if service workers are particularly amenable to having Developer A provide an interface for User B to run untrusted code made by Developer C, D and E.
Or just an iframe?
related: "Kefka is a Go-native shell sandbox with coreutils, Python via WebAssembly, and more" https://xeiaso.net/blog/2026/dancing-mad-sandboxing/
Loving the customer testimonials :D ..
If someone feels like an eli5 - What are the use-cases for something like this?
ELI5: Imagine you want to run a heavy, powerful 3D video game engine inside a standard web browser or a lightweight desktop app, without making it slow or unsafe.
JavaScript alone can't handle that kind of heavy lifting efficiently. That’s where Wasm comes in. It lets you run high-performance native code (like C++) at near-native speed safely in the sandbox.
For example, I'm currently using Wasm to run a complex 3D geometry engine (Manifold) inside a lightweight CAD app (Nasscad). It gives you web flexibility with desktop power.
Thanks for that!
I think they are asking about the tool itself, not WASM.
This tool seems useful for running 0 dependency JavaScript with isolation through web assembly as an alternative to the isolation and ease of use provided by tools such as cloudflare workers.
> powerful 3D video game engine inside a standard web browser [...] JavaScript alone can't handle that kind of heavy lifting efficiently.
True... but also WebGL/WebGPU on Vulkan/Metal/etc is a thing. You can run shaders on your GPU via the Web already.
I think that this is a plugin library for teams that want to offer a platform for the public (or an LLM-AI) to submit code to. If your team writes some code, you don't generally sandbox it from yourself, you just amend your program: you don't need a sandbox. But, if you want to run code that you don't trust, you should run it in a way that prevents it from causing problems if it is actually dangerous (like a virus or accidentally overwrites your files with blank files). That's what a sandbox like kyushu promises to do.
So, with a sandbox library like this, you could - say - write a website that hosts games (like itch.io or newgrounds) that hosts games on the world wide web. The sandbox part can give you confidence that, if a villain's programmer henchmen uploads a virus instead of a game, it can't infect your platform or other games on the website. Or, if a LLM-AI written game is accidentally tries to take up all the memory of the computer, it can't ask the operating system for more than is in the sandbox.
how is it different from firecracker or other containerization ? what makes it secure enough to make those claims?
Firecracker launches small, but otherwise general purpose virtual machines. Containers, at least the standard implementations that most of us use, use kernel features like namespaces to isolate workloads, but still share a kernel so the sandboxing is not as strong.
Wasm is a virtual machine, just like for example the jvm is, that is designed around only allowing the executed program access to the host runtime via specific apis that are subject to security policies. It does not run arbitrary software, but rather only software built to target specifically wasm.
The software this post is about is just bundling a wasm runtime with other software for convenience.
Haha, glad someone noticed those testimonials ;)
Others mentioned better use cases than I could probably come with. Not sure it's a strong use case but, one thing I could maybe mention too is the fact that it ships as a standalone artifact. It's portable and, if reproducible, can provide some sort of guarantee on what's effectively running for those who care.
it is also perfect for running untrusted user code safely, if you want to buld a plugin system or your own edge functions this can be really helpful
Very cool work.
What approach are you using? Been working on a similar in-browser node runtime based on Rust/WASM kernel + Service-Worker HTTP intercept + CJS→ESM transform.
Feature wise, does this compare to StackBlitz webcontainers?
I had previous experience with QuickJS - respectively using the rquickjs crate (awesome project) - so my approach was first asserting whether it was possible to run a Wasmtime binary that both executes the JS code and handles HTTP requests and responses.
Then, the second part which was really important to me, was figuring out if I could find a way to embed the developer's JS code within the worker without requiring them to install Cargo. (thanks to Wizer it's possible, love it).
Once I had those two, the rest was basically execution (not saying it was straightforward though ;)
I was also a bit lucky: at the same time as I was developing it, Rolldown announced the version 1 of their standalone crate. So it was the perfect timing to use it as well.
As for StackBlitz WebContainers, I actually don't know much about it. They run in the browser as I understand, so fundamentally different but, feature wise I'm sure this project is way more mature and therefore offers way more features.
Awesome, thanks for detailing the thought flow and choices that led you here. I chose not to go the QuickJS route for performance reasons but I think it's a solid choice depending on the use case.
> They run in the browser as I understand, so fundamentally different
Yes, runs entirely in the browser, while this is a hosted product. StackBlitz technology is really good but it is closed source.
Yeah I was surprised by this when I opened their website.
Your setup - Rust/WASM kernel + Service worker - sounds really sweet. If already public, please do share the link, else looking forward to your launch!
Will do, thanks!
Kyushu:
- 九州: Largest island mass of southwest Japan comprising 7 states. Currently undergoing a real estate boom (and agricultural worker shortage) because of TMSC opening factories
- 吸収: absorb
- 急襲: ambush, surprise|sudden assault
Great use case for edge functions and plugin systems. How does the startup latency compare to running the same code in a V8 isolate like Cloudflare Workers?
I haven't benchmarked it yet but, guts feeling, would expect it to be (a bit?) slower. Cloudflare has likely spent quite some effort optimizing it and also runs fast machine. Kyushu uses QuickJS which adds a layer that needs to be loaded but, it's pre-initialization in memory which should mitigate the cost.
I’ve worked with Wasm for about 6 years now (founded a company around it that got acquired, even)
Even though our product was not a commercial success ~3 yrs ago I still believe something like this should succeed and give people choice when it comes to isolation/virtualization (containers, microVMs, Wasm). They are each useful and appropriate for different things.
I started working on Nasscad back in early March with the assistance of Claude AI, and it led to Nasscad: a lightweight, powerful, and uncompromising CAD tool. I used to be allergic to HTML, Node.js, and the like. But we have to face the reality that the web stack dominates now—bringing along HTML, CSS, JavaScript, Wasm, frontend, and backend.
cool idea of a self-hostable alternative ot CF workers without much overhead, compiling it down to a binary makes local testing way easier.
Thx! I thought about adding a context to the fetch handler, could be handy for local testing. Likewise, local commands (e.g. dev or watch mode) are not yet there. Those would be next on the line if the CLI starts getting used by others than me.
*Update:* I've got a draft PR for `kyu dev` with live reload.
*Update*: Done. `kyu dev` is implemented and released :)
I thought CF workers could be self-hosted? I haven't tried that system but saw Kenton Varda tweeting about running them locally for development.
Yes, the Cloudflare Workers Runtime is open source: https://github.com/cloudflare/workerd
You can definitely run workerd in production on your own machines and some people do.
The biggest catch is that workerd's implementation of Durable Objects currently doesn't work across multiple machines, but I'm working on fixing that: https://github.com/cloudflare/workerd/pull/6780
so am I able to migrate my current cloudflare worker API to this ?
I wouldn't rush and jump straight to it at this point, as mentioned it's early and relatively experimental at this point, but technically, at least for relatively simple function, yes.
As a matter of fact, I did it myself in one of my pipelines. Here's the related PR https://github.com/peterpeterparker/blog-to-newsletter-worke...
interesting I think if I could migrate off cloudflare and sort of have a hybrid back up in case cloudflare goes down again
Looking forward to see more developments on this as it has real economic value if it does work.
the customer testimonials were enough to earn my github star
I did quite a market research to gather them ;)
ROFL
nice site design
Thanks! It's actually the first time I started "designing" (I'm definitely not one) everything by picking the theme for the code snippets first. That's why the same colors are reused on the site and even in the logo.