Create a docker-bake.hcl (or docker-bake.json) file at the repository root; define a group and multiple targets, each with its own context, dockerfile, tags, and platforms
Define shared configuration in a variable block or by using inherits to avoid repeating platform or cache settings across targets; example: target 'base' { ... } then target 'app' { inherits = ['base']; ... }
Add cache-from and cache-to inside each target block using the same type= syntax as buildx: cache-to = ["type=registry,ref=YOUR_REGISTRY/myapp-TARGET:cache,mode=max"]
Run all targets in parallel with docker buildx bake --push; add --print first to validate the resolved bake definition without building
Override individual target values from the CLI without editing the file: docker buildx bake --set target.tags=myapp:dev-SHA to inject a dynamic tag in CI
Use a matrix strategy in GitHub Actions to run docker buildx bake across multiple bake files or target subsets if the full bake graph is too large to run in one job
Known gotchas
Bake targets are built in parallel when they are independent; if a target depends on another (via inherits or a shared stage), declare that dependency explicitly so bake serializes correctly
When using the build-push-action GitHub Action with bake mode, set builder_driver: docker-container explicitly — the action does not auto-switch the driver in bake mode and the default driver ignores cache-to
The --set flag overrides are dot-path expressions (target.field); forgetting to match the exact target name in --set causes the override to be silently ignored
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp