Why is it useful to create a personalized builder if on it is also included the platforms supported by the default one?

[gmartinez1985]

There is something I'm missing about the usefulnes of creating a builder.

In my case I'm using a Mac device with arm64 architecture. I have Docker installed through Docker Desktop. My Docker version is 27.0.2, build 912c1ddf8a.

By default there are 2 builders, supporting both of them the same platforms:

If I create a new custom builder por the architectures riscv64 and 386 (and also an invented one), when I run it is added to the list of my 3 platforms all the supported platforms by my Docker installation.

In fact, if having the following basic Dockerfile:
FROM hello-world:linux

I execute the build for riscv64 and 386 (the 2 existing arquitectures I included in my builder), and also for amd64:

3 executions are succeed when in my custom builder I didn't include amd64

So, why is it useful to create custom builders if in any of them it is also to be included all the supported platforms by the default one?

Greeting and thanks in advance.

[wellkilo]

The --platform values attached when creating a builder are not an allow-list. They advertise/override platforms for a node; BuildKit also detects the worker's native platform and any emulated platforms registered through binfmt/QEMU. docker buildx inspect therefore shows the union of detected and configured capabilities.

On Docker Desktop for Apple Silicon, the VM normally has binfmt handlers for several architectures, so amd64 can succeed even if you mentioned only riscv64 and 386. The invented platform is merely metadata until a build actually needs to execute a RUN command or pull a base for it; declaring it does not install an emulator or make it buildable.

Custom builders are still useful because they choose a different BuildKit daemon/driver and configuration:

• docker-container, Kubernetes or remote execution;
• isolated/persistent cache;
• multiple native nodes for multi-platform builds;
• custom buildkitd config, certificates, network and entitlements;
• newer BuildKit than the Engine-bundled default;
• controlled lifecycle and resource limits.

To verify real execution support, use docker buildx inspect --bootstrap and build a Dockerfile with a RUN uname -m for the target. A FROM-only or no-RUN build may only assemble descriptors/layers and does not prove emulation works.

So create --platform is capability advertisement, not restriction. Build requests are restricted with docker buildx build --platform=..., while actual support comes from the worker plus emulators/native nodes.