Live data from Hacker News

Launch HN: Freestyle – Sandboxes for Coding Agents

freestyle.sh

41–50 of 182 posts

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#41
post #9

Earlier quoted context omitted.

Fly.io sprites is the most similar to us of the bunch. They do hardware virtualization as well, have comparable start times and are full Linux. What we call snapshots they call checkpoints. The big pros of Sprites over us is their advanced networking stack and the Fly.io ecosystem. The big cons are that Sprites are incredibly bare bones — they don't have any templating utilities. I've also heard that Sprites sometime…

Thanks for the thoughtful response. I'm predominantly a self-hoster, but I think your product makes a lot of sense for a wide variety of users and businesses. I'm excited to try out freestyle!

I've been building an open-source, self-hostable Firecracker orchestrator for the past month: https://github.com/sahil-shubham/bhatti (https://bhatti.sh)

Still WIP, but the core works — three rootfs tiers (minimal Ubuntu, headless Chromium with CDP, Docker-in-VM), OCI image support (pull any Docker image), automatic thermal management (idle VMs pause then snapshot to disk, wake transparently on next API call), per-user bridge networking with L2 isolation, named checkpoints, persistent volumes, and preview URLs with auto-wake.

Fair warning: the website is too technical and the docs are mostly AI-generated, both being actively reworked. But I've been running it daily on a Hetzner server for my AI agents' browser automation, and deploy previews.

I'd love any feedback if you want to go ahead and try it yourself

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#42
post #36

Earlier quoted context omitted.

Agreed, the thing I'd be most interested in is the isolated execution environment you mentioned. Agents running autopilot are powerful. Agents running unsupervised on a machine with developer permissions and certificates where anything could influence the agent to act on an attacker's behalf is terrifying

I recommend running the agent harness outside of the computer. The mental model I like to use is the computer is a tool the agent is using, and anything in the computer is untrusted.

I would recommend not giving an agent the full run of any computing environment. Do handle fine grained internet access controls and credential injection like OpenShell does?

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#44
post #36

Earlier quoted context omitted.

Agreed, the thing I'd be most interested in is the isolated execution environment you mentioned. Agents running autopilot are powerful. Agents running unsupervised on a machine with developer permissions and certificates where anything could influence the agent to act on an attacker's behalf is terrifying

I recommend running the agent harness outside of the computer. The mental model I like to use is the computer is a tool the agent is using, and anything in the computer is untrusted.

The problem is the agent, which should be treated untrusted. The computer isn’t the problem

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#45
This is awesome - the snapshotting especially is critical for long running agents. Since we run agents in a durable execution harness (similar to Temporal / DBOS) we needed a sandboxing approach that would snapshot the state after every execution in order to be able to restore and replay on any failure.

We ended up creating localsandbox [0] with that in mind by using AgentFS for filesystem snapshotting, but our solution is meant for a different use case than Freestyle - simpler FS + code execution for agents all done locally. Since we're not running a full OS it's much less capable but also simpler for lots of use cases where we want the agent execution to happen locally.

The ability to fork is really interesting - the main use case I could imagine is for conversations that the user forks or parallel sub-agents. Have you seen other use cases?

[0] https://github.com/coplane/localsandbox

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#47

Earlier quoted context omitted.

I recommend running the agent harness outside of the computer. The mental model I like to use is the computer is a tool the agent is using, and anything in the computer is untrusted.

I would recommend not giving an agent the full run of any computing environment. Do handle fine grained internet access controls and credential injection like OpenShell does?

I used to believe this, but I think the next generation of agents is much more autonomous and just needs a computer.

The work of a developer is open ended, so we use a computer for it. We don't try to box developers into small granular screwdrivers for each small thing.

Thats whats coming to all agents, they might want to run some analysis with python, want to generate a website/document in typescript, and might want to store data in markdown files or in MongoDB. I expect them to get much more autonomous and with that to end up just needing computers like us.

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#49
post #45

This is awesome - the snapshotting especially is critical for long running agents. Since we run agents in a durable execution harness (similar to Temporal / DBOS) we needed a sandboxing approach that would snapshot the state after every execution in order to be able to restore and replay on any failure. We ended up creating localsandbox [0] with that in mind by using AgentFS for filesystem snapshotting, but our solut…

Deterministic testing of edge cases. It can be really hard to recreate weird edge cases of running services, but if you can create them we can snapshot them exactly as they are.

Re: Launch HN: Freestyle – Sandboxes for Coding Agents

#50
post #44

Earlier quoted context omitted.

I recommend running the agent harness outside of the computer. The mental model I like to use is the computer is a tool the agent is using, and anything in the computer is untrusted.

The problem is the agent, which should be treated untrusted. The computer isn’t the problem

Kind of. The chat logs of the agent are trustworthly, as should any telemetry you have on it or coming out of the VM. Its behavior should be treated as probabilistic and therefore untrustworthly.
Post reply on HN