Running Phoenix applications on RISC-V: A Practical Report

As part of a personal experiment, I attempted to run a Phoenix LiveView application - RawPair - on a RISC-V SBC (Milk-V Mars, Debian Trixie). The goal was to evaluate how viable it is to self-host modern web stacks on emerging architectures. Here's a summary of the process and findings. What Worked Platform: Debian Trixie (testing) Device: Milk-V Mars (riscv64) Installed components: Elixir 1.18.3 Erlang 27.3.3 Node.js 22 PostgreSQL Docker (docker.io package) Phoenix application code built and compiled successfully ttyd compiled from source Supervisord used for process management Basic Phoenix endpoint launched and connected to the database What Didn't Work Out of the Box Tailwind CSS CLI Phoenix LiveView's default asset pipeline depends on the Tailwind CLI (tailwind package), which wraps a native binary written in Rust (tailwindcss-oxide). The official Tailwind releases do not include builds for the riscv64 architecture. This resulted in: Runtime errors stating the architecture was unsupported The Phoenix build process failing during mix assets.build Incompatibility with Tailwind's scanning and compilation steps Workarounds attempted Using Docker to run Tailwind in an arm64 container via QEMU emulation (proved too slow) Manually building Tailwind from source (required TurboRepo, also unavailable on RISC-V) Manually building TurboRepo from source (679 Rust modules) What's the Core Issue? Tailwind's CLI requires a precompiled binary to run. On unsupported platforms like riscv64, no fallback mechanism exists. While the broader Phoenix stack is portable and builds fine on RISC-V, Tailwind currently introduces an architectural dependency that breaks compatibility. Potential Solutions Using the Play CDN for Tailwind in limited cases (not viable if using @apply or purging unused classes) Replacing Tailwind with a CSS approach that doesn't require native compilation (far from straightforward on Phoenix-based applications) Requesting RISC-V support upstream (see: Tailwind GitHub issue) Summary Running Phoenix + PostgreSQL on RISC-V is possible and surprisingly smooth with Debian Trixie. Tailwind CSS currently blocks full compatibility due to its architecture-dependent binary. This experience highlights the challenges of using modern frontend tooling on emerging platforms. I'm documenting this in case others attempt something similar or are evaluating frontend stack portability.

Apr 20, 2025 - 01:38

Running Phoenix applications on RISC-V: A Practical Report

As part of a personal experiment, I attempted to run a Phoenix LiveView application - RawPair - on a RISC-V SBC (Milk-V Mars, Debian Trixie). The goal was to evaluate how viable it is to self-host modern web stacks on emerging architectures.

Here's a summary of the process and findings.

What Worked

Platform: Debian Trixie (testing) Device: Milk-V Mars (riscv64)

Installed components:

Elixir 1.18.3
Erlang 27.3.3
Node.js 22
PostgreSQL
Docker (docker.io package)
Phoenix application code built and compiled successfully
ttyd compiled from source
Supervisord used for process management
Basic Phoenix endpoint launched and connected to the database

What Didn't Work Out of the Box

Tailwind CSS CLI

Phoenix LiveView's default asset pipeline depends on the Tailwind CLI (tailwind package), which wraps a native binary written in Rust (tailwindcss-oxide). The official Tailwind releases do not include builds for the riscv64 architecture.

This resulted in:

Runtime errors stating the architecture was unsupported
The Phoenix build process failing during mix assets.build
Incompatibility with Tailwind's scanning and compilation steps

Workarounds attempted

Using Docker to run Tailwind in an arm64 container via QEMU emulation (proved too slow)
Manually building Tailwind from source (required TurboRepo, also unavailable on RISC-V)
Manually building TurboRepo from source (679 Rust modules)

What's the Core Issue?

Tailwind's CLI requires a precompiled binary to run. On unsupported platforms like riscv64, no fallback mechanism exists. While the broader Phoenix stack is portable and builds fine on RISC-V, Tailwind currently introduces an architectural dependency that breaks compatibility.

Potential Solutions

Using the Play CDN for Tailwind in limited cases (not viable if using @apply or purging unused classes)
Replacing Tailwind with a CSS approach that doesn't require native compilation (far from straightforward on Phoenix-based applications)
Requesting RISC-V support upstream (see: Tailwind GitHub issue)

Summary

Running Phoenix + PostgreSQL on RISC-V is possible and surprisingly smooth with Debian Trixie.

Tailwind CSS currently blocks full compatibility due to its architecture-dependent binary.

This experience highlights the challenges of using modern frontend tooling on emerging platforms.

I'm documenting this in case others attempt something similar or are evaluating frontend stack portability.