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

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

Post reply on HN
Print view View original

401–410 of 417 posts

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#401

Post by apitman »

dist-epoch wrote: post #126
Grimburger wrote: post #37

> Each agent runs inside a dedicated microVM with your dev environment What's a "microVM" and what's the security model here compared to using real virtual machines with actual constraints on breakouts? Is it marketing fluff? Incus/LXD has had VM's for a long time now. incus launch images:ubuntu/26.04 my-ubuntu-vm --vm incus exec my-ubuntu-vm -- bash

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 conta…

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

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#402

Post by icedchai »

ruszki wrote: post #386
icedchai wrote: post #335

Earlier quoted context omitted.

There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls

So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?

The docs mention it can be bypassed for configured domains.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#403

Post by figmert »

codethief wrote: post #192
sureglymop wrote: post #72

What is the main benefit over doing something like: docker run --runtime krun --rm -it -v $(pwd):/workspace/$(basename $(pwd)) -w /workspace/$(basename $(pwd)) --network restricted-net ghcr.io/openai/codex-universal:latest sh That runs the codex OCI in a qemu microvm. From what I can see, more fine grained network and filesystem access control as well as convenience?

Yes, pretty much, except for one detail: > That runs the codex OCI in a qemu microvm. AFAIU it's actually the other way around: krun spawns a libkrun-based (not QEMU-based) VM inside a crun container. Source: https://github.com/libkrun/libkrun/discussions/538#discussio... So with your solution you get the additional security benefit of containerizing the hypervisor on the host.

Once you have a vm, the container provides next to no additional security benefits. It's just unnecessary overhead at that point.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#404

Post by kylequest »

TLDR facts about Docker Sandboxes (based on its install): Uses ContainerD compiled natively for Mac OS and uses Nerdbox for the VMs:

├── bin

│ └── sbx

├── libexec

│ ├── containerd-shim-nerdbox-v1 │ ├── mkfs.erofs

│ ├── mkfs.ext4

│ ├── nerdbox-kernel-arm64

│ └── nerdbox-rootfs-arm64.erofs

More info about Nerdbox is here https://github.com/containerd/nerdbox

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#405

Post by mplemay »

rusch wrote: post #58

The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…

If you are looking to write have you're agent write typescript code, check out: https://github.com/mplemay/belgie.

TLDR: You're agent will get a isolated v8 runtime (chrome's sandboxed javascript runtime)

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#406

Post by ruszki »

icedchai wrote: post #402
ruszki wrote: post #386

Earlier quoted context omitted.

So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?

The docs mention it can be bypassed for configured domains.

Yes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#407

Post by brettpro »

ethagnawl wrote: post #383
macNchz wrote: post #241

Earlier quoted context omitted.

It does, for whatever reason the marketing page doesn’t advertise it but the docs have Linux instructions: https://docs.docker.com/ai/sandboxes/ I’ve been using this pretty extensively for a few months on Mac and Linux and have been super happy with it.

Thanks. That omission didn't smell right based on everything I know about Docker. Curious choice, indeed, not to show Linux install instructions.

When I tried this a month or so ago Linux support was markedly bad, and a quick look at the GitHub issues confirmed it wasn't just me and wasn't a priority for the company. I wouldn't advertise it either.

The nails in the coffin were 1) login was required 2) login was broken because they "didn't consider" it would be run in a headless environment [0] and 3) they shipped with hardcoded binary paths and root requirements [1].

I moved on and use Incus directly with small helper scripts, smolvm, or a full fat VM running desktop Claude or ChatGPT if I (or someone I mentor) really needs the full app. I'm not yoloing every new claw agent in --dangerously-destroy-my-things mode, so network restrictions are best effort, though filesystem access stays tight.

Either way, docker sandboxes really didn't seem to be it, and the company didn't seem interested in trying to be anything beyond an enterprise solution.

0. https://github.com/docker/sbx-releases/issues/186#issuecomme... 1. https://github.com/docker/sbx-releases/issues/48

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#408

Post by [deleted] »

ruszki wrote: post #386
icedchai wrote: post #335

Earlier quoted context omitted.

There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls

So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?

[deleted]

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#409

Post by toksdotdev »

ruszki wrote: post #386
icedchai wrote: post #335

Earlier quoted context omitted.

There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls

So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?

microsandbox maintainer here. the custom certificate is installed in the guest's trusted root CA list, so it should work across any program, except where the program opts to explicitly pin certificates for a destination.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#410

Post by codethief »

dbmikus wrote: post #258
codethief wrote: post #189

Earlier quoted context omitted.

In my experience it's mostly the UX/DX where Gondolin is lacking. For instance, I don't want to set up a JavaScript project every single time I need a sandbox. Instead, I just want to place a config file somewhere in my repo or my home dir and be done with it. So I wrote a wrapper around Gondolin which allows me to do that and a few other things: https://github.com/codethief/tuor (Warning: Still very much experimenta…

If you'd be open to trying something else, my startup is open core: https://github.com/gofixpoint/amika The definition for your cloud sandboxes is just a TOML config in your repo We also have an API and CLI to let users message the agent from outside or across sandboxes We're still building a lot, so if you have any time to try it out (amika.dev) and give feedback, that is worth gold to us!

I'm afraid I don't want my sandboxes to live in the cloud, though. :-)
Post reply on HN