Fast Multi-Platform Builds on GitHub

Source: Dev.to

Overview

Building multi‑architecture Docker containers in GitHub Actions is often done by installing BuildX and QEMU. While functional, QEMU emulation can be about 10× slower than native hardware (e.g., a simple Hello World project went from ~30 seconds to ~3 minutes).

Below are several ways to speed up those builds.

Options for Faster Multi‑Architecture Builds

• Switch to runners that have cross‑platform remote builds pre‑configured.
• Build single‑architecture images in a matrix and merge them manually.
• Use GitHub Actions instances as remote builders with Tailscale.
• Set up your own machines for remote builds.
• Leverage a Kubernetes cluster for remote builds.

Use Pre‑configured Runner Providers

Some runner providers ship with BuildX and native‑hardware remote builders already set up. One such service is Namespace.so. After signing up, you only need to change the runs-on field in your workflow YAML to use their runners.

Cost: roughly $2 / month for the author.

Build Single‑Architecture Images in a Matrix and Merge

Create a matrix of jobs, each building an image for a specific architecture, then merge the results with a buildx imagetools command.

docker buildx imagetools create -t nabsul/myproject:v1.0.0 \
    nabsul/myproject:v1.0.0-amd64 \
    nabsul/myproject:v1.0.0-arm64

This approach keeps the builds simple and avoids cross‑platform emulation, though it requires an extra merge step.

Remote Builders via GitHub Actions and Tailscale

You can spin up a buildkitd server in each job, join a Tailscale tailnet, and let the jobs discover each other for cross‑platform builds.

A typical shutdown helper used in the final step:

printf "HTTP/1.1 200 OK\r\nContent-Length: 16\r\n\r\nShutting down..." \
    | nc -l -p 8080

After the build finishes, a curl request triggers the shutdown.
Note: This setup is powerful but fragile—failed curl calls can leave jobs hanging, and you must manage Tailscale configuration and security.

Use a Kubernetes Cluster as Remote Builders

If you already have a Kubernetes cluster with both Intel and ARM nodes, you can run temporary namespaces for each build, execute the builds there, and clean up afterward. This avoids provisioning dedicated build machines but does require a cluster with mixed‑architecture nodes.

Use Your Own VMs as Remote Builders

Run separate VMs (e.g., one ARM, one Intel) and configure BuildX to use them as remote runners. You can secure the communication with TLS certificates or simplify networking by using Tailscale, which removes the need for manual certificate management.

Conclusion

Several viable strategies exist to accelerate multi‑architecture builds on GitHub Actions:

• Namespace.so offers the simplest, low‑cost solution.
• The matrix‑plus‑merge pattern is a reliable fallback if hosted runners become pricey.
• Tailscale‑based remote builders or a Kubernetes cluster provide flexible, self‑hosted alternatives, especially when you already have the infrastructure.

Choose the approach that best matches your cost constraints, existing resources, and tolerance for operational complexity.