how does this differ from daytona or e2b?
Also modal.com, I saw a few more as well.
Launch HN: Freestyle – Sandboxes for Coding Agents
81–90 of 182 posts
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#82The problem with agents is that it is currently way too expensive. 100 times more expensive maybe. Another big issue is the lack of interactivity with an agent. Therefor for now agentic development is only viable from your own machine. And there isolation is less of an issue easier to manage.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#83Is it possible to run a Kubernetes cluster inside one? (E.g. via KIND.) If so, we'd very much like to test this. We make extensive use of Claude Code web but it can't effectively test our product inside the sandbox without running a K8s cluster
Yes! You can def run something like K3s in these VMs.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#84Nice work.
However, 50 concurrent VMs is not a lot. Similar limits exists on all cloud providers, except perhaps in AWS where the cost is prohibitive and it is slow.
Earlier this year, we ended up rolling out own. It is nothing special. We keep X number of machines in a warm pool. Everything is backed by a cluster of firecracker vms. There is no boot time that we care about. Every new sandbox gets vm instantaneously as long as the pool is healthy.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#85Congrats guys!
Would share some technical details, I bet you have great stories to tell.
Let’s, what is forking? You completely copy disk, make ram snapshot and run it? If CoW, but ram? You mentioned 8GB ram vms. Sounds like impossible to copy 8Gb under 500ms, also disk?
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#86Congrats guys! Would share some technical details, I bet you have great stories to tell. Let’s, what is forking? You completely copy disk, make ram snapshot and run it? If CoW, but ram? You mentioned 8GB ram vms. Sounds like impossible to copy 8Gb under 500ms, also disk?
So fork time is actually O(1) with VM size, its 500ms even for 64gb + disk. We're using some pretty weird COW techniques to pull it off.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#87Nice work. However, 50 concurrent VMs is not a lot. Similar limits exists on all cloud providers, except perhaps in AWS where the cost is prohibitive and it is slow. Earlier this year, we ended up rolling out own. It is nothing special. We keep X number of machines in a warm pool. Everything is backed by a cluster of firecracker vms. There is no boot time that we care about. Every new sandbox gets vm instantaneously…
50 is not heavy, what is heavy is 1000 VMs that can be paused/brought back 50 in 1 second.
Though generally ya, handrolling this stuff can work at the scale of 50 VMs, it becomes a lot harder once you hit hundreds/thousands.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#88Earlier quoted context omitted.
yep you can choose ram + disk + cpu size
? You say 'yes' but you seem to be answering a different question. Docker desktop only makes me choose a max ram - it dynamically scales RAM usage. I don't need fully automatic like that, but the ability to vertically scale RAM for an existing instance is really important, particularly given the cost of RAM these days.
Ah we cannot do this without a restart. Hot pluggable ram is something I'm interested in but is currently a backburner feature.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#89how does this differ from daytona or e2b?
Generally compared to those two more powerful. Freestyle VMs are full Debian machines, with support for sysd, docker in docker, multiple users, hardware virtualization etc. Daytona and E2B are both great "sandbox" providers but don't really feel like VMs/you can't run everything you can in an EC2.
We also support the forking/snapshotting/long running jobs that they struggle to.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#90It's hard to tell what this is or how it compares to other things that are out there, but what I latched onto is this: > Freestyle is the only sandbox provider with built-in multi-tenant git hosting — create thousands of repos via API and pair them directly with sandboxes for seamless code management. On top of that, Freestyle VMs are full Linux virtual machines with nested virtualization, systemd, and a complete net…
So the snapshotting tech is actually 100% independent of Git. Git is useful for branching vs forking (IE you can't merge two VM forks back together), but all the tech I showed in the Loom exists independently from Git. The hard part of it was making the VM large and powerful while making snapshotting/forking instant, which required a lot of custom VMM work.
> The hard part of it was making the VM large and powerful while making snapshotting/forking instant, which required a lot of custom VMM work.
I don't find "large and powerful" in reference to a VM to sound compelling. What should be large? The memory? The root disk? As I alluded to in my comment, I'm more curious about what can be made small.
Also I'm skeptical that if I forked a vm running a busy Gas Town that it would be very light or fast in how it forks. A well behaved sqlite I could see, but then I'd wonder why not just fork the storage volume containing the database...