I had the chance to review the technical design, and it’s clear this project takes a thoughtful and well-directed approach.

Rather than relying on the usual trade-off between Firecracker-style microVMs and syscall-level sandboxing like gVisor, ERA takes a different path—leveraging libkrun to deliver “lightweight yet VM-like” isolation without compromising the developer experience. That balance is genuinely impressive.

What stood out to me while exploring the repository:

・Deeper isolation than gVisor—no direct access to the kernel surface

・A clearly safer boundary than containers, without the overhead of Firecracker

・Practical issues with libkrun (buildah, krunvm, case-sensitive volumes) are addressed with care in the README and setup scripts

・Maintains ~200ms microVM startup, making it fast enough to integrate naturally into agent execution loops

・Local-first by design, yet flexible enough to support Cloudflare Workers for orchestration when needed

・Well-crafted recipes and examples that go beyond the basics and support real-world usage

This isn’t just about “running microVMs”—it’s about delivering a tool that developers can actually rely on. It feels far from a proof of concept; it’s something you’d want to keep in your toolbox.

Running AI agents safely on local machines is still an open challenge with no clear standard. In that context, ERA’s approach—seamlessly integrating microVMs into everyday development workflows—is both timely and valuable. I have deep respect for the thoughtful implementation and design philosophy behind it.

This is potentially exactly what I was looking for, thank you for putting it together.

When running a bunch of parallel agents locally, they can step on each other's shoes a bit. The ideal setup is to give them isolated workspaces, have them pull code in, do work, then push code back upstream.

When they do work, they sometimes go off the rails. They'll delete files they don't understand or think are irrelevant, explore other parts of the FS and get confused once their context is contaminated. By giving them a sterile workspace, it allows near risk-free multi-agent operations.

Containers offer most of this, but I was concerned about the security boundaries if it really goes haywire. For example, if I have an agent working at a very low level, it might start messing with the OS in a way that can damage things in a difficult way to reverse. They get confused easily.

Anyway, bookmarked. I will check it out in more detail when I get to that portion of my workflow. Thanks again.

Heck yea, I'm trying to do something similar to manage running bunch of parallel agents locally.

Let me know if you run into any issues

I am a bit confused how I would use this (maybe because I may not be your target audience?).

For example if I am coding with Kilocode and phpstorm. How would I use these microVms and what is the cloudflare worker for? I currently run a regular set of docker containers to run my code, how does this compare?

Co-builder on this project,

To answer your questions :)

- How would I use these microVms and what is the cloudflare worker for?

This is unlikely the right solution for you, it's more geared towards people building kilocode (because they have an agent that independently writes code + executes that code).

The microvm's are for developers running locally wanting to execute untrusted code written by an ai - example is running codex or gemini-cli. Cloudflare workers are for users who want their own "sandbox infra" so they can execute untrusted code written by ai with their production app (not local hopefully)!

- I currently run a regular set of docker containers to run my code, how does this compare?

Very little difference for your use case unless you expect to do more hostile coding.

But I'll try to explain why VM's are different than containers in the security area:

Containers are not considered as production-level security boundary. One of the main reason is because containers share the kernel with the host machine running the container.

Security penetration engineers do not consider exploiting `some` linux kernels to be high effort because depending on the version, libraries, etc there are CVE's to exploit: https://www.cisa.gov/known-exploited-vulnerabilities-catalog...

However, virtual machines are battle tested sandbox tech designed to have strong protection by having host and the VM have individual operating systems AND dedicated virtualized hardware. This is also the main environment you can rent from big providers. Some more info here: https://www.wiz.io/academy/containers-vs-vms

So this product is a microVM which combines security of VM's + a layer to make it easy and fast like containers to get the best of both worlds.

This is pretty cool, I am literally working on a project very similar to this. IMO most of the current agent sandboxes are not great, they're either insufficient for the threat model, too platform dependent or saas only. A microvm I think is the correct answer.

can you include a component diagram overview to give folks a quick idea of "what runs where?" before making the decision to try this out.

you wrote that this is local but what's up with the cloudflare subdir? do we need a cf account to run this?

Will do!

The microvm's are our local solution so devs can use it.

But we thought people might to do some production work to not run local stuff - so we added a compatibility layer with cloudflare :D. Good note, didn't even think about that being kind of confusing.

No CF account needed to run this!

This is great, and greatly needed with advanced LLM-assistant working.

Is there a way to install / run these from node.js / npm as well (not global), instead of installing them to the whole system ?

Would be a bon for IDEs to run code sandboxed locally!

It will be possible to run from a node SDK soonTM!

Here's the work-in-progress here: https://github.com/BinSquare/ERA/tree/main/era-agent/sdk/nod...

I'm not very familiar with node to be fair so it's taking a little longer for me to get that going.

I hate to speak negatively about someone's hard work but I am genuinely confused as to why this needs to be a separate product/service. Could I not spin up a container or a VM and run my agents in it? What is this sandbox letting the agent do safely that neither the current container or VM solutions are able to offer?

Co-builder of proj here:

You absolutely can spin up a container or a vm and run your agents in it - but you make trade offs. Containers are easy and fast. Vm's use more resources but are more secure. Most people in production run containers in vm's to get benefits of both!

This is a product that tries to get the best parts of both containers (devX + speed) and vm's (security). The innovation here is using micro-vm's which are really really lightweight and fast to start compared to traditional vm's. Props to libkrun team for creating that: https://github.com/containers/libkrun

Alright, but why couldn't I use `krunvm` directly then? What does your wrapper provide that I can't easily do already? Is it essentially a set of "recipes" and "skills"?

Krunvm has some breaking issues that I'm trying to upstream fixes to: https://github.com/containers/krunvm/pull/74. Amazing project and maintainer btw.

This product is effectively wrapper that has some fixes + devX glue that makes the experience hopefully faster. I try to improve the cleanup, logging, resources monitoring as an example: https://github.com/BinSquare/ERA/blob/main/era-agent/vm_serv...

The recipes and skills stuff is pretty experimental, we're trying to see if we can make this a full environment where agents can just have all the tools they need to build along with full privilege (sudo) because it's inside a microvm!

That's fair. Thanks for your work!

I don't think I'll use your project, but it's great that you're thinking about these things. We need more security initiatives in the "AI" space.

Just poked through the code, and I’ll add to the other answers given from an outsiders perspective.

What I find interesting: I’m running all kinds of agents (for good or bad, make fun of me if you like): not just coding agent products, but “hand rolled” as well, and they all have features which require some filesystem or environment state (tools, skills, instructions etc). They are each subtly different in those requirements, but some patterns are emerging and it seems to me that OP is seeing this as well - and noting that this aligns with the Agent Sandbox domain which is not “solved” yet. Consider that a Dockerfile sets up an environment for the code you want to deploy, which is better than the shell script you use on your local - it’s becoming more apparent to me that there’s a similar need here, which isn’t satisfied by the abstractions we already have, and lots of folks are poking around these domains to find something that fits.

What exactly is a microVM?

A lightweight VM.

See these posts: https://firecracker-microvm.github.io https://www.koyeb.com/blog/what-is-a-microvm

A rumor that gets started when you cheat on your girlfriendVM.