I currently use lightweight VMs (Proxmox containers) and git worktrees. I can fork an existing VM in in seconds. It is not entirely clear to me what I would gain from using your solution.
Launch HN: Freestyle – Sandboxes for Coding Agents
91–100 of 182 posts
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#92Nice 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…
Thanks for sharing your approach!
> It is nothing special. We keep X number of machines in a warm pool.
I'd love to better understand the unit economics here. Specifically, whether cost is a meaningful factor.
The reason I ask is that many startups we've seen focus heavily on optimizing their technology to reduce cold/boot startup times. As you pointed out, perceived latency can also be improved by maintaining a warm pool of VMs.
Given that, I'm trying to determine whether it's more effective to invest in deeper technical optimizations, or to address the cold start problem by keeping a warm pool.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#93Earlier quoted context omitted.
Yep I can see this especially when the agent is spinning up test servers/smokes and you don't want those conflicting. How do we reconcile all the potential different git hashes though, upstream I guess etc (this might be an easy answer and I'm not super proficient with git so forgive)
So we recommend branch per fork, merge what you like. You have to change the branch on each fork individually currently and thats unlikely to change in the short term due to the complexity of git internals, but its not that hard to do yourself `git checkout -b fork-{whateverDiscriminator}`
Have you considered git worktree?
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#94I currently use lightweight VMs (Proxmox containers) and git worktrees. I can fork an existing VM in in seconds. It is not entirely clear to me what I would gain from using your solution.
Proxmox forking in a few seconds is a miracle!
These are likely only a better value for you at large scale/if you start wanting to run hundreds.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#95Non open source and non local SAAS sandboxes are offensive to even try to launch. No one needs this and the only customers will be vibe coders who just don't know any better. There are teams building actual sandboxes like smolmachines, podman, colima and mre. At least be honest and put the virtualisation tech you are using as well as that its closed source SAAS on the landing page to safe people time.
> Non open source and non local SAAS sandboxes are offensive to even try to launch. No one needs this and the only customers will be vibe coders who just don't know any better.
This is simply not true, but also not a very charitable take.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#96Earlier quoted context omitted.
So we recommend branch per fork, merge what you like. You have to change the branch on each fork individually currently and thats unlikely to change in the short term due to the complexity of git internals, but its not that hard to do yourself `git checkout -b fork-{whateverDiscriminator}`
Have you considered git worktree?
Great for simple things, but git worktrees don't work when you have to fork processes like postgres/complex apps.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#97Congrats 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.
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).
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#98Earlier quoted context omitted.
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 w…
So thats what we did. We've made forking a whole gas town performant in 100s of milliseconds. Try it — you can definitely see it working on free tier.
In respect to large and powerful RAM + Size is important but I was more-so referring to full Linux power. The ability to run nested virtualization, ebpf, fuse, and the powerful features of a normal Linux machine instead of a container.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#99Earlier quoted context omitted.
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.
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.
Re: Launch HN: Freestyle – Sandboxes for Coding Agents
#100Earlier quoted context omitted.
> 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 w…
So thats what we did. We've made forking a whole gas town performant in 100s of milliseconds. Try it — you can definitely see it working on free tier. In respect to large and powerful RAM + Size is important but I was more-so referring to full Linux power. The ability to run nested virtualization, ebpf, fuse, and the powerful features of a normal Linux machine instead of a container.
Well that does sound pretty impressive then. And as a champion of open source it wouldn't make me feel like I was getting locked in because the regular speeds I could live with (on a server with KVM or a nested virtalization setup).