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.
I'd like to see real numbers that compare Docker Desktop for macOS before microVMs to post-microVMs.
I stopped using Docker on macOS because host file system performance was so slow, even with all of the caching hacks piled on top of it, that it made the whole thing effectively unusable for development.
Directionally the post shared sounds great, but it seems "too good to be true" that we'd have a performant microVM for macOS.
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.
Do you have a strategy for secrets? Such as storing them, or using MitM to inject them (e.g., HTTP API requests)? I've used squid cache in the past, and currently use iron-proxy for this sort of feature.
The secrets are stored in the OS-specific keychain. When a sandbox starts, the network proxy injects the secret into the request (as auth headers) only when the hostname matches.
Concept is great - works quite well - I often have multiple short lived sandboxes running at once.
Docs [1] on overriding auth are incorrect. Sbx ignores inject[].username for basic auth and instead the stored secret needs to be the complete Authorization header. This should be made clear, or fixed.
Having to log in every couple of days SUCKS!! Opening the browser so I can login (which we shouldn't have to do) interfers with my scripts that create and destroy sandboxes as I need them.
I miss the old worktree functionality - I dislike the new clone concept - So I've created my own scripts that create a worktree for a feature, and run sbx create/run from there.
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://docs.docker.com/ai/sandboxes/customize/
On MCP, since credential handling was mentioned here: the sandbox sees one gateway endpoint, and OAuth tokens stay in the host credential store rather than in the VM. https://docs.docker.com/ai/sandboxes/mcp-gateway/
All this is early. We're looking at more based on feedback from users like running sandboxes in the background for long-horizon work and a lot more (including what you all raised in the thread here). Keep them coming.
The parent didn't go into any detail. I can. Homebrew has a history of ripping out your foundation underneath you. One day you are on Python 3.8, then next day you are on Python 3.10 and all your packages are broken. MacPorts doesn't do that.
Now, whether you should you be using the Homebrew Python is a completely different question. YMMV for other platforms managed via Homebrew.
I've traditionally used MacPorts for dev tooling and Homebrew for everything else, but with more aggressive adoption of tooling like uv an nvm I'm not sure the different really matters for me anymore.
Exactly. Same with PHP, MySQL etc…
Also they just block old versions and dont let you install them, you have to jump through a lot of hoops to use an old PHP version for example, so in no way developer friendly.
In the end I realized that Brew is a package manager for consumers, and as a professional i should’nt keep fighting it.
A lot of that is simply formula authors / application devs who don't know what they're doing (python@3.10 and other versions are a thing, and have been for quite a while now, but they're not always used and devs don't always keep track of the version they need) and people not updating their software for years (pythons are on a 5 year cycle everywhere, homebrew included: https://devguide.python.org/versions/ and https://formulae.brew.sh/formula/python@3.10 ).
Python in particular is well known to not be a stable target. For anyone. By design. If you expect long term use of a specific version of code, use a different language. It is not at all homebrew's fault that they're how many people discover that.
pyenv has been standard tooling for far longer than uv. depending on package manager supplied Python packages only makes sense if you’re running rhel or Debian or something and your application is packaged/deployed/the maintenance path uses dnf/apt. Otherwise you should always use a venv and use an out of package manager update mechanism. Like, in a broader sense, vendoring dependencies only makes sense if you’re shipping an application, not on a dev box.
That's what the GP means as well, you can use pyenv and uv to install multiple versions of Python and create envs with whichever version you want to use.
I switched to mise too for all my dev tooling. It just works so nicely for all kinds of ecosystems. I can use the same tool for Python, Node, Java, whatever and it just works.
Neat approach. Also, we're seeing a number of approaches to sandboxing every day now. Got me thinking about why we're seeing this resurgence. Thoughts?
I think a lot of this current sandboxing interest is coming from a break in assumptions. Traditional security mostly assumed a human was driving. Actions are chained together slowly and there’s time to notice and intervene. Agents have root access/tons of privilege but they execute at machine speed. The controls (firewalls/IAM) all still “work,” but the thing they were implicitly relying on (human judgment + hesitation) isn’t there anymore.
Since that assumption went away, we're all looking for ways to contain this risk + limiting what can happen if the coding agent does something unintended. Seeing a lot of people turn toward containers, VMs, and other variants of them for this.
Full disclosure: I’m at Docker. We’ve seen a lot of developers immediately reach for Docker as a quick way to fence agents in. This pushed us to build Docker Sandboxes, specifically for coding agents. It’s early, and we’re iterating, including moving toward microVM-based isolation and network access controls soon (update within weeks).
Hey - Srini from Docker here. We’ve seen a lot of developers turn to Docker for this use case and heard some mentions of the Docker-in-Docker block. We put out Docker Sandboxes in experimental preview as a potential answer. Still early but we're working on the next iteration based on MicroVMs and avoids Docker-in-Docker.
How does docker sandbox solve the docker-in-docker issue? Can Claude running in docker sandbox spin up other docker containers, without having privileged access?
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.docker.com/blog/why-microvms-the-architecture-be...