I tried Docker Sandboxes but last time I checked you could not configure custom volume mounts, making more complex setups impossible. For work I need two directories for context for the agent to have access to…
I know some people want to run their agents when their computer is off, but I imagine a solution like this will be much more common than paying for a remote sandbox (i.e on fly.io or exe.dev), especially because it'll be free.
Though, they need to remove the login requirement.
I got excited for this not because this didn't exist before, but because Docker putting their weight on this would imply a broader adoption and better integration in the industry. I am sad that they are asking for a login here though, which doesn't make any sense to me.
The one thing I wonder about is how you enforce the usage of Docker Sandboxes vs running the agent on the host directly, apart from scanning machines for binaries
TO me, that's the important distinction: sandboxing limits what the agent can do but it doesn't necessarily enforce that the agent must run inside the sandbox. You need a separate control layer to enforce that boundary.
You design the sandbox so the agent starts in that layer. The next thing you can do is to limit the network access, this is what I'm working on right now.
Like many people, I suspect, I used Claude to write my own agent sandbox that suits my needs very well. Investing my time in a propietary product has become a hard sell.
You want to prevent the agent/others from reaching your home directory and other things. As long as you don't mount/sync directories/files from/to the container, so no mounting like "-v $(pwd):/app", but instead copy in, then when done, copy out.
And of course, instead of doing the "copy in > copy out" process manually, get your local agent to write a bash script that does that for you, given what directory you're in, and you're basically G2G.
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.
Ah let's see, do they still want you to LOGIN, in order to use a local dev tool? Yes, yes they do. No thanks Docker. You can keep your buzzword reasoning as to why this is needed.
Wow, I hope one day Linux will be able to support the exclusive MacOs/Windows technology of Docker Sandboxes.
(it's in the doc, but kinda strange to not see some instructions on the main page, probably distro related)
There's always https://github.com/mensfeld/code-on-incus
> 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.
It’s real VMs, firecracker style.
I’d rather use another open source solution that doesn’t require a signup, and less likely to get rugpulled.
There is no reason to require a login for creating local mini sandboxes.
If you’re on Apple, native solutions like “container-machine init” come built in and are pretty good, if you’ll only be on Apple hardware.
I tried Docker Sandboxes but last time I checked you could not configure custom volume mounts, making more complex setups impossible. For work I need two directories for context for the agent to have access to…
I started building my own isolated and security-hardened docker image for OpenCode about half a year ago. Been using it daily.
https://github.com/pkhamre/opencode-docker
I know some people want to run their agents when their computer is off, but I imagine a solution like this will be much more common than paying for a remote sandbox (i.e on fly.io or exe.dev), especially because it'll be free.
Though, they need to remove the login requirement.
I got excited for this not because this didn't exist before, but because Docker putting their weight on this would imply a broader adoption and better integration in the industry. I am sad that they are asking for a login here though, which doesn't make any sense to me.
That's docker, man. Tomorrow they're gonna add limits on sandbox runs without a premium account too
If any AI company was doing serious engineering isolated containers would have been a prerequisite to using their tools.
Reminds me of sandboxy - https://github.com/apple/containerization/tree/main/examples...
Also if your thing doesn't work with `pi` out of the box, then low effort
Requires login. Garbage.
I build a OSS lightweight, portable VM for those that don't want lock ins: https://github.com/smol-machines/smolvm
What? Does using sbx require login? Bummer.
Yes and they have a specific subscription for managing sandbox policies across the enterprise: Docker AI Governance
You can create those manually but if you want to enforce those then you need the subscription
The one thing I wonder about is how you enforce the usage of Docker Sandboxes vs running the agent on the host directly, apart from scanning machines for binaries
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.
it's running a full VM so the agent can eg: run docker commands safely etc
TO me, that's the important distinction: sandboxing limits what the agent can do but it doesn't necessarily enforce that the agent must run inside the sandbox. You need a separate control layer to enforce that boundary.
You design the sandbox so the agent starts in that layer. The next thing you can do is to limit the network access, this is what I'm working on right now.
Or do you mean something else?
Like many people, I suspect, I used Claude to write my own agent sandbox that suits my needs very well. Investing my time in a propietary product has become a hard sell.
Were you following any patterns/standards/advice on what you needed to protect against? Anything you can point the rest of us to?
You want to prevent the agent/others from reaching your home directory and other things. As long as you don't mount/sync directories/files from/to the container, so no mounting like "-v $(pwd):/app", but instead copy in, then when done, copy out.
And of course, instead of doing the "copy in > copy out" process manually, get your local agent to write a bash script that does that for you, given what directory you're in, and you're basically G2G.
What is the advantage of copying rather than a bind-mount?
What specifically are you looking for? If you start from the premise that it runs as you right now, then that's something you can easily improve upon.
Start by mounting just your repo and passing in the keys for the agent. Take it from there, it's like software engineering, you iterate.
When you run into issues you expand the tools in the container available to it.
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.
Open source alternative with podman support and local telemetry collection https://github.com/VibePod/vibepod-cli
Docker management will fail their tech at every opportunity.
The linked page implies there is no linux support, I wonder why. It's there in the docs if you hunt for it.
The docs are here: https://docs.docker.com/ai/sandboxes/
The other url is their marketing page.
Yes, Linux is supported.
Ah let's see, do they still want you to LOGIN, in order to use a local dev tool? Yes, yes they do. No thanks Docker. You can keep your buzzword reasoning as to why this is needed.