Posts

deploy.update_config, credential_spec, ports[].mode: host: every one of these is valid against the compose-spec schema, and none of them has ever done anything to a plain docker compose up. They’re Swarm-only. Before Compose 5.6.0, a file carrying any of them loaded without complaint, and whatever behavior you expected from reading the spec just never showed up, with no hint why. What changed Load a file with one of these attributes now, and Compose says so: ...

A provider managing containers on a remote or non-Docker runtime has always been able to declare build: or image: on its service, but getting the actual image bytes to wherever that runtime lives was left entirely to the provider: push to a registry it can reach, or shell out to docker save/scp and hope it matches what Compose actually resolved. Tip #61 covered provider services for exactly this kind of external dependency: databases, tunnels, Kubernetes intercepts. Compose 5.6.0 adds the piece that tip didn’t have yet: a provider can now opt into the same image phase every other service goes through. ...

docker network rm -f and docker context rm -f share a flag name and do different things. docker network rm --help says its -f means “Do not error if the network does not exist”: a network still attached to a running container survives it regardless. docker context rm --help says its own -f means “Force the removal of a context in use”: on a context, -f genuinely forces removal even while it’s the active one. Both commands describe their own behavior accurately. The trap is assuming -f means the same thing everywhere because it’s the same letter, and skipping the one --help you actually needed to read. docker-destructive-guardrails, the skill this closing post covers, exists for exactly this kind of inconsistency: the places where “it looked like the other command” is how damage happens. ...

An agent that only describes a plan instead of executing it isn’t a model problem. It’s usually missing the one tool it needs to act, and the fix is a single line in agent.yaml: type: shell or type: todo. That’s the kind of symptom Docker Agent is built to catch. Docker Agent (the CLI is docker agent, built on the open-source cagent engine) lets you define an AI agent, its model, its instructions, the tools it can call, optionally a whole team of sub-agents delegating to each other, in a single YAML file instead of application code, then run, serve, or publish that file the same way you’d run, serve, or publish a container image. See the Docker Agent documentation for the full product picture. docker-agent-config, docker-agent-run, and docker-agent-deploy, the three skills this post covers, take that file from authoring through production. ...

One command, sbx run claude ., and Claude gets a complete, disposable place to work: its own filesystem, its own network, its own Docker daemon, built from the current directory in a few seconds, instead of running directly on your machine with your own shell, your own files, and your own network access. That’s Docker Sandboxes: a standalone sbx CLI that runs an AI coding agent inside an isolated microVM so a runaway command, a bad rm, or a prompt-injected instruction stays contained to a disposable environment instead of your actual laptop. See the Docker Sandboxes documentation for the full product picture; docker-sandboxes-lifecycle and docker-sandboxes-network-credentials, the two skills this post covers, are what make that sandbox practical to drive day to day: how isolated the agent’s workspace is, how you get back into a sandbox you left running, and exactly what it can reach on the network and authenticate with. ...