Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > 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.
by mdeeks - lambdas are ephemeral on compute, but couldn't you connect up EFS for your long lived data?
then when you launch the next one, its like you are still there?
by 8note - I'm assuming you can launch them again after 8 hours.by lab14
- You can use them for dev environments.
You just have to finish development in 8 hours.
by amw-zero - Firecracker doesn't reclaim RAM well, so they put this limit in to make sure you don't suffer from the eventual memory bloat problems.by fizx
- In theory, you could set up a process to move data/filesystem between sessions into and out of s3.by alFReD-NSH
- They are long-lived if you're a mayfly.
But I think the point is that they should be cheap to set up, and because of the short life, never really contain anything except the potential to compute when needed, not important data.
by mmastrac - It just a time limit of the life of a single MicroVM.
Using this for a long lived "developer environment" would be extraordinarily expensive anyhow. Scaling the vCPU + RAM cost of these to the same shape compute optimized Graviton On-Demand EC2 instance (16 vCPU x 32 GB RAM) shows about 4x the cost.
So don't do that. Just use an EC2 instance.
by topspin - Shouldn’t the title be “AWS Lambda MicroVMs”? MicroVMs are an existing concept.by fcarraldo
- Yeah, I'm surprised Justin posted this like it was new(s). Wasn't it doing the rounds on the 22nd when it launched?by alexellisuk
- 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"?
- in so many cases, docker is more than sufficient for major agent workloads... with no hostile users of course
- This is for people who want both faster execution, and better security isolation for agents/subagents. It is a different use case than yoursby 0xbadcafebee
- Microvms are better for the VM provider. They use less memory and have a smaller attack surface. Also starting in 100ms means you don't need to add a bunch of async machinery when launching the vms.by vmg12
- I imagine you can have a situation where you let an agent run in a shared env but to access certain tools you spin up a VM just for the tool call duration and then shut it down again. Let’s say you wanna allow the agent to write and run code then you need it to run it somewhere safe
- I dont get it either - I was going to ask the same question but found this.
We have been doing the exact opposite - instead of micro VM's we are giving agents larger VMs.
Previously we were giving them 1GB RAM VM's - now we have upped to 4 GB RAM VM's. When the agent is working - the real cost is in the inference. There is no reason to keep the agent waiting because your VM is too damn slow. So we moved to larger and faster VMs.
The agent might install a package, or run a script - and now it moves along just faster. Not to mention that if the agent is installing a 'fat' SDK, like maybe android sdk, a thicker RAM just moves along everything smoothly without breakages. The incremental amount we pay for the bigger VM is more than justified by the increase in agent performance.
And all the tooling that has already been built up for standard human operated VM's just works pretty well out of the box. We are able to spin up VM's pretty much on demand and purge them clean once the work is done.
We are moving to 8 GB RAMs/4CPUs sometime this year, and GPU's hopefully sometime next.
by sonink - 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.
by apitman - The problem is that this feature is generally restricted to enterprise customers because VDI systems are such a profitable market. NVIDIA and AMD both only offer this on enterprise cards, and Intel has been very wishy-washy on support in their cards.
If you're looking for a thing to google, look up SR-IOV support on (consumer) GPUs.
Also if you're wondering who the customers of these things tend to be, it's generally the CAD market, law firms, etc. If no one's laptop contains sensitive data and can only stream the desktop of a remote system, the loss or theft of an employee's computer isn't nearly the same kind of a security worry.
by Teknoman117 - 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!)
by alasano - Do you mind adding https://isorun.ai? We just launched last week. Founder here (Staff SRE with 20 years in Linux, fastest and cheapest SaaS agentic runtime running on heavily modified Firecracker)by emirb
- Would love to see sandboxd added — it's the self-hosted open-source option with Docker hardening, built-in coding agents (Claude Code, OpenCode), and live preview URLs. https://github.com/tastyeffectco/sandboxd
- From last week: MicroVMs in Proxmoxby haunter
- 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.
by ilaksh - For self-hosting, have a look at what we're building with SlicerVM.com (disclosure: I'm the founder). Also runs just as well on Apple Silicon.
We run quite a few Slicer instances on mini PCs and Ryzen builds - also on Hetzner (and yes ouch 120 EUR / mo up to ~ 550 EUR / mo for 16core / 128GB RAM feels almost unfair)
by alexellisuk - Not Firecracker, but Incus's system containers seem like a good middle ground between Docker and VMs.
https://linuxcontainers.org/incus/docs/main/explanation/cont...
by crabmusket - Cloudflare is cost effective for certain types of workloads, I've heard of businesses getting surprisingly far on the $5/mo worker plan.by CuriouslyC
- I just went with qemu and run it in my own machine. It is portable so you run it on other OSes which is handy when everything is under the same desktop app. But I was after better isolation and the ability to be fully in control of the agent environment to pair with local llms. As soon as you lift it to some managed environment it becomes hard to justify all of the necessary steps to manage connections, encryption etc., eg passing credentials for access to other resources.by sublimefire
- Hetzner is still cheap compared to AWS.by vidarh
- Why do you want to self-host vs. using one of the many providers out there?
Daytona, E2B, OpenComputer, Freestyle, Blaxel, Vercel, Modal, Cloudflare, Tensorlake, Superserve, etc. etc.
Some of them work by pre-purchasing credits, so you can control the blast radius of spend.
Also, if you want a more embedded sandbox runtime as a library instead of a daemon + REST API, you can check out libkrun (and friendly layers on top of it like https://microsandbox.dev/ and https://smolmachines.com/)
by dbmikus - The simplest worthwhile DIY sandbox you can have is to layer two tools: bwrap and gvisor.
bwrap will set up the environment and then gvisor elevates it into a true sandbox.bwrap args -- gvisor args do args -- /path/sandboxee argsStandalone gvisor (not the 'do' subcommand) used to be a mess with the OCI json requirement, but recently they began work on presenting their own bwrap interface (likely to pursue AI agent uses) though I wouldn't use it myself yet.
People often look down on gvisor because they think it's some kind of syscall filter, it is not. It can use one of ptrace, seccomp or even KVM to intercept ALL syscalls and service them with it's own logic (which is in Go). Basically it's a VMM and kernel in one.
by coppsilgold