Raspberry Pi in production: what changes
A Pi on your desk and a Pi in a cabinet in a warehouse two provinces away are different engineering problems. Here is what has to change between them.
The Raspberry Pi is a genuinely good production computer, and it is also the single easiest way to build something that works beautifully on a bench and fails quietly in the field. The gap is entirely operational.
SD cards die
This is the number one cause of dead deployed Pis. Cheap cards fail within months under constant logging.
- Use industrial-grade storage, or boot from USB or eMMC
- Mount the root filesystem read-only where you can
- Send logs off-device rather than writing them locally
- Move `/var/log` and any scratch space to tmpfs
Power is not clean
Field power is noisy and gets cut without warning. Undervoltage causes corruption that looks like random software bugs, and you will spend a week chasing the wrong thing.
Specify a proper supply, monitor the undervoltage flag and report it as telemetry, and design every write to be safe against sudden loss.
You cannot plug in a keyboard
Everything you do on the bench with a monitor has to have a remote equivalent: logs, health, config changes, recovery. A watchdog that reboots a wedged device is not optional.
Builds must be reproducible
"I set it up by hand and it works" does not scale past one. Image the device with Yocto, Buildroot or at minimum a scripted provisioning process, so the hundredth unit is identical to the first and so a replacement can be built in an hour.
Updates need a path home
Plan the over-the-air update mechanism before the first deployment, not after. Retrofitting updates onto a fleet you cannot reach is the most expensive lesson in embedded work, and everyone learns it exactly once.