Show HN: Riza – Safely run untrusted code from your app

Show HN: Riza – Safely run untrusted code from your app(riza.io)

11 points by conroy 2 years ago | 6 comments

Hi HN, I’m Kyle and together with Andrew (https://news.ycombinator.com/user?id=stanleydrew) we’ve been working on Riza (https://riza.io), a project to make WASM sandboxing more approachable. We’re excited to share a developer preview of our code interpreter API with HN.

There’s a bit of a backstory here. A few months ago, an old coworker reached out asking how to execute untrusted code generated by an LLM. Based on our experience building a plugin system for sqlc (https://sqlc.dev), we thought a sandboxed WASM runtime would be a good fit. A bit of hacking later, we got everything wired up to solve his issue. Now the API is ready for other developers to try out.

The Riza Code Interpreter API is an HTTP interface to various dynamic language interpreters, each running inside a WASM sandbox without access to the outside world (for now). We modeled the API to align with a POSIX shell-style interface.

We made a playground so you can try it out without signing up: https://riza.io

The API documentation lives here: https://docs.riza.io

There are many limitations at the moment, but we expect to rapidly expand capabilities so that programs can e.g. access the network and filesystem. Our roadmap has more details: https://docs.riza.io/reference/roadmap

If you need to execute LLM-generated code we’d love to have you try the API and let us know if you run into any issues. You can email us directly at founders@riza.io.

sikan_ 2 years ago |

Been using Riza for the past few months at our startup for executing code generated by GPT4.

We use it for local dev, running prompt eval, and running code in prod.

- It was very fast to setup - it took us just a few minutes to execute our first function call.

- Multiple languages support - we use both JS and Python for code generated by LLM , Riza works great with both languages out of the box.

- No cold start - this is important because latency matters in our product.

- No infra management - even if we use AWS lambda or similar serverless product we felt like we still needed to a bunch of setup to make sure its fast + secure.

Congrats on launching!

itunpredictable 2 years ago |

When I was at Retool (Hi Kyle), we wanted to create a way for users to write arbitrary code that got executed against their data in our cloud, e.g. using the MongoDB Node SDK to write Mongo queries in JS instead of only being able to use the pre-defined functions and form fields we had. Engineering researched it for a while, tried out Lambda and a few other things, but we never got there. This would have been sick

stanleydrew 2 years ago | |

We think about the Retool case a lot. User-defined database connectors were an initial inspiration to start building Riza.

datascienced 2 years ago |

How does it compare to “just” using vagrant, docker, firecracker etc.

mdaniel 2 years ago |

I mean, it's "run a subset that is supported by wasi" not "untrusted code"

    Traceback (most recent call last):
      File "/src/code.py", line 3, in <module>
        print(os.listdir('/'))
              ^^^^^^^^^^^^^^^
    FileNotFoundError: [Errno 44] No such file or directory: '/'

OT1H, I do appreciate the sandbox-y nature of run fake code, but OTOH I would think a much less explodey way of shimming out untrusted code would be an in-memory filesystem so things blow up less

I guess put another way: who is the target audience for this?

conroy 2 years ago | |

> I would think a much less explodey way of shimming out untrusted code would be an in-memory filesystem so things blow up less

Filesystem access is the first item on our roadmap (https://docs.riza.io/reference/roadmap). If you want to see it in action, try opening /src/code.py. While adding an in-memory filesystem would be easy, we want to make it usable for reading and writing potentially large files.

> I guess put another way: who is the target audience for this?

Our customers are using our API to run LLM-generated code, build plugin systems, and power customer-defined data transformations.