OpenClaw is one of those AI assistant tools that’s been making the rounds lately. My reflex when I see popular software? Two questions: can I run it on RISC-V, and can I stuff it in a container? Spoiler: yes and yes. But getting there involved missing native binaries, cross-compilation gymnastics, a credential store that’s apparently case-sensitive (who knew?), and the kind of patience that only QEMU can teach you.

I have a BananaPi F3 sitting on my desk. SpacemiT K1 SoC, 16GB of RAM, running Armbian trixie on riscv64. It’s my favourite board for answering the question nobody else seems to ask: does this actually work beyond x86 and ARM? Usually the answer is "not yet." Sometimes it’s "sort of." Today it’s going to be "yes, but."

OpenClaw caught my eye. It’s an AI gateway/assistant that integrates with everything: Telegram, Discord, Slack, Signal, even WhatsApp. Makes you wonder if your toaster needs an AI layer too. Distributed via npm, with Docker images for the architectures that polite society cares about. Nothing for RISC-V, obviously.

Challenge accepted.

Before reaching for Docker, let’s try the simple path. SSH into the BananaPi, install Node.js 22 from unofficial-builds (because the Node.js project doesn’t ship official riscv64 binaries yet), and:

Twenty-three minutes later (grab a coffee, read some email, contemplate life choices), it’s done. For comparison, the same install takes about two minutes on amd64. The gap? node-llama-cpp compiling from source via cmake/g++ because there’s no prebuilt binary for riscv64. But it compiles. And it works. Twenty-three minutes well spent.

It works. On RISC-V. Natively. I could stop here.

But I’m a Docker Captain. I can’t stop here.

OpenClaw’s build system uses tsdown, which is powered by rolldown, a Rust-based JavaScript bundler. Rolldown ships precompiled native binaries for the platforms people actually use: linux-x64, linux-arm64, darwin-x64, darwin-arm64, win32-x64.

Not linux-riscv64.

If you’ve ever ported anything to RISC-V, you know this script by heart. The runtime? Works. The pure JavaScript? Works. The build toolchain that produces that JavaScript? Nope. Native dependencies. No riscv64.

The funny part? esbuild (used by Vite for UI builds) already ships @esbuild/linux-riscv64. Rolldown, being newer, hasn’t caught up yet. That’s the riscv64 ecosystem in a nutshell. It grows one package at a time, and you either learn patience or you learn to cross-compile.

The moment I figured it out, I felt silly for not seeing it sooner: tsdown’s output is pure JavaScript. The bundler needs native binaries to run, but what it produces is plain JS. Architecture-independent. Portable.

And Docker BuildKit has exactly the mechanism for this: --platform=$BUILDPLATFORM. Run the build stages on whatever architecture your host is (amd64, most likely), then target riscv64 for the final image. I’ve used this trick on ARM boards more times than I can count. Same playbook, different ISA.

Build the JS where the tools work. Run it where we want it. Obvious in hindsight. Took me longer than I’d like to admit to get there.

My first attempt was…​ not great. I shoved per-architecture conditional stages into the main Dockerfile. Terrible idea. It doubled pnpm install time for everyone on amd64/arm64. Rule number one when you’re porting to a niche architecture: don’t break the builds of the people who are actually using it in production.

The better approach: a separate Dockerfile.riscv64. Zero impact on existing builds. The CI workflow overlays it onto upstream tags via sparse checkout:

This lets us track upstream releases without modifying their code. Just add our riscv64 Dockerfile on top.

The full Dockerfile has a few more tricks worth mentioning. Bun has no riscv64 binary (surprise, surprise), so the runtime stage installs a stub script in /usr/local/bin/bun that exits with an explicit error. Silent failures at 2 AM are nobody’s idea of fun. And node-llama-cpp needs cmake, g++, and make to compile from source on riscv64, so those get installed in the runtime stage too. Yes, build tools in the runtime image. Don’t @ me.

Because one registry is never enough (I collect registries like some people collect stamps), the workflow now pushes to both GHCR and Docker Hub.

And because clicking "Run workflow" manually is for people with more patience than me, I set up the upstream sync workflow to auto-dispatch a riscv64 build whenever a new stable release tag appears. Except it didn’t work. Of course it didn’t.

A full day of porting, testing, and swearing at credential stores. Here’s where things stand.

The fork now auto-tracks upstream: every 6 hours, the sync workflow checks for new release tags and dispatches riscv64 builds automatically. No manual intervention needed. From upstream release to Docker Hub image, it’s fully hands-off.

The upstream PR (#12033) adds riscv64 as an optional build target for the main project. If merged, every OpenClaw release would natively include a riscv64 image without needing the fork.

OpenClaw isn’t the only game in town. A Reddit comparison thread lists a frankly absurd number of alternatives: PicoClaw, NanoClaw, ZeroClaw, TinyClaw, IronClaw, Pinchy, ZeptoClaw, NanoBot…​ I haven’t tried any of them on RISC-V yet. But I’m tempted.

PicoClaw and NanoClaw are lighter, probably a better fit for boards with 4GB or 8GB of RAM. ZeroClaw takes a minimalist approach that might sidestep the native binary problem entirely (fewer dependencies = fewer things to cross-compile). IronClaw and Pinchy are heavier beasts that would really stress-test the cross-compilation pattern.

The good news: everything in this article (the Dockerfile.riscv64 pattern, the BuildKit $BUILDPLATFORM trick, the QEMU CI pipeline) is reusable. If the tool uses Node.js and its build output is plain JS, the recipe is the same.

Which ones are actually worth running on RISC-V? I’ll find out. That’s the next article.