How we run untrusted code in Langfuse (OSS) and why we picked lambda

langfuse.com

4 points·marcklingen··3 comments

Interesting approach. The Lambda cold-start tradeoff is real but for untrusted code isolation it is hard to beat the security boundary. One parallel: DMARC enforcement works similarly - it is a hard boundary at the DNS level rather than trying to inspect and filter, which tends to be more reliable than heuristic approaches.

I haven't read the whole article but what are your thoughts on using the recent AWS Lambda Microvm's which are stateful for sometime. I imagine that lambda might give some issues

> We deliberately traded features for properties we could verify: no egress, no dependencies, no credentials in v1. In exchange we got tenant isolation we didn't have to build and a runner whose stolen credentials open nothing. Most importantly, we got the feature into real users' hands quickly - and the feedback flowing.

This line and the no X, no Y, no Z sounds a bit too LLM-isy. Could you please answer if article was in any capacity generated with the use of LLMs?

> but what are your thoughts on using the recent AWS Lambda Microvm's which are stateful for sometime.

I think they are great for agent sandboxing. In our case we don't have the need for it as it's really fast, stateless executions. The tenant isolation feature (which is also fairly) new was a killer feature for us though!

> This line and the no X, no Y, no Z sounds a bit too LLM-isy. Could you please answer if article was in any capacity generated with the use of LLMs?

I actually handwrote and then used an LLM to polish. I wanted to make a point though: we very deliberately excluded certain features for now so that we can add them iteratively - thinking about one thing at a time. I don't think this approach is a given in todays world - some people would probably just do things because they can.

Reply on news.ycombinator.com