An app connects to Redis at localhost:6379 in every environment, but Redis never actually lives at the same place twice: a local container in dev, a managed instance in staging, a different managed instance in prod. Something has to resolve that difference, and the easiest place to put it is scattered if ENV == "prod" branches in the app’s own config. The ambassador pattern puts it in one disposable container instead. ...

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. ...