“microvms” are real vms but the hypervisor and vm (guest kernel) shed most of the hardware / device emulation, support, and discovery which makes traditional VMs look / feel like real computers, as well as most guest interactions. This gives them extremely low overhead.

Firecracker is designed to start a VM in under 125ms and 5MB. Netbsd advertises that you can direct-boot a MICROVM kernel configuration in under 10ms.

If an agent fires up NPM, takes a boatload of memory, is that memory released back to the OS after NPM shuts down in the VM?

In principle yes, in practice it's complicated, using something called "balloon drivers"

https://en.wikipedia.org/wiki/Memory_ballooning

There’s also memory hotplugging via virtio-mem. But generally speaking downscaling live vm memory can’t be said to be a solved problem, it’s more of an active area of research.

> If an agent fires up NPM... :D :D

I think this is one of the big issues with today's MCP servers. Most are based on Node.js and take a lot more memory than they should, compared to the complexity that the job requires. Just run a few MCP servers locally, and all your RAM is gone...

An Ubuntu Server VM, like the ones started by Incus, use at least 512 MB of RAM per instance. If you spawn 10 sandbox VMs, you already pay 5 GB RAM just to sit there idle. You also pay a CPU cost, you have 10 kernels managing stuff, but arguably it doesn't matter that much given CPU core counts.

I use something in between - a single Ubuntu VM, into which I spawn multiple Incus LXC containers for the agents. The containers only use 50 MB or so per instance (separate systemd, ...). This way I pay the VM RAM tax only once, and the agents are still contained inside the VM if they manage to escape the LXC containers.

Yeah this basically. I differentiate between "containers I wrote" (where I packaged the app/wrote the OCI "Dockerfile" / container file) and "containers from other people": all those I wrote (for our own use) go into one VM, while all the other containers go into another VM. Then I've got a third VM for containers for the AI agents.

This way I don't pay tens of VMs "tax" but basically only three (plus one or two VMs I use for testing enhancements to my VMs provisioning / optimization / securing setup, when I work on that).

I don't use LXC (I could) but regular containers, inside VMs.

I'll look into the stripped down "micro" VMs but then I don't spend my days launching VMs/shutting them down so it's not a big deal.

This is what I do. Nice benefit is it lets me passthrough my GPU and share it between multiple containers. Incus is awesome.

There are many devs that have little to no experience of Linux, like the hundreds of thousands of .Net and Java CRUD devs in enterprise companies using Windows.

There is a need for a Docker desktop like GUI for this market.

Java CRUD devs have been getting into Linux a lot more in recent years since learning more about how DevOps does their work is important and integrated in with our projects, like the Dockerfile, Helm files, etc. I was already into Linux before Java was even released. I'd say even .Net devs are too since .Net Core is becoming more important in their world.

When I was a teen I had no experience with software development. Then I went to school and learned about it. Now I'm making money doing this thing because I became quite good.

The world didn't fit around me, so I made "me" fit around "the world". I bet those stubborn dinosaurs can learn a new trick or two also, if management lets them do it during working ours...

Huh? https://docs.docker.com/desktop/setup/install/windows-instal...

Also, WSL (Windows Subsystem for Linux) has been baked into Windows for a long time and makes it very easy to play with Linux, as does using the Hyper-V VM system. Any developer unfamiliar with Linux because they use Windows, has little excuse.

Agreed, even game devs that ignore Linux as target for their AAA games, actually tend to use Linux for game servers, the age of IIS with .NET/ISAPI is long gone, except for legacy code stuck in .NET Framework.

Modern .NET did not went cross platform by accident, and Java development has always been "develop on Windows deploy on UNIX", in corporations where Mac tends to have little presence.

docker's sandboxes are cli only atm

It’s real VMs, firecracker style.

Haven't used docker sandbox but you can't just `apt install postgres` on firecracker, it needs to get baked into the image first.

That's my experience anyway, there's a lot of restrictions once you need to do some real basic things. For basic prompts maybe but interacting with a full stack ehh.

So bit hesitant to call firecracker a real VM myself.

Your example is not complete, you have to show how it will run claude/codex, you have to do extra things to install run and mount folders there, this one does that with less config, also with this agents can run docker, lxd doesn't allow you to do that

You create your own image first rather than blank ubuntu.

Packer and Incus setup:

  packer {
    required_plugins {
      incus = { version = ">= 1.0.0", source = "github.com/lxc/incus" }
    }
  }

  source "incus" "ubuntu" {
    image        = "images:ubuntu/24.04"
    output_image = "ubuntu-claude"
    type         = "virtual-machine"
  }

  build {
    sources = ["source.incus.ubuntu"]

    provisioner "shell" {
      inline = [
        "curl -fsSL https://claude.ai/install.sh | bash",
        "echo 'export PATH=\"$HOME/.local/bin:$PATH\"' >> ~/.bashrc"
      ]
    }
  }

Then:

  packer init ubuntu-claude.hcl
  packer build ubuntu-claude.hcl
  incus launch ubuntu-claude my-claude-vm
  incus exec my-claude-vm -- claude -p "solve the EC discrete logarithm problem, if it doesn't work keep going" --dangerously-skip-permissions

The reality of these things are that eventually you will want to do something useful or different with them and the flexibility simply isn't there compared to a real vm, if you desperately need boot times then there's plenty of other options here, especially with packer. Some of my prompts are often hitting 60+ minutes so it's not really something I think about.

That's a full VM. Microvms are much smaller and they start up very very fast. In miliseconds.