Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Freestyle – Sandboxes for Coding Agents

freestyle.sh

Post reply on HN
Print view View original

101–110 of 182 posts

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#102

Post by sabedevops »

benswerd wrote: post #31
stocktech wrote: post #28

I built something like this at work using plain Docker images. Can you help me understand your value prop a little better? The memory forking seems like a cool technical achievement, but I don't understand how it benefits me as a user. If I'm delegating the whole thing to the AI anyway, I care more about deterministic builds so that the AI can tackle the problem.

So first MicroVM != Container, and container is not a secure isolation system. I would not run untrusted containers on your nodes without extra hardening. The memory forking was originally invented because for AI App Builders and first response driven applications its extremely important that they are instant (difference between running bun dev and the dev server already being running). However its much more generall…

What does this protect you from that you’re exposed to by running a well-crafted rootless container on a system with SELinux or similar?

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#103

Post by ianberdin »

benswerd wrote: post #99
ianberdin wrote: post #97

Earlier quoted context omitted.

Insane. Does it possible to fork to another bare metal machine? Maybe multi region as fly io. If not, I bet you have huge disk sizes on your machines to store all the snapshots (you said, you store them and bill only for disk space).

So forking across multiple nodes in that speed is not possible — we run extremely beefy nodes in order to avoid moving VMs across nodes as much as possible. We are researching systems of hot moving VMs across VMs but it would have very different performance characteristics.

Yeah, I see. Is it possible to get a corrupted state? Let’s say we had realtime database actively writing at that moment?

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#104

Post by benswerd »

sabedevops wrote: post #102
benswerd wrote: post #31

Earlier quoted context omitted.

So first MicroVM != Container, and container is not a secure isolation system. I would not run untrusted containers on your nodes without extra hardening. The memory forking was originally invented because for AI App Builders and first response driven applications its extremely important that they are instant (difference between running bun dev and the dev server already being running). However its much more generall…

What does this protect you from that you’re exposed to by running a well-crafted rootless container on a system with SELinux or similar?

Generally kernel level attacks and neighbor performance impacts on the security side.

On the functional side without a kernel per guest you can't allow kernel access for stuff like eBPF, networking, nested virtualization and lots of important features.

Here is a good blog from docker explaining how even the best container is not as safe as a MicroVM https://www.docker.com/blog/containers-are-not-vms/

theoretically you can get to fairly complete security via containers + a gVisor setup but at the expense of a ton of syscall performance and disabling lots of features (which is a 100% valid approach for many usecases).

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#105

Post by benswerd »

ianberdin wrote: post #103
benswerd wrote: post #99

Earlier quoted context omitted.

So forking across multiple nodes in that speed is not possible — we run extremely beefy nodes in order to avoid moving VMs across nodes as much as possible. We are researching systems of hot moving VMs across VMs but it would have very different performance characteristics.

Yeah, I see. Is it possible to get a corrupted state? Let’s say we had realtime database actively writing at that moment?

It is impossible.

Our tech is not decades old so there is a chance we've missed something but our layer management is atomic so I'd be shocked if you'd be able to corrupt state across forks/snapshots.

Post reply on HN