They do spike on different features like:

    - snapshotting and forking
    - good SSH and VPN access for end-users
    - agent-friendly features, like obscuring secrets at network layer

I've been working on some open-core stuff[1] to coordinate sandboxes, and we're making changes to have a library that lets people coordinate any number of remote or local sandboxes using any provider, kinda like how the Docker CLI works for managing containers, git repos, and coding agents. Flue[2] is another player in this space, and is more of a pure framework, while we're building it as an interactive product for using sandboxed agents and workflows.

[1] https://github.com/gofixpoint/amika/blob/main/ROADMAP.md

[2]: https://flueframework.com/

The startups in this space right now don't provide much value on top of the cloud providers they're wrapping. They don't tend to be run by experienced infra people either so they seem very vibecoded, insecure, janky, etc. They're also significantly overpriced because they're marking up already expensive providers.

Something surprising from my own experience is that while there's certainly a huge role for async agents in cloud sandboxes, async agents running locally seem more useful in many cases.

Part of it might just be that I am old and inflation is catching up with my understanding of prices.

But as far as AWS I still have to say no thanks. Imagine some group actually started using my hosted AI agent service for something compute and network intensive. It could turn into $2000 overnight and if I didn't account for one of the numerous types of AWS charges, I might have only collected $500 for credits purchases.

Or it could easily be ten times that. But who am I kidding. No one is going to use my agents. So it doesn't matter if it's gvisor or Firecracker or whatever.

  > Containers launch in seconds, yet their shared-kernel architecture requires significant custom hardening to safely contain untrusted code

  > you create a MicroVM Image by supplying a Dockerfile and code packaged as a zip artifact in Amazon S3
  > 
  > MicroVMs support up to 8 hours of total runtime

This smells like a competing team building something to capitalize on AI hype, but the product isn't differentiated enough for this to make sense long term. If this was a service called managed AI agents, and you added features specific to AI agents, that has value. But "here's Fargate with a different name" isn't gonna last.

https://engine.build/lab/agent-sandboxes

Will add MicroVMs there today (and any others that are missing if you let me know!)

https://taoofmac.com/space/blog/2026/06/18/1845

https://github.com/rcarmo/pve-microvm

Does this mean you effectively can't use them as long-lived developer environments? It sounds like even if you suspend them, this is the hard limit on the total time it can run.

Apart from the above features.

  1. We support more than 32GB disk (as a detachable device, ideal for agentic memory)

  2. We provide egress control

  3. We provide vault for secret injection (to counter prompt injection)

  4. Snapshot / forking.

  5. long lived sandboxes.

Can be used via - npx skills add instavm/skills

Are you guys literally spinning up agents where a 100 ms boot time vs a 3 seconds boot time makes a difference?

I'm asking because I understand the appeal of micro VMs but every time the subject comes up people talk about "isolating agents": what's wrong about isolating agents in a regular VM (or in a container which, itself, is in a VM)?

FWIW I've got my stuff nicely isolated in regular VMs that are regularly up for hours and hours.

It's like the microVMs boots in 100 ms, then the agent does... What? And exits after another 100ms and now you need to launch another one?

What's the use case of "microVMs to isolate agents"?

Which is more cheaper for me?

Ideally maybe self hosting would be better?