Azure has shipped Spin as an experiment https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po... and is investing in Wasmtime and WASI https://opensource.microsoft.com/blog/2025/03/26/hyperlight-... (One author, Yosh, is the co-chair of WASI standards subgroup)

This platform is also based on wasmtime and wasmtime's wasi-http implementation, which I authored, so I'm really proud to see it reused here!

One more plug: I've been working on https://github.com/yoshuawuyts/wstd/ with Yosh and Dan Gohman (creator of WASI) as a nice way to write wasi-http guests in Rust.

Check out Fastly’s WASM-powered Compute platform:

https://www.fastly.com/documentation/guides/compute/

(I work there)

Cloudflare workers can do wasm and js.

I haven't tried with wasm personally because well, it has a limit of 25 mb and I am not sure but last time I read somewhere in their forums about some guy wishing to run golang, it had the issue that wasm could only be 1-2mb and golang's most basic example had it taken 1-2mb so they can't cook anything good.

Of course I can be wrong & I am just too lazy to search that article to remember the facts again.

After delving into this, it seems Wasmer tried, but as they weren't standards compliant, adoption/ecosystem support never followed.

The Bytecode alliance is taking their time stabilizing wasi. wasip2 which is needed for the wasi-http realm this relies on has only really existed for a few months as a stable Rust target, and still misses a lot of the really cool features that will come with wasip3 like full async support.

I suspect Cloud providers will adopt wasi after 1.0, but that is likely years away. I don't think wasi-http will change much before then so now is the time to start building with it.

They don't want to kill their Golden Geese.

As someone who uses bun,deno & cloudflare workers, I want to say that atleast in bun, the wasm part actually happens itself in js and bun just runs that js using javascriptcore which is definitely not optimized as it is stated by Bun docs themselves (https://bun.sh/docs/runtime/loaders#wasi)

Also I am still not sure how you are thinking that this project is similar to Bun.

Bun is for javascript, somebody runs wasm in js and that on bun...

Faasta runs wasm directly and you would need to use javy to actually run js in Faasta https://github.com/bytecodealliance/javy

Its sort of like a->b or b->a and faasta is way more leaner and better... Though bun is good if you are all Typescript.

Still I am sure I am not able to explain myself clearly, so do ask me something if you think I haven't explained quite properly and I am obviously sorry about that!

(Side note: but my main gripe with deno is that I have to specify all of these permissions and its still not a 1:1 equivalent to nodejs , like its very close still though so I still used bun and I actually used just today bun to install pnpm and then install wrangler and then remove pnpm and install via bun because for some reason wrangler doesn't recognize bun as package manager but whatever right)

That this is like Bun is a stretch. This runs anything directly that can compile to WASI P2. Bun polyfills wasi-js to run WASI P1 inside JS.

Could perhaps be fixed by adding a "R" for rust at the end: Faastar

Thanks for the feedback, I've added the URL to about, I originally supported path prefix and subdomains, but I found it slightly more confusing to communicate to users. I'm definitely planning on more example.

The plan is for it to be an opensource project, currently the cli and interface crates are MIT, I have been considering a copyleft license for the server, or a dual licensing strategy.

For self hosted, if you use porkbun for DNS it will automatically pull a wildcard SSL cert using the API at startup.

I plan to also support multiple custom domain certs on a multi tenanted instance like faasta.xyz. For now I'd recommend a reverse proxy though.