Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

111–120 of 450 posts

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

#111

Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will become one. cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand. Also, the kern…

Would you say podman is better, or is it the same as docker ?

In general running containers rootless is better from a security standpoint and podman makes this much easier. So, yes.

This is not my main point though. Both are based on cgroups and cgroups are the wrong tool for the job.

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

#112
I use it (sbx), but I don't 100% trust that it actually works, and I would prefer something open source where the limits of the sandboxing could be tested and explored.

Maybe we should just ssh into separate development machines to ensure real and verifiable sandboxing? (as was totally standard before Docker became a thing)

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

#113
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…

For persistent-ish one-off apps https://xbin.dev/ (my project)

Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.

Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)

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

#114
I hardly see how this matters, when Apple and Microsoft already have their own in box solutions for the same problem.

Better sandboxing for AI agents is exactly the main reason for containers improvements on macOS and Windows, with a few talks at WWDC, and BUILD.

Not sure how much they would get from Linux users then.

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

#115

> 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

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.

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

#117
Does this support Linux yet? When I previously looked it did not (the reason being that they were already using VMs on Windows/macOS but not on Linux). Every time I see an announcement I think "great, they must've added Linux now then", but the linked pages always have Windows + macOS instructions but not Linux.

All the open GH issues about supporting Linux that I subscribed to have gone unresponded to.

OpenShell looks like a good alternative, but it still has "Do not use in production" plastered all over the website, which doesn't fill me with confidence yet

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

#118

> 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

“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?

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

#119

I am not sure I understand, how is this different from a devcontainer or other similar techniques? On another topic, can't help but notice that "leading coding agents" somehow does not include Pi.

About the missing native support for Pi, I opened this issue long ago in case you want to add some pressure: https://github.com/docker/sbx-releases/issues/34

To work around that limitation I came up with this https://github.com/shaftoe/sbx-template-pi

So essentially you can get latest Pi/Node pulling from that image:

`sbx run -t ghcr.io/shaftoe/sbx-template-pi:latest shell`

Like others here I'm also saddened by the login requirement but at the moment this is the best UX I could find for running sandboxed agents, the "kit/mixin" concepts are neat and I make use of them too: https://github.com/shaftoe/sbx-template-pi#stacking-the-extr...

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

#120

Earlier quoted context omitted.

Bubble wrap is just containerisation no?

Not sure what you mean by "just". Containerisation is generally understood to mean something like what Docker does, which includes sandboxing but a whole lot more on top, like image management etc. Bubblewrap is just sandboxing without the rest of containerisation.

Docker Sandboxes is using microVMs, not containerization.
Post reply on HN