Yet Another Sandbox Company

You may have noticed a couple of things in the last few months. One, I started a company that sells sandboxes. Two, that there are a bunch of new companies selling sandboxes. So why did I start yet another sandbox co?

Well, let's step back for a minute. What's a sandbox and what does it provide? A sandbox is just an isolation mechanism for things you don't trust, it gives you a place to run code written by LLMs or customers or install things safely. How the isolation is created matters and there's a whole bunch of ways to do it - file system isolation, cgroups, namespacing, virtual machines, etc. The strictest form of isolation is going to come from a virtual machine, of which there's a lot of options as well.

In the world of agents, most apps use a coding agent under the hood - the agent is generally tuned for its specific task and market but its still writing code and scripts and then invoking them most of the time. Naturally, we want some isolation for that agent to protect us and prevent issues from the agent spilling over and affecting other customers (noisy neighbor problems). There are sandbox companies solving for this problem specifically (actually most of them are dialed into this problem). The core thing these companies will publish is an SDK for other developers to integrate into their apps. The most common isolation technique in this space is a virtual machine monitor called Firecracker which makes use of Linux's KVM (kernel virtual machine) to spin up tiny stripped down VMs. KVM itself is really wonderful technology and is now about 20 years old and is quite well understood by now.

I first started messing about with Firecracker several years ago at Flatfile. We had a fleet of compute for asynchronous workers that would grab jobs off of a queue. We were running the workers as containers in Kubernetes and because autoscaling just isn't instantaneous, we were generally always running a bit overprovisioned so that some core services wouldn't get bogged down waiting for capacity to come online. Originally, we were just seeking to offload the jobs into AWS lambdas but controlling the invocations became complex (something has to tell the lambda to wake up and check the queue), we couldn't just shove the service into the lambda cleanly, and the developer experience left a lot to be desired. I experimented with building custom root filesystems for Firecracker to solve some of the issues but there wasn't an off the shelf control plane at the time to do manage at scale across multiple machines so I packed the project up and put it on the shelf.

The agentic era made me grab it back off the shelf but alas, no real control planes still. More than that however, the more side projects I bootstrapped with coding agents the more I wanted extra features that don't come out of the box with firecracker: I wanted stateful VMs, I wanted to plug multiple agents into the VM, I wanted to use the VM locally and not in someone else's cloud, I wanted to share the VM (more accurately I wanted to share what I built inside of it), I wanted to ship it to the internet and expose a service. I wanted to manage many VMs across multiple machines. I wanted VMs on my Mac and my Linux box; I wanted to run a service in a VM on my linux box and hit it from my Mac.

I wanted a lot.

Personally, I don't think the hard part about what we're doing is the VM. We're putting a wrapper around 20 year old linux tech after all. Making VMs behave like containers in agentic apps is challenging, and there's value in that (indeed, try heyvm --api to run it as a REST API for building with). I think however, that if we were to stop there we would be leaving a lot on the table. I tend to think about agentic development as centering on the sandbox - it's your isolation but its also where all of your artifacts live. It's almost like a folder on your hard drive - create a folder for a new project and stuff everything about that project into it. The sandbox has the potential to be the folder for AI, except instead of just a container it can also power the thing you're building. Now, for that to truly be valuable, it also needs to be fairly portable. There's a reason that file sharing apps were all the rage during the cloud boom - most things we work on or create aren't done in a vacuum, they have a purpose and they have people that they are prepared for. So what if the sandbox we're using for AI assisted work can additionally be the folder, the compute, and access layer all at the same time? That's the reason I started another sandbox company, and its the reason that Heyo Computer looks a lot different from our peers (several of whom are doing awesome stuff and I'd love to support as backends in heyvm). When the sandbox becomes a first class citizen we unlock a lot of potential (we also unlock a lot of hard problems but those will be follow up posts).

PS - if you haven't already, head to https://heyo.computer and sign up for the mailing list to track our progress.