Handmade Servers: Scaleway's RISC-V Rabbit Hole

Sixteen Euros and a 3D Printer

In a basement laboratory in Paris, sometime in late twenty twenty-three, engineers at Scaleway were hand-soldering components onto circuit boards. They were laser-cutting metal sheets into custom chassis. They were pulling 3D-printed blade enclosures off printers and fitting them with tiny computer modules. Not prototypes for a trade show. Not art installations. These were going into actual production racks in an actual datacenter, to be rented out to actual paying customers at fifteen euros and ninety-nine cents per month. The product was the Elastic Metal RV1, and when it launched on February twenty-ninth, twenty twenty-four, it became the first RISC-V server you could rent in any public cloud, anywhere in the world.

Now, the obvious question is: why? Why would a European cloud provider spend months of R&D building artisanal, hand-assembled servers around a processor architecture that most enterprise buyers have never heard of? A chip designed by Alibaba's semiconductor division in China? Running at one point eight five gigahertz with four cores and sixteen gigabytes of RAM? That is not exactly competing with the latest AMD EPYC. The answer is a story about open silicon, geopolitical chess, a vulnerability called GhostWrite, and six hundred and seventy-two servers crammed into a single rack.

The Alphabet Soup of Silicon

To understand what Scaleway actually built, you need to understand what RISC-V is, and more importantly, what it is not. Let's start with the letters. RISC stands for Reduced Instruction Set Computing. The V is the Roman numeral five, because this is the fifth generation of RISC research coming out of the University of California at Berkeley. The project started in twenty ten, and it was born out of frustration.

For decades, the processor world ran on two tracks. On one side, you had Intel and AMD with x86, a CISC architecture, meaning Complex Instruction Set Computing. These processors can execute elaborate multi-step instructions in a single call. They are powerful, ubiquitous, and utterly proprietary. On the other side, you had ARM, which is technically a RISC design, simpler instructions, more energy efficient, and it conquered mobile phones. But ARM is also proprietary. You want to make an ARM chip? You license the design from ARM Holdings, now owned by SoftBank, and you pay royalties. Every single phone in your pocket is paying rent to a company in Cambridge, England.

RISC-V said: what if the instruction set, the fundamental language a processor speaks, was free? Not free as in cheap, but free as in open source. Anyone can read it, anyone can implement it, anyone can extend it, and nobody owes anybody a licensing fee. The instruction set architecture, or ISA, is the contract between software and hardware. It defines what operations a processor must support, what registers it has, how memory is addressed. The ISA is to a chip what a language specification is to a programming language. You can write many different compilers for the same language. Similarly, you can design many different physical chips that all speak the same ISA.

This distinction is crucial. RISC-V the ISA is open. But any particular chip built to that ISA can be completely proprietary on the inside. The transistor layout, the pipeline design, the branch prediction logic, the cache hierarchy, all of that is the manufacturer's trade secret. Think of it like HTTP. The protocol is open. Anyone can implement a web server. But Nginx and Apache have completely different internal architectures.

The Chip Inside the Box

The processor Scaleway chose for their RV1 server is the T-Head TH fifteen-twenty, made by T-Head, which is Alibaba Group's semiconductor subsidiary. T-Head is one of the most active RISC-V chip designers on the planet, and they have been steadily climbing the performance ladder. The TH fifteen-twenty is a system-on-chip built around four Xuantie C nine-ten cores. That is T-Head's highest-performance RISC-V core design, running at one point eight five gigahertz in this configuration, though the chip is rated for up to two point five gigahertz. Nobody seems to actually run it that fast in practice.

The SoC includes sixteen gigabytes of LPDDR4 memory, a hundred and twenty-eight gigabytes of eMMC storage, an Imagination Technologies GPU capable of OpenCL and Vulkan, and a four TOPS neural processing unit for machine learning inference. There is also a secondary Xuantie C nine-oh-six core running at eight hundred megahertz as an audio DSP, and a tiny Xuantie E nine-oh-two low-power core for background tasks. It is a surprisingly complete system-on-chip for what started as an embedded platform.

The same chip powers the Sipeed LicheePi 4A single-board computer, the Milk-V Meles, the BeagleV-Ahead, and a handful of RISC-V laptops. In benchmarks, the C nine-ten core at one point eight five gigahertz trades blows with the Cortex-A72 in a Raspberry Pi 4. That is not going to threaten any server workload you can name. But that is also not the point.

The Art of Making a Server

Here is where the story gets genuinely strange and wonderful. There is no off-the-shelf RISC-V server motherboard. No Dell PowerEdge equivalent. No Supermicro chassis designed for RISC-V blades. The entire datacenter hardware supply chain, decades of standardization around UEFI boot, IPMI management, hot-swap drive bays, redundant power supplies, none of that exists for RISC-V. Scaleway had to build everything from scratch.

Their starting point was a clusterboard in the mini-ITX form factor, which groups seven RISC-V modules onto a single board. Mini-ITX is a standard for small computers. It is great for development. It is completely useless in a datacenter because you cannot mount it in a standard rack.

So the Scaleway Labs team designed custom blade enclosures, fully 3D-printed on their own printers in their Paris facility. The chassis that holds the blades was laser-cut from metal sheets. Every single manufacturing step was done in-house. They iterated on the design repeatedly, each version refining airflow, density, and cable management.

The result is a five-U chassis that holds twelve blades, six in the front and six in the back, with each blade containing one clusterboard of seven servers. That is eighty-four dedicated RISC-V servers in five rack units. Add one U for power supply, and a full fourteen-U section gives you two chassis, a hundred and sixty-eight servers. Scale that up to a fifty-two-U rack, and you can fit six hundred and seventy-two servers. Six hundred and seventy-two individual, independently addressable, bare-metal machines in a single rack.

The power consumption is equally wild. A full clusterboard draws about fifty-five watts. A complete chassis, twelve clusterboards, about six hundred and sixty watts. For comparison, a single Dell R660 one-U server draws around three hundred and fifty watts. Five U worth of Dell servers would draw about seventeen hundred and fifty watts and give you maybe five servers. Scaleway's RISC-V chassis draws six hundred and sixty watts and gives you eighty-four. The raw compute per server is obviously lower, but the compute per watt and compute per rack unit tell a very different story.

Booting Without a Map

The software side was arguably harder than the hardware. In the x86 world, every server boots through UEFI, a standardized firmware interface that has been refined over decades. It handles hardware initialization, secure boot, network boot, and hands off to the operating system in a predictable way. The RISC-V world had none of this.

Scaleway had to work with a boot process inherited from embedded systems. The chain goes like this: first, a minimal proprietary boot ROM on the chip runs. This loads a first-stage bootloader, which is a stripped-down version of U-Boot SPL, stored in the eMMC. This first stage is deliberately minimal and immutable so that a customer cannot accidentally brick the server. It loads a second-stage U-Boot, which in turn loads a third, final U-Boot that is configured differently. This final bootloader loads OpenSBI, which is the RISC-V equivalent of a firmware abstraction layer, and the Linux kernel.

OpenSBI deserves its own sidebar. It stands for Open Supervisor Binary Interface, and it is the reference implementation of the SBI specification. In the RISC-V privilege model, there are multiple levels of execution privilege. The lowest is user mode, where your applications run. Above that is supervisor mode, where the operating system kernel runs. And above that is machine mode, which has full access to everything. OpenSBI runs in machine mode and provides a standardized interface for the kernel to request privileged operations, things like managing interrupts, accessing hardware timers, or performing power management. It is roughly analogous to what BIOS or UEFI does on x86, but designed specifically for the RISC-V architecture.

Then there was the network boot problem. In a cloud environment, you do not install operating systems from USB sticks. Servers boot over the network. The industry standard is PXE, or iPXE, or UEFI HTTP Boot. Scaleway tested all three. Only PXE actually worked on the RISC-V hardware. Neither iPXE nor UEFI HTTP Boot had been ported to the architecture at that point. So PXE it was. They got the servers booting into a minimal BusyBox Linux environment over the network, then deploying full Debian installations. And with that, the software chain was complete enough to offer as a cloud product.

GhostWrite: When Your Vector Extension Writes to the Wrong Memory

In August twenty twenty-four, about five months after the RV1 launched, security researchers at the CISPA Helmholtz Center for Information Security in Germany dropped a bombshell. They had found a vulnerability in the C nine-ten processor that was not a side-channel attack, not a speculative execution issue like Spectre or Meltdown. It was a direct, deterministic hardware bug.

This vulnerability allows unprivileged attackers, even those with limited access, to read and write any part of the computer's memory and to control peripheral devices like network cards. GhostWrite renders the CPU's security features ineffective and cannot be fixed without disabling around half of the CPU's functionality.

The researchers had built a custom fuzzer called RISCover, later renamed RISCVuzz, that generated small programs and ran them across multiple different RISC-V processors, comparing the results. Since every RISC-V CPU should follow the same specification, they should produce the same outputs for the same inputs. The C nine-ten did not. When the fuzzer fed it a specific illegally-encoded vector store instruction, every other CPU either generated a page fault exception or refused to execute it. The C nine-ten just... executed it. And that instruction wrote directly to physical memory, completely bypassing the virtual memory system.

Let that sink in. The entire modern security model of computing depends on virtual memory. Every process gets its own virtual address space. The CPU's memory management unit translates virtual addresses to physical addresses, and ensures that one process can never see another process's memory. This is what keeps your web browser from reading your password manager's memory. This is what makes containers and virtual machines work. And the C nine-ten had a single instruction that just... skipped all of it. Wrote directly to the physical DRAM. No checks, no translations, no permissions.

The attack was one hundred percent reliable. It was deterministic. It took microseconds to execute. It worked through Docker containers. It worked through sandboxing. It could read the root password straight out of memory. It could interact with the hard drive, with network cards, with any peripheral device mapped to physical memory. It was, in the researchers' assessment, a complete compromise of the CPU's integrity.

The vulnerability existed because T-Head's implementation of the RISC-V vector extension had a bug in how it handled certain instruction encodings. The vector extension is a set of instructions designed for processing large amounts of data in parallel, similar in concept to Intel's SSE or AVX. T-Head implemented a draft version of the vector extension, specifically RVV zero point seven point one, which is not the final ratified standard RVV one point zero. And in their implementation, some instruction encodings that should have been treated as illegal were instead executed, with the processor routing memory operations through the physical memory bus instead of the virtual memory system.

The only fix was to disable the entire vector extension. On a processor where the vector extension accounts for roughly half of the instruction set, that is a significant performance hit, measured at about seventy-seven percent overhead by the RVV benchmark suite. Scaleway, to their credit, had already disabled the extension by default through a kernel update before the vulnerability was even publicly disclosed. They had been warned by the researchers in February, and acted quickly.

The Sovereignty Tangent

Now, here is where the story gets geopolitically interesting. RISC-V International, the foundation that governs the RISC-V standard, is headquartered in Switzerland. Not the United States. Not China. Not the UK. Switzerland. This is not an accident. It was deliberately moved there in twenty twenty to ensure that the standard could not be weaponized by any single country's export control regime.

This matters enormously right now. The United States has spent the last several years tightening export controls on advanced semiconductors, primarily targeting China. The restrictions cover high-end chips, chip design tools, and manufacturing equipment. ARM, being a company headquartered in the UK with extensive US operations, is subject to US export controls. So is Intel. So is AMD. So is NVIDIA. If you are China and you want to build advanced processors, your options are increasingly limited.

Except for RISC-V. Because the ISA is an open standard governed by a Swiss foundation, it is not subject to US export restrictions. You cannot embargo a publicly available specification any more than you can embargo the HTTP protocol. China has poured billions into RISC-V development. Alibaba's T-Head division, which makes the chip in Scaleway's servers, is one of many Chinese companies going all in. Huawei has invested heavily in the XiangShan project through the Chinese Academy of Sciences. The twenty twenty-five release of the Kunminghu architecture targets three gigahertz clock speeds and has been described as the Linux of processors, open, community-driven, and increasingly competitive.

In March twenty twenty-five, T-Head unveiled the XuanTie C nine-thirty, a server-grade sixty-four-bit multi-core processor that is fully compatible with the RVA twenty-three profile, the standardized baseline that ensures software compatibility. It features dual five-twelve-bit vector units and an integrated eight TOPS matrix engine for AI workloads. The performance targets are credible enough to compete with mid-range server offerings from Intel and AMD. This is a dramatic leap from the C nine-ten in Scaleway's servers.

Meanwhile, Europe is running its own RISC-V play. The EU Chips Act, passed in twenty twenty-two, allocated over forty-three billion euros to semiconductor development in Europe, and RISC-V is a major beneficiary. The DARE project, Digital Autonomy with RISC-V in Europe, received two hundred and seventy million euros and is coordinated by the Barcelona Supercomputing Center. The goal is to build European exascale supercomputers and automotive systems on homegrown RISC-V silicon, free from foreign export controls.

The launch of RISC-V servers is a concrete and direct statement by Scaleway to boost an ecosystem where technological sovereignty is open to all, from the lowest level upwards.

Scaleway joined the RISC-V Foundation in May twenty twenty-four. They are not just offering servers. They are positioning themselves as infrastructure for an entire political project: European digital sovereignty built on open silicon.

The Fragmentation Problem

Not everyone is thrilled about RISC-V's flexibility. The modularity that makes RISC-V attractive, the ability to add custom extensions for vector computing, AI processing, encryption, and more, also creates a combinatorial explosion of incompatible variants. Every combination of extensions is effectively a different processor. A program compiled for one configuration might not run on another.

Linus Torvalds has been characteristically blunt about this. He has publicly criticized the growing number of RISC-V variants, warning that fragmentation could undermine the entire project. If every chip maker adds their own custom extensions, you end up with a world where RISC-V is technically open but practically fragmented into islands that cannot share software. That is not sovereignty. That is balkanization.

The issue is that people see RISC-V as this panacea. A free architecture! But if every vendor adds their own extensions, you end up with the worst of both worlds. An open standard that nobody agrees on.

The RISC-V Foundation is trying to address this with standardized profiles like RVA twenty-three. These profiles define a mandatory baseline of instructions and extensions that all conforming processors must implement. The idea is that if your software targets the RVA twenty-three profile, it will run on any chip that claims compliance. It is the same approach Java tried with its "write once, run anywhere" promise, and we all know how perfectly that worked out. But the alternative, no standard at all, is clearly worse.

The December twenty twenty-five introduction of the US SAFE Act, the Secure and Feasible Export of Chips Act, adds another layer of complexity. If passed, it could restrict US companies from contributing advanced vector or matrix instructions to the global RISC-V standard if those contributions are deemed to benefit adversary nations. That could lead to a forking of the ISA itself, with one version used in the West and another developed in China. The open standard that was supposed to transcend geopolitics could itself become a geopolitical battleground.

What Would You Actually Do With One?

Let's get practical. You spin up a Scaleway RV1 server. You have four cores at one point eight five gigahertz, sixteen gigs of RAM, a hundred and twenty-eight gigs of eMMC storage, and a hundred megabit network connection. What can you actually do with this?

The honest answer: anything you would do on a conventional Linux server, just slower. Debian, Ubuntu, and Alpine are officially supported. Fedora was added later, along with Android twelve for the adventurous. About ninety-eight percent of Debian packages are now compatible with RISC-V. Web servers, databases, Git hosting, continuous integration, DNS servers, VPN endpoints, monitoring agents, all of it works.

The real use cases fall into a few buckets. First, CI/CD testing. If you are building software that you want to run on RISC-V, and the list of people doing that is growing fast, you need actual RISC-V hardware to test on. Cross-compilation catches most issues, but some bugs only show up on real silicon. Running your test suite on an RV1 as part of your pipeline is cheap insurance.

Second, exploration and education. If you are a computer science student or a systems programmer and you want to understand a processor architecture from the ground up, RISC-V is by far the most accessible. The ISA specification is a single readable document. The reference implementations are open source. You can trace execution from user space all the way down to individual instructions in a way that is practically impossible with x86 or ARM's labyrinth of legacy compatibility layers.

Third, edge computing prototyping. The power consumption profile of these chips, roughly one point three watts per core, makes them interesting for edge deployments where power budget matters more than raw throughput. If you are designing a system that will eventually run on RISC-V embedded hardware in the field, developing against real RISC-V servers in the cloud is much more convenient than managing physical development boards.

Fourth, and this is the nerdy one, it is just inherently cool. You are running bare metal on a processor architecture that barely existed as a product a few years ago, built by a French cloud company that hand-soldered the boards and 3D-printed the enclosures in a Paris basement. The serial console is exposed, so if you are feeling truly adventurous, you can install Arch Linux by hand through the bootloader. That is not a product feature. That is a dare.

The Six Hundred and Seventy-Two Server Rack

Let's zoom out to the density story one more time, because the numbers are genuinely remarkable. Six hundred and seventy-two independently addressable bare-metal servers in a single fifty-two-U rack. Each with its own IP address, its own operating system, its own network isolation. Drawing a combined total that is a fraction of what the same rack filled with x86 servers would consume.

Imagine a Kubernetes cluster running across an entire rack of these. Six hundred and seventy-two nodes. You could run legitimate distributed systems experiments at a scale that would normally require serious infrastructure investment. Want to test how your service mesh behaves with five hundred nodes? Want to simulate a geographically distributed microservices architecture? Want to stress-test a consensus algorithm? You have the hardware for it, at a price point that starts at about ten thousand seven hundred euros per month for the whole rack. That is absurd. In the good way.

The power story is equally compelling. Each clusterboard at fifty-five watts, eighty-four servers at six hundred and sixty watts total. A comparable density of x86 servers would draw roughly fifteen to twenty kilowatts for the same rack space. Scaleway's stated goal of sustainable cloud computing is not just marketing here. The physics actually supports the claim. Whether the compute-per-watt ratio makes business sense depends entirely on the workload, but for tasks that are parallel, network-heavy, and not CPU-bound, the economics could be genuinely interesting.

The Future in Transit

The RISC-V ecosystem is moving fast. The Sophgo SRA3-40, one of the first genuinely server-class RISC-V machines, is approaching commercial availability with proper UEFI boot support and ECC memory. Ubuntu now officially supports the RVA twenty-three profile. The RISC-V Data Center SIG, a working group within RISC-V International, is actively defining standards for RISC-V in datacenter environments, covering everything from boot sequences to management interfaces.

Scaleway's RV1 is a first step, and the company knows it. The servers sold out quickly after launch and they had to put more into production. They have added features like Flexible IP and Private Network support. They have made the serial console available for deep tinkering. And they have signaled clearly that this is not a one-off experiment. When the next generation of RISC-V SoCs arrives, with better performance, proper UEFI support, and the RVA twenty-three profile compliance, Scaleway will be one of the first to put them in the cloud.

The question is not whether RISC-V will matter. It already does. Billions of RISC-V cores ship every year in embedded applications, in SSDs, in network controllers, in IoT devices. The question is whether it will make the leap to general-purpose server computing, the way ARM did with Graviton at Amazon and Ampere Altra in the colo world. The gravitational pull of the open ISA is immense. No licensing fees. No single vendor controlling the roadmap. No export control chokepoints. Every major government and most major semiconductor companies are betting that the answer is yes.

And in the meantime, in a datacenter in Paris, there are racks of little handmade servers humming along at one point three watts per core. They were designed in a lab, printed on a 3D printer, soldered by hand, and booted over a PXE chain that someone had to debug instruction by instruction because the firmware did not exist yet. They cost less per month than a decent lunch in Paris. And they are, quietly, a tiny piece of what might turn out to be one of the most consequential technology shifts of this century. Not because of what they can compute today. But because of what their existence means for who gets to design the computers of tomorrow.