Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding Agent VMs on NixOS with Microvm.nix

michael.stapelberg.ch

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Coding Agent VMs on NixOS with Microvm.nix

#41

Post by indigodaddy »

phrotoma wrote: post #21
NJL3000 wrote: post #16

A pair of containers felt a bit cheaper than a VM: https://github.com/5L-Labs/amp_in_a_box I was going to add Gemini / OpenCode Kilo next. There is some upfront cost to define what endpoints to map inside, but it definitely adds a veneer of preventing the crazy…

One problem with using containers as an isolation environment for a coding assistant is that it becomes challenging to have the agent work on a containerized project. You often need some janky "docker-in-docker" nonsense that hampers efforts.

I like using LXC containers, eg full persistent OS and you can do docker if you want etc. I started this and it works well for me to put on a server or VPS:

https://github.com/jgbrwn/vibebin

Re: Coding Agent VMs on NixOS with Microvm.nix

#42

Post by indigodaddy »

dist-epoch wrote: post #10
clawsyndicate wrote: post #2

we run ~10k agent pods on k3s and went with gvisor over microvms purely for density. the memory overhead of a dedicated kernel per tenant just doesn't scale when you're trying to pack thousands of instances onto a few nodes. strict network policies and pid limits cover most of the isolation gaps anyway.

LXC containers inside a VM scales. bonus point that LXC containers feel like a VM.

I started this with same idea:

https://github.com/jgbrwn/vibebin

Re: Coding Agent VMs on NixOS with Microvm.nix

#43

Post by 0x457 »

Cyph0n wrote: post #37
0x457 wrote: post #25

Earlier quoted context omitted.

It's also an answer to caching with /nix/store. I wish more cloud services supported "give me your nixosConfiguration or something similar" instead of providing api to build containers/vms imperatively. Dockerfile and everything that mimics it is my least favorite way to do this.

It’s fairly trivial to map your NixOS config into a VM image: https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui... An alternative is to “infect” a VM running in whatever cloud and convert it into a NixOS VM in-place: https://github.com/nix-community/nixos-anywhere In fact, it is a common practice to use the latter to install NixOS on new machines. You start off by booting into a live USB with SSH enabled,…

I know that part is easy, i just nix-anywhere just yesterday to reinstall one of my servers. It's not what I'm talking about.

Re: Coding Agent VMs on NixOS with Microvm.nix

#44

Post by esafak »

giancarlostoro wrote: post #33
nh2 wrote: post #29

Earlier quoted context omitted.

I find that a bit of a weird point. The goal of such sandboxing is that you can allow the agent to freely write/execute/test code during development, so that it can propose a solution/commit without the human having to approve every dangerous step ("write a Python file, then execute it" is already a dangerous step). As the post says: "To safely run a coding agent without review". You would then review the code, and u…

If that's the goal, why not just have Claude Code do it all from your phone at that point? Test it when its done locally you pull down the branch. Not 100% frictionless, but if it messes up an OS it would be anthropic's not yours.

But that's what Anthropic uses; a sandbox. Now you can have your own.

Re: Coding Agent VMs on NixOS with Microvm.nix

#45

Post by Cyph0n »

0x457 wrote: post #43
Cyph0n wrote: post #37

Earlier quoted context omitted.

It’s fairly trivial to map your NixOS config into a VM image: https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui... An alternative is to “infect” a VM running in whatever cloud and convert it into a NixOS VM in-place: https://github.com/nix-community/nixos-anywhere In fact, it is a common practice to use the latter to install NixOS on new machines. You start off by booting into a live USB with SSH enabled,…

I know that part is easy, i just nix-anywhere just yesterday to reinstall one of my servers. It's not what I'm talking about.

Okay, so your idea is that cloud providers should make this even easier?

    $ nixos-rebuild build-image --flake .#myhost --image-variant amazon
    $ aws-cli image upload

Re: Coding Agent VMs on NixOS with Microvm.nix

#46

Post by yearolinuxdsktp »

alexzenla wrote: post #24
clawsyndicate wrote: post #2

we run ~10k agent pods on k3s and went with gvisor over microvms purely for density. the memory overhead of a dedicated kernel per tenant just doesn't scale when you're trying to pack thousands of instances onto a few nodes. strict network policies and pid limits cover most of the isolation gaps anyway.

This is a big reason for our strategy at Edera ( https://edera.dev ) of building hypervisor technology that eliminates the standard x86/ARM kernel overhead in favor of deep para-virtualization. The performance of gVisor is often a big limiting factor in deployment.

How do you compete with Nitro-based VMs on AWS with 0.5% overhead?

Re: Coding Agent VMs on NixOS with Microvm.nix

#47

Post by schmuhblaster »

rictic wrote: post #11
heliumtera wrote: post #8

Couldn't you replicate all of your setup with qemu microvm? Without nix I mean

Yep. What nix adds is a declarative and reproducible way to build customized OS images to boot into.

Or try this: https://github.com/deepclause/agentvm, it's based on container2wasm, so the VM is fully defined by a Dockerfile.

Re: Coding Agent VMs on NixOS with Microvm.nix

#48

Post by the_harpia_io »

nh2 wrote: post #29
the_harpia_io wrote: post #6

[flagged]

I find that a bit of a weird point. The goal of such sandboxing is that you can allow the agent to freely write/execute/test code during development, so that it can propose a solution/commit without the human having to approve every dangerous step ("write a Python file, then execute it" is already a dangerous step). As the post says: "To safely run a coding agent without review". You would then review the code, and u…

[flagged]

Re: Coding Agent VMs on NixOS with Microvm.nix

#49

Post by the_harpia_io »

mystifyingpoi wrote: post #32
the_harpia_io wrote: post #6

[flagged]

> not just contain the execution environment. See, my typical execution environment is a Linux vm or laptop, with a wide variety of SSH and AWS keys configured and ready to be stolen (even if they are temporary, it's enough to infiltrate prod, or do some sneaky lateral movement attack). On the other hand, typical application execution environment is an IAM user/role with strictly scoped permissions.

[flagged]

Re: Coding Agent VMs on NixOS with Microvm.nix

#50

Post by syzcowboy99 »

alexzenla wrote: post #26
clawsyndicate wrote: post #4

Earlier quoted context omitted.

since we allow agents to execute arbitrary python, we treat every container as hostile. we've definitely seen logs of agents trying to crawl /proc or hit the k8s metadata api. gvisor intercepts those syscalls so they never actually reach the host kernel.

The reason why virtualization approaches with true Linux kernels is still important is what you do allow via syscalls ultimately does result in a syscall on the host system, even if through layers of indirection. Ultimately, if you fork() in gVisor, that calls fork() on the host (btw fork() execve() is expensive on gVisor still). The middle ground we've built is that a real Linux kernel interfaces with your applicati…

> Ultimately, if you fork() in gVisor, that calls fork() on the host

This isn't true. You can look at the code right here[1], there is no code path in gVisor that calls fork() on the host. In fact, the only syscalls gVisor is allowed to make to the host are listed right here in their seccomp filters[2].

[1] https://github.com/google/gvisor/blob/master/pkg/sentry/sysc...

[2] https://github.com/google/gvisor/tree/master/runsc/boot/filt...

Post reply on HN