What --platform linux/amd64 triggers

Ask for an architecture your machine doesn't have, with docker pull --platform linux/amd64 <image> or an image that has no arm64 build at all, and Docker doesn't refuse. It runs the amd64 binaries through QEMU's user-mode emulation, registered with the kernel through binfmt_misc, the same facility Linux uses to run any non-native executable format. It works, but it's instruction translation in software with no hardware help, so anything CPU-bound is noticeably slower than the native arm64 build. The Virtualization.framework vs. QEMU post explains why.

Docker Desktop sets up that QEMU registration for you. If you run Docker Engine directly inside a Linux workspace instead, it isn't there until you add it, usually with a one-time docker run --privileged --rm tonistiigi/binfmt --install all inside the guest.

A faster path if Rosetta is already set up

If you run Docker inside a Linux workspace, this part is worth knowing. Setting up Rosetta for Linux registers Rosetta as the guest kernel's handler for x86-64 ELF binaries with the --fix-binary yes flag. That flag makes the kernel open the interpreter once, at registration, which is what lets the registration keep working for a process inside a container's own mount namespace; the container image doesn't need its own copy of the interpreter. That's standard Linux kernel behavior, and it's the same principle tonistiigi/binfmt relies on for QEMU.

So once Rosetta is registered in a guest, an amd64 container's binaries may already be going through Rosetta rather than QEMU. Test it rather than assume: Velo Workspaces doesn't wire the two together explicitly, and we haven't published numbers for it. Pull a known amd64-only image and time something CPU-bound inside it, before and after the Rosetta setup in the same guest. If Rosetta is doing the work, you won't need a stopwatch to notice.

When no emulation is the right answer

Translation, Rosetta's or QEMU's, is a workaround for a missing native build, not a substitute for one. If the amd64-only image is yours, the fix is a multi-arch build, docker buildx build --platform linux/amd64,linux/arm64, so nobody pulling it has to emulate anything, your CI included. If it's a third-party image with no arm64 build, emulation is the only option short of finding an alternative, so budget for the slowdown instead of discovering it halfway through a build.

Related reading: Rosetta 2 in Linux VMs, can you install x86 Linux on an Apple Silicon Mac for the whole-OS version of this question, and Velo Workspaces vs. Docker Desktop vs. OrbStack. Or download Velo Workspaces and try it yourself.