Is threre any plans to support docker sandbox command?

Docker Desktop Docker Sandbox
1

Hi, I would like to know whether docker sandbox will remain available in the future, or whether it is deprecated and planned for removal in a future update.

In my case, I cannot use sbx due to authentication limitations. I work in a closed network with self-hosted Harbor and Nexus instances.

2

I didn’t hear anything about discontinueing the docker sandbox command, but if you have problem with sbx, I would open a ticket on github

You are not the first asking about this, so I will try to find out if the docker sandbox command will still work in the future. I would assume yes.

3

Sorry for taking so long. I tried to get some more information and now I don’t think the old docker sandbox command will be the same in the future. The architecture of the old and the new sbx is different and although I remembered “Docker sandbox” was mentioned n the documentation of sbx, I can’t find it now. The only reference I found that Docker Desktop is not required for sbx.

I have no confirmation yet, but I think it is more likely that if the docker sandbox command gets an update, it will be the same as sbx now, so that wouldn’t thelp you.

Some features even in Docker Desktop started in a way that required logging in and later it was not necessary. One example is host network. So it is possible that something like that will happen to sbx, although the current FAQ doesn’t indicate that: https://docs.docker.com/ai/sandboxes/faq/#why-do-i-need-to-sign-in

Quote:

Docker Sandboxes is built around the idea that you and your agents are a team. Signing in gives each sandbox a verified identity, which lets Docker:

  • Tie sandboxes to a real person. Governance matters when agents can build containers, install packages, and push code. Your Docker identity is the anchor.
  • Enable team features down the road. Shared environments, org-level policies, audit logs. These all need a concept of “who,” and building that in later would be worse for everyone.
  • Authenticate against Docker infrastructure. Sandboxes pull images, run daemons, and talk to Docker services. A Docker account makes that seamless.

Your Docker account email is only used for authentication, not marketing.

So I can understand the explenation, but I also see how it is a problem in an air-gapped environment. Are you also using a local model? I heard that there were some problems with trying to use local models, like it was not possible to change the endpoint for some agents in sandboxes. I am not sure about the plans of supporting local models, but that would make a login requirement a little more unnecessary, since you can also load an image to the sandbox VM from a tar file.

In other words, is sbx’s login requirement is the only thing that would require you to allow some URLs to be available, or did you have to enable AI cloud service endpoints?

4

Thank you for your reply. It’s much clearer to me now.

I use local inference, so authentication is the only blocker for using sbx in my environment. For now, I’ll continue using docker sandbox while it still works, and then we’ll see how things develop