When Raspberry Pi Strands Production (And When It Doesn't)
Consumer single-board computers accelerate prototypes and kill field deployments. The honest case for when to ship one, and when to migrate.
A working prototype on a Raspberry Pi is not a problem. A fleet of ten thousand products in the field still running on a Raspberry Pi, four years after shipping, is often the problem the company did not know it was building.
The question from a founder with a demo that works is usually “can we ship on this?” That is the wrong question. The right one is should we ship on this, for this product, at this volume, in this environment, under this service horizon. Teams that get it wrong get it wrong in the same direction — they keep the prototype architecture into production and discover the cost at scale, where it is ten to twenty times higher than at EVT.
”Raspberry Pi in production” is not a verdict. It is a decision. The Compute Module line legitimately ships in commercial products today. The consumer Model B boards almost never should. The gap between those two statements is where most of the engineering judgment lives — and where most teams skip it.
The Raspberry Pi question: not “can it” but “should it”
The Raspberry Pi is an extraordinary piece of engineering — a quad-core ARM system with a mature Linux stack and a unit cost a startup can afford. This is why every hardware founder has one on the bench. None of that answers whether it belongs in a product. “Works on the bench” and “survives a fleet” are different criteria. Clearing the first tells you nothing about whether you clear the second.
When Raspberry Pi is the right answer (legitimately)
There is a real set of products where a Pi — almost always a Compute Module 4 or CM5, rarely a consumer Model B — is the correct production choice. The pattern is consistent: moderate volume, controlled environment, no hard real-time requirement at the application layer, a service horizon inside the Foundation’s EOL, and a product where Linux is a feature, not a concession.
The Pi ships well in:
- Indoor commercial products at sub-10k/year volume — digital signage, lab instruments, kiosks, HMIs.
- Edge compute appliances where the value is a Linux application, not the physical interface to the world.
- Products using the Compute Module form factor — a custom carrier PCB with the connectors and protection your product needs. Different engineering from “put a Pi 4 in a box.”
- Products with a three-to-seven year service life where CM4’s 2034 horizon is comfortably past retirement.
In these cases the Pi is not a compromise. An industrial alternative would be over-specified.
When it’s a trap
The trap is the space where the prototype works, the team says “it’s just software from here,” and nobody re-evaluates the compute platform against production constraints until the first real units are in the field. The failure modes are boring and repeatable.
Thermal. The Pi 4 throttles at around 80°C junction. In a sealed enclosure at 40°C ambient with moderate load, the SoC hits that temperature inside minutes. Throttling does not burn the board out — it silently redefines performance. Control loops miss deadlines. Video pipelines drop frames. Behavior that was deterministic on the bench becomes load-dependent in the field.
Deterministic timing. Linux on a Pi is not a real-time operating system. PREEMPT_RT helps; it does not turn a shared cache, memory controller, and scheduler into a deterministic hard real-time system. For motor commutation, safety interlocks, or any loop that cannot tolerate a thirty-millisecond jitter spike, the Pi is the wrong place to run it — not because it “usually works” but because the day it doesn’t, a motor destroys itself or a person gets hurt.
End of life. The Foundation commits Pi 4 and CM4 availability to January 2034, newer parts into 2036. That sounds generous until you remember a product shipping today is serviced for ten or fifteen years. EOL means a full redesign cycle at the last-time-buy window.
Certification. A board that passes emissions on a bench does not mean your product passes in its enclosure with its cable harness. The Foundation’s CE/FCC data is a reference; your product still goes through the chamber. The Pi’s RF behavior around WiFi/BT and the display cable is a known source of certification pain that industrial SoMs with proper shielding have already solved.
Environmental and mechanical. Consumer Pi boards are not designed for vibration, shock, conformal coating, wide-temperature operation, or industrial connectors. The MicroSD card is the most common field failure in Pi-based products. Flash wear under sustained logging is measured in months, not years.
Supply. The 2021–2023 Pi shortage is instructive. Teams committed architecturally to the Pi, without a second source, spent a year reverse-engineering around the part they could not buy.
Individually these are survivable. Stacked across ten thousand units in thirty countries, they compound into a reliability problem cheaper to prevent than to fix.
The migration we did at Aerones
At Aerones, the production fleet — robots servicing ten thousand turbines a year across twenty-seven countries, outdoors at a hundred meters in crosswinds, rain, and sub-zero temperatures — ran critical subsystems on Raspberry Pi boards. Motor control. Sensor fusion. Safety interlocks. For the early commercial phase, this worked.
It stopped being the right architecture at scale — not because the Pi “failed” dramatically, but because the compound of thermal, timing, EOL, and environmental exposure across a growing fleet was a reliability liability the business could not carry. When a robot strands at 120 meters in a North Sea crosswind, the cost is a crane deployment, a missed weather window, and a six-figure recovery bill.
The migration was to Beckhoff industrial controllers — not as a drop-in swap, but as a rearchitecture. The important decisions were about which functions needed hard real-time determinism — motor commutation, safety interlocks, winch tension regulation — and which could remain supervisory — mission planning, telemetry, remote operations, vision processing. Hard real-time ran on Beckhoff. Supervisory ran on industrial Linux compute with proper thermal, mechanical, and EOL characteristics. Industrial fieldbus between them with deterministic latency. Graceful degradation defined at every interface — what fails to safe, what fails to degraded operation, what stops the robot, what triggers a controlled descent.
The fleet kept servicing turbines through the migration. That is what this work looks like under pressure, on a revenue-generating platform, instead of at EVT for a tenth of the cost.
How to decide during prototype, before migration under pressure
For every prototype architecture that includes a consumer SBC, before freezing at EVT, answer these honestly:
- Volume. At what point does the per-unit cost delta between a CM4 and an industrial SoM stop mattering relative to the cost of one field failure?
- Environment. What is the actual thermal envelope — measured, not assumed — with the board inside the real enclosure?
- Timing. Does the product have a control loop, safety function, or signal path that cannot tolerate non-deterministic jitter? If yes, that function should not run on the SBC — regardless of which SBC.
- Service horizon. Is the SBC’s EOL comfortably past the product’s service life, with margin for a last-time-buy?
- Certification. Have you looked at RF, safety, and environmental requirements against the SBC’s documented performance in your enclosure?
- Failure cost. What does a field failure cost — in dollars, safety, reputation? A consumer warranty swap, or a crane, a flight, a patient?
If the answers converge on the Pi being appropriate, ship it. If any one flags, move architecture now — at EVT, before firmware, enclosure, and test strategy are built around the wrong platform.
Industrial alternatives by failure mode
There is no single “industrial Pi.” There is a set of platforms, each addressing a different failure mode. The right choice depends on which mode is load-bearing.
The pattern that generalizes: split the architecture. Put hard real-time and safety-critical functions on a platform engineered for them — an MCU, an FPGA, or an industrial controller. Put application, UI, connectivity, and supervisory functions on the Linux platform that fits volume, environment, and service horizon. The Pi can be the supervisory side in the right product. It should rarely be the hard real-time side in any product.
Related reading
- From Prototype to Production
- Embedded Systems Development: A Systems Discipline
- Why Hardware Projects Overrun by 12+ Months
- Aerones
Prototype running on a Pi and not sure whether it should ship on one?
We do this analysis — volume, environment, timing, EOL, certification, failure cost — as a fixed-scope engagement, and tell you honestly whether to keep the architecture or migrate. No open-ended billing. No ambiguous timelines.
Start a Conversation