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

321–330 of 419 posts

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

#321

Post by hanwenn »

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…

I wrote my own (or rather, had Claude write it), https://github.com/hanwen/runclaude.

Mine uses containers, and makes only the git/jj workspace read/write, hiding all credentials that are in my home dir.

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

#322

Post by nopurpose »

LeBit wrote: post #157
nopurpose wrote: post #94

Earlier quoted context omitted.

Who is doing it as first class feature with at least adequate UX? I have skimmed alternatives offered in comments to this post (vibepod-cli, code-on-incus, opencode-docker, sandboxy, smolvm, amazing-sandbox) and none of them seem to do credentials injection at the proxy level.

nono. Also fnox now does credentials proxying.

Thanks, bookmarked nono to have a look later.

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

#323

Post by notsirius »

zingar wrote: post #29
notsirius wrote: post #9

been using this for a while - works great! Has also had a lot of updates over the past year so worth checking out again if you tried it a while ago

Do the agents come preinstalled in the images? Or do they somehow use whatever I’ve installed locally? The former makes sense to me but then I’m wondering whether the sandbox images stay up to date with new releases of each image.

Sometimes is up to date. When its not - you can just use a kit and add command: install : codex update https://docs.docker.com/ai/sandboxes/customize/kits/

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

#324

Post by aborsy »

cogman10 wrote: post #305
kwakubiney wrote: post #303

Earlier quoted context omitted.

Why’s it not on Linux? What are the difficulties with that platform?

Looks like they do support Ubuntu. Is this open source? Can I install this on a non Ubuntu system?

A limited form of it with different syntax comes with Docker Desktop. The sbx tool is not available for non-Ubuntu distributions.

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

#325

Post by tacker2000 »

srini-docker wrote: post #318
kwakubiney wrote: post #303

Earlier quoted context omitted.

Why’s it not on Linux? What are the difficulties with that platform?

Linux is available today (Ubuntu): github.com/docker/sbx-releases. Our webpage showing only brew and winget is on us. For the people upthread who asked about on customization: templates (like snapshotting a running sandbox) and kits (YAML applied at creation like install steps, files, network and credential rules, or define a new agent outright) are the supported path now. It's early but take a look here: https://doc…

Please consider adding MacPorts support.

Brew is notoriously developer-unfriendly.

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

#326

Post by atechboy »

srini-docker wrote: post #298

I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…

So the idea is to give each agent a VM to do several tool calls? or one VM for each tool call?

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

#328

Post by rocfan »

cogman10 wrote: post #305
kwakubiney wrote: post #303

Earlier quoted context omitted.

Why’s it not on Linux? What are the difficulties with that platform?

Looks like they do support Ubuntu. Is this open source? Can I install this on a non Ubuntu system?

CLI works on Fedora. Been using it daily for ~ a week.

See repo `docker/sbx-releases`. The `.rpm` there has Rocky Linux in the name but works on Fedora.

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

#329

Post by ruszki »

skinfaxi wrote: post #217
llimllib wrote: post #190

Earlier quoted context omitted.

right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret. And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it. Our agents are trained t…

The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.

But how? Normally the TLS handshake and encryption/decryption happen in user space. Even the kernel doesn’t know anything about it.

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

#330

Post by tanepiper »

srini-docker wrote: post #298

I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…

I'm very glad this now exists - fwiw almost a decade ago I worked on https://github.com/takeoff-env/takeoff as a solution for making it easier for hot reloading your stack which is thankfully redundant today, and funnily enough the list of problems you identify is also something I've been working on.

Recently I've also been working on a VM stack for an agentic platform using pre-build images with some cloud injection scripts that simplifies the deployment of a private agentic cluster - in the end I went with full VM with a 4vCpu/8gb for the main agent and 2vCPU/4Gb - only the main agent had docker-in-docker, the rest rootless docker but I agree it's still an elevated risk.

I'll definitely have to give this a spin and see if I can simplify it to one larger box with this solution.

Post reply on HN