Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

251–260 of 407 posts

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

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

https://smolmachines.com has "smolvm" microvms, for better security. The DX is whatever you decide to do with it.

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

#252
I'm currently facing this issue. I've resorted to implementing my own execution environment albeit limited.

It goes like this: - bash script parser + interpreter (with hooks for things like file open, execute etc.,) - wasm executor for execution. - wasm implementations of common tools like coreutils, grep, sed etc., from the uutils project. - wasm implementation of python by a VMware backed project. - entirely virtualized filesystem using Go's io/fs.FS. (tmp dirs can be implemented using any backend)

Works like a charm for the limited usecase I have. There are definitely some drawbacks with threading and especially with preopens in wasm. But a cheap sandbox for simple file explorations and minimal computations.

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

#253
post #250

Earlier quoted context omitted.

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.

So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?

How would that work? You don't control github.com servers so your repo would never see the secret.

edit: You may want to look into tokenizing proxies as the general application of this concept.

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

#254
Does anyone have a solution for iOS development?

I was all in on sandboxes and safehouse for my agents but the moment I got into iOS development it felt like my hand was forced to just run Claude / codex / pi directly on my machine because nothing else could do the dev loop.

It’s been a painful reality for me, I’m going against core pieces of how I feel I should be interacting with agent harnesses and yet, I need to get the work done so

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

#255
post #247

Operating systems ought to be providing us the utilities we need to safely sandbox processes (agent or otherwise), but they appear to not be interested in the job

Apple, Microsoft, IBM, Unisys, HP, Oracle/Sun have done that for a while now.

Poorly! Apple’s facilities for this are the ones I know best, and they are woefully insufficient

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

#256
post #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.

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.

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

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

My startup is open core: https://github.com/gofixpoint/amika

We run cloud sandboxes, and have some experimental local sandbox support that is fully OSS.

Main thing for amika.dev is you can control the sandboxes and agents interchangeabley by SSH, web, or API, and can expose the services the agent is working on over signed URLs

Entire sandbox config is a TOML file

We're going to improve the local OSS sandbox mode and add better network controls over the next couple weeks.

Ultimately, what we're building kind of like if Tailscale and Firecracker had a baby, with a messaging protocol for remote controlling any sandboxed agent

It's free to try out. Still a lot to build, so we really appreciate any and all feedback about what we should focus on

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

#258

Earlier quoted context omitted.

I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing? thanks

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!

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

#259
post #247

Earlier quoted context omitted.

Apple, Microsoft, IBM, Unisys, HP, Oracle/Sun have done that for a while now.

Poorly! Apple’s facilities for this are the ones I know best, and they are woefully insufficient

Well, the features announced at WWDC 2026 naturally are yet to be made available in a mature form.

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

#260
post #250

Earlier quoted context omitted.

So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?

How would that work? You don't control github.com servers so your repo would never see the secret. edit: You may want to look into tokenizing proxies as the general application of this concept.

Your agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt
Post reply on HN