The Raspberry Pi, from the bedroom to the factory floor

If you were a child in Britain in the 1980s there was a fair chance a beige computer arrived in your bedroom, or your classroom, and changed what you did with your evenings. The BBC Micro, the ZX Spectrum, the Commodore 64 and the Amiga did not just play games. They booted into a prompt that expected you to type something, and a generation of engineers started there.

By the 2000s that had gone. Computers were sealed appliances. Eben Upton, then teaching computer science at Cambridge, saw applicants arriving with far less programming experience than a decade earlier, and set out to build something that would do for them what the BBC Micro had done for him (Raspberry Pi, November 2021). The first Raspberry Pi went on sale on 29 February 2012 at $35, and the distributors’ websites fell over under the demand. The Model A and Model B names were a deliberate nod to the BBC Micro.

Nobody involved expected what came next. By February 2016 it had overtaken the ZX Spectrum as Britain’s best-selling computer. As of March 2026 more than 75 million have been sold (Wikipedia, Raspberry Pi Holdings FY2025 results).

The quiet shift to industry

The bit of the story that gets less attention is where those boards went. In 2014 Raspberry Pi launched the Compute Module: the same computer, on a small board with no connectors, made to be designed into other people’s products. Industrial and embedded customers became the largest market. Today the Pi is inside signage, vending, test equipment, medical devices, building controls and a great many machines whose users never know there is a Pi in there.

A lot of those products, though, were designed around the consumer board. It was available, it was cheap, and it worked. That means a great many commercial machines in the field today boot from a removable microSD card in a consumer Raspberry Pi, and carry the consequences: the card wears out, it can be pulled and copied, the software on it can be swapped, and the only way to service it is a visit with a new card.

We know this world well. It is where our ASTRID tools started: reading the health of the card in the machine before it fails, verifying the image on it, writing a known-good replacement, and proving all of it with a record. The removable card is a weakness that ASTRID turns into a service.

What the Compute Module changes

The Compute Module 4, launched in 2020, and the Compute Module 5 in 2024 are a different proposition. They are offered with 16, 32 or 64 gigabytes of eMMC storage soldered to the board, alongside the “Lite” versions that still take a card (Raspberry Pi documentation). With storage on the module there is nothing to pull out, nothing to lose and nothing to copy in a car park.

They also support signed boot. The module can be set, once and permanently, to run only software signed with the manufacturer’s key. Raspberry Pi’s own tooling warns that enabling it “modifies the OTP memory and is irreversible” (Raspberry Pi usbboot), which is exactly the point: a machine in the field cannot be made to run something else.

For a manufacturer, moving a product from a consumer Pi to a Compute Module with eMMC and signed boot is a real security upgrade. It also changes the service model, because the storage that used to be a card you could swap in the field is now part of the board.

Provisioning becomes the job

A module with soldered storage has to be written before it is fitted, and re-written when the software changes. Raspberry Pi provides the mechanism: put the module into boot mode over USB and it presents its eMMC as a drive. The process is well documented and entirely manual. At one module on a bench it is fine. At a hundred, or in a hospital corridor with a machine open, it is not.

This is what the newest ASTRID capability does. An engineer connects the module, or the machine’s service port, to ASTRID. It identifies the board by its serial, checks that what it is about to write is the signed image the manufacturer released, writes and verifies it, and reads the eMMC’s own health registers so the record shows how much life the storage had at the time. The same write gate that protects a card applies to the module: it will not write to anything it has not positively identified.

The same tool works in three places:

• In the field. Service a machine’s storage in place, with the record sent home before the panel goes back on.
• In your factory. Provision modules at build time from the released image, with a passport per board.
• Before they reach you. We can pre-image modules against your signed release and ship them ready to fit, so the storage in your product has a documented history from the day it left us.

That last one is the part we think matters most. A supply chain is only as trusted as its least documented step, and for a great many products the storage is that step. A card bought from a marketplace, written on a laptop, fitted by whoever was available: nobody can say afterwards what was on it or where it came from. A module written from a signed release by a tool that records what it did, with the eMMC health read at the same time, is a different thing. It is a part with a passport.

Where this goes

The Pi that began as a way to get children typing at a prompt is now serious industrial hardware, and the Compute Module is where that seriousness lives. The removable card is not going away overnight, and ASTRID will keep reading, wiping and writing cards for as long as machines use them. But the direction is clear, and we have built for it. If your product runs on a Pi, in any of its forms, we would like to talk about how its storage is provisioned, and how you would prove it.

The ASTRID range covers both. Our supported media page lists what we read on eMMC as well as cards.