alt Hacker NewsMicroVMs: Run isolated sandboxes with full lifecycle control
Comments
The holy grail microVM for me is one that can properly share a GPU across VMs, similar to what you can do with containers.
Shout out to https://smolmachines.com/ for supporting Vulkan over virtio-gpu/Venus. Currently the best implementation I'm aware of. Unfortunately my use case is running a full desktop inside the VM, and streaming it out over something like Sunshine/Moonlight. For this you need GPU rendering and video encoding. Venus rendering works, but you have to pass the frames back and forth between the host and the guest multiple times which is inefficient. Also Venus doesn't support video encode as far as I can tell.
It's about time AWS got into the agent sandbox game.
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.
What's the best provider to self-host Firecracker? I feel that AWS is not a safe or cost-effective option for a self-funded startup or small business. Although is anything cost effective anymore? Hetzner just had a massive price hike.
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.
We have this page which compares a whole bunch of sandbox providers in different categories
https://engine.build/lab/agent-sandboxes
Will add MicroVMs there today (and any others that are missing if you let me know!)
For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand.
This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.
what is the trend right now on mac to run microvm? I am using OrbStack.. is anything micro than this?
Shouldn’t the title be “AWS Lambda MicroVMs”? MicroVMs are an existing concept.
From last week: MicroVMs in Proxmox
I’ve been working with AgentCore that uses the same MicroVMs. They are capable in many ways but for coding agents that load a big got repo they get bloated quickly with the git repo.
I’m building this google3 style mounting to address this.
https://github.com/mohsen1/git-lazy-mount
Still work in progress but for now I am seeing promising results
> 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.
I am wondering what type of workload this is for.
They give a tiny example and insist on micro, fast start, but the say it lasts up to 8 hours and is up to 16 vCPU.
What sort of app require faster boot (than lambda or ec2), but only for a limited interval, and with possibly plenty of processing power...
Maybe I am not the right target, but if you have examples so that I can better appreciate, I'd love that
> MicroVMs support up to 8 hours of total runtime
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.
Not informational but I kept reading that as 'MicroVMS' which would be a scaled down version of the DEC VMS operating system?!? And I was trying to figure out if they had added containers or something to it.
Added support for configuring and running these directly from beamshell (.com). Really cool being able to spin these and use them any mcp client.
beamshell microvm deploy && beamshell microvm run
Interesting, I have recently started working on a project which is similar and fully open source, maybe interesting to some here. Happy to receive any kind of feedback on it.
No one talks about new Railway Sandboxes - https://docs.railway.com/sandboxes
I think they have one of the best sandbox environments on the market with pay per utilized resources pricing, it's a huge cost reduction for agentic workloads when you have 95%+ idle CPU time and occasional spikes for CPU heavy work (e.g. agent run tests or something like this).
I use railway to host my openclaw like personal agent for friends and family (9 instances) and it costs like 1-2$/mo with scale to zero.
Does anyone understand the pricing? The pricing page says “Lambda MicroVMs are priced per instance-second” but MicroVM’s aren’t otherwise mentioned.
This seems roughly similar to Google's Cloud Run gen2 instance types. My understanding is with the second generation, they are running microvms which are bootstrapped from a container image.
I don’t get it we are paying at least hundreds or maybe thousands per month on ai costs. Just get a regular vm ?
What's the point of microVMs for running agents?
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"?
What does the actual startup latency look like? Does it depend on the size of the resulting image?
How does this compare to Fly.io
Which is more cheaper for me?
Ideally maybe self hosting would be better?
[dead]
[dead]
Not so subtle plug for another sandbox provider, https://instavm.io :
Apart from the above features.
1. We support more than 32GB disk (as a shareable 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
There are sooooo many sandbox providers out there.
They do spike on different features like:
Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolated environments for your own work.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/