Show HN: Faasta – A self-hosted Serverless platform for WASM-wasi-HTTP in Rust

95 points by alexboehm 15 days ago

I've just released an early version off my project I've been working on for a few months now and would love some feedback.

https://github.com/fourlexboehm/faasta

I was surprised there isn't yet an open/source and standards compliant way to host wasi-http functions in a way that takes advantages of WASM, a multi tenanted application.

If you're not familiar with wasi, Compared to something like AWS Lambda, this approach is much more efficient as a single process can serve 1000s of function invocations concurrently and asynchronously, instead requiring an entire VM.

This is still early days for the project, but feel free to download the cli utility with cargo install cargo-faasta.

Feel free to test deploying functions on my hosted instance at https://website.faasta.xyz.

The service is free to use and currently supports deployments via GitHub OAuth, with a limit of 10 functions per GitHub account.

mrmagoo17 - 15 days ago

That's a really cool implementation! I hope I'll have some time soon to have a peek at the code. I am honestly a bit surprised to see that none of the major cloud providers are even thinking to leverage WASM and WASI for serverless...

Imustaskforhelp - 14 days ago

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.
- Imustaskforhelp - 14 days ago
  
  Cloudflare is literally magic with typescript. I swear, people like to give me that cloudflare example of gambling and show the time where their sales team messed up so hard but If we read that article, I think I can agree with Cloudflare because they were a gambling site... my gripe is that cloudflare could've been more professional, but hey mistakes happen , I genuinely hope that Cloudflare has moved on, Since if I ever create any website, any service whatever, Its most likely going to be on Cloudflare and I just hope that I don't get messed up like that guy.
  And also one key thing to note is you should probably not keep the domain itself in cloudflare if you are thaat paranoid and write something in hono if you really want portability (maybe its overkill??) and if you really get messed up like the gambling blog guy then you can easily switch away...
  Still ITS way too unlikely to happen I guess.
phickey - 14 days ago

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.
ebcase - 14 days ago

Check out Fastly’s WASM-powered Compute platform:
https://www.fastly.com/documentation/guides/compute/
(I work there)
- alexboehm - 14 days ago
  
  I have been playing with it, it's very cool to be able to run anywhere. Do you have plans to implement wasi-http? One of my concerns is the free tier only offers Compute as a trial, and $50 is pretty steep for a hobby project, are there plans to add Compute usage to the free tier?
alexboehm - 15 days ago

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.
- syrusakbary - 15 days ago
  
  > After delving into this, it seems Wasmer tried, but as they weren't standards compliant, adoption/ecosystem support never followed.
  You may be surprised by how much WASIX is being adopted by the ecosystem! Aiming it to be full POSIX compliant has proven incredibly powerful, as there's no need for waiting for other entities to reinvent what already works in the POSIX (macOS, Linux, ...) :)
  - alexboehm - 15 days ago
    
    I'm not discounting WASIX or what you guys are doing I'd love to just use wasm today for everything instead of waiting, I started this project by trying to use WASIX, I just found it quite difficult to actually develop for as many of the essential rust crates, seemed reluctant to merge your changes, and having to use dependency versions from a year ago with patches is very frustrating.
    
    syrusakbary - 14 days ago
    
    Fair! We have already plans to solve the patching issue you commented... stay tuned!
- sshine - 15 days ago
  
  So happy to see wasi-http become stable.
sitkack - 14 days ago

They don't want to kill their Golden Geese.

kaliqt - 14 days ago

Bun likely has a larger footprint than this but it's also gaining lots of traction: https://bun.sh/docs/runtime/loaders

How might this project differentiate itself from Bun as it grows? Because Bun aims to be compact and fast (fast being the priority in their case).

Imustaskforhelp - 14 days ago

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)
drewbitt - 14 days ago

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.

xkcd-sucks - 14 days ago

Unfortunate name collision with FASTA the bioinformatic sequence file format

digikata - 14 days ago

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

singularity2001 - 14 days ago

You could link to faasta.xyz in github about and add EXAMPLES there.

The lambdas should be able to be accessible via http(s) e.g.

https://square.faasta.xyz/3 => 9

https://faasta.xyz/square/3 => 9

Great idea if done right!

alexboehm - 14 days ago

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.
- singularity2001 - 14 days ago
  > I originally supported path prefix and subdomains
  please bring them back!

PhilippGille - 13 days ago

Is this similar to Fermyon's Spin?

https://github.com/spinframework/spin

badmonster - 15 days ago

Do you plan to support custom domains and SSL certificates for self-hosted Faasta deployments, or will that be handled externally via reverse proxies?

alexboehm - 15 days ago

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.
- badmonster - 15 days ago
  
  gotcha

foresterre - 14 days ago

Since there is no LICENSE in the repo, I assume this will not be an open source project? Will it have an open core or similar license?

alexboehm - 14 days ago

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.

lettersdigitsda - 14 days ago

[flagged]

alexboehm - 14 days ago

A more descriptive word would been self-hostable function as a service, that's why faas is in the name!
The point of serverless is you don't have to think about hosting, and ideally it's cheaper.
The problem is if the hosting provider goes away you're screwed. In the case of Faasta, it's a single static binary with minimal configuration so if that happens, you can host it your self or move to another provider.
- remram - 14 days ago
  
  How can you "not have to think about hosting" while self-hosting?
  - tormeh - 14 days ago
    
    I get the feeling it's basically an old-fashioned application server like Wildfly or Tomcat. So the developer doesn't worry about system-d config or whatever, but just adds their application files to a folder. Of course someone needs to maintain the application server, however it's deployed, but it detangles things a bit. I personally think this makes no sense unless someone else hosts the application server. Maybe in an enterprise context of some sort. Otherwise this feels like a tried-and-failed idea.
    
    alexboehm - 14 days ago
    
    The difference is Wasm provides the security boundary so it can be multi tenanted. The real magic is that wasi will be hostable anywhere much like Docker containers are today, but it's much more efficient than docker containers because there are less overheads and startup latency.
  - alexboehm - 14 days ago
    
    Well at that point you'll obviously start having to think about it. The point is you can easily move to self-hosting without rewriting everything.