Copied to Clipboard
That’s it. The build itself? Already working. The packaging scripts? Already existed as templates. The repository signing and publishing? Already automated.
The Build: 9 Minutes and 13 Seconds
I triggered the build workflow for Buildx v0.29.1 (the latest upstream release as of November 2025). The BananaPi F3 self-hosted runner picked it up.
Nine minutes and thirteen seconds later: done.
Native RISC-V64 binary compiled. GitHub release created. Debian package built automatically. RPM package built automatically. Both added to their respective repositories. GPG-signed metadata generated.
I opened a terminal:
sudo apt update
sudo apt install docker-buildx-plugin
Verified:
$ docker buildx version
github.com/docker/buildx v0.29.1
It just... worked.
What Users Get Now
If you’re running Docker on RISC-V64 using our repository, you now have access to:
Latest upstream version: v0.29.1, same as any other architecture
Standard installation: Just apt install docker-buildx-plugin or the RPM equivalent
Automatic updates: Daily tracking means new Buildx releases get built and packaged within hours
Full feature set: Multi-platform builds, advanced caching, build secrets—all of it
And here’s what makes me proud: it’s all integrated into the same infrastructure. The same automated tracking. The same build pipelines. The same repository management. The same GPG signing.
Adding Buildx didn’t require inventing new processes. It required connecting existing pieces.
When You Know Your Infrastructure Is Working
I’ve been thinking about what this moment represents.
A few months ago, the question was: "Can we even get Docker working on RISC-V64?" We were patching build files, debugging submodule conflicts, and manually compiling binaries.
Today, the question is: "What feature should we add next?" And the answer took three PRs and less than 10 minutes of actual build time.
That’s infrastructure maturity.
It’s not about the individual components being perfect. It’s about the system being composable. When you can add new capabilities by following existing patterns, when automation carries the heavy lifting, when the boring parts stay boring—that’s when you know you’ve built something sustainable.
The Complete Picture
Let’s zoom out for a second. Here’s what we have now for RISC-V64:
| Component |
Status |
| Docker Engine |
dockerd, containerd, runc - Weekly builds, daily release tracking |
| Docker CLI |
docker command - Weekly builds, daily release tracking |
| Docker Compose |
Multi-container orchestration - Weekly builds, daily release tracking |
| Docker Buildx |
Advanced build features - Weekly builds, daily release tracking |
| Tini |
Container init process - Weekly builds, automated packaging |
All built natively on RISC-V64 hardware. All packaged for Debian and RPM distributions. All served through signed, maintained repositories. All automatically updated when upstream releases new versions.
This is what a mature Docker ecosystem looks like.
Takeaways & What’s Next
Here’s what I’m taking away from this:
Infrastructure investment compounds - Those days building automation weren’t just for Docker Engine. They made every subsequent addition easier.
Good patterns are reusable - The same workflow structure worked for Engine, CLI, Compose, and now Buildx. That’s not luck, that’s design.
Boring is beautiful - The most successful automation is the kind you forget exists until you need it. This workflow has been running weekly for days without intervention.
RISC-V64 is ready - Not "almost ready" or "ready for experiments." Ready. Full Docker toolchain, maintained repositories, automated updates.
What’s next? Honestly, I’m not sure. The foundation is solid enough that we can shift focus from "make it work" to "make it better." Performance optimization? User experience improvements? More container tooling?
Or maybe just let it run. Sometimes the best thing you can do with infrastructure is nothing.
Try It Yourself
If you want to try Docker on RISC-V64, everything you need is at github.com/gounthar/docker-for-riscv64. Installation instructions, repository setup, the works.
And if you want the deep dive on how we got here—the self-hosted runner setup, the build pipeline architecture, the repository management—check out the comprehensive article on LinkedIn.
For now, I’m just going to appreciate that moment when you add a feature and it feels... easy.
That’s how you know you’ve done something right.
Resources