The Raspberry Pi Made Me Love Computers Again
Contents
I spent a chunk of my career deep enough in cloud infrastructure that “the computer” became an abstraction with a billing dashboard attached to it: instances and regions, standing in for machines and rooms I would never actually see. It is genuinely useful work and I don’t regret any of it, but somewhere in there I stopped being curious about the hardware, because there was no hardware in front of me to be curious about — just an API call that provisioned something in a data centre I would never see, running on a CPU generation I could look up but never touch.
A Raspberry Pi undid that, almost by accident. I bought one to run Pi-hole because it was the cheapest always-on box that would do the job, and ended up rediscovering that computers are physical objects with real, visible constraints, and that those constraints are more interesting to design around than infinite cloud elasticity ever was.
Constraints are the whole appeal
A Raspberry Pi gives you a fixed, small amount of everything: a handful of watts of power budget, a CPU that will thermal-throttle if you push it, RAM measured in single-digit gigabytes even on the current top-end model, and storage that is either a microSD card with a real, well-documented write-endurance ceiling or a somewhat more robust NVMe drive on the models that support it. None of that is a limitation you route around with a bigger instance type. You have to actually think about what you are asking the machine to do, at a level of specificity that cloud infrastructure lets you skip entirely.
That specificity is what made me enjoy infrastructure again. Deciding whether a workload genuinely needs a database server or can run happily on SQLite is a more interesting question when the answer changes whether your fanless board throttles under load. Deciding whether to log to disk at all, given a microSD card’s write-cycle budget, forces you to actually think about log verbosity and retention rather than reflexively logging everything because storage is “free.” Every decision has a physically felt consequence, on a machine you can pick up and hold, and that immediacy is something a cloud console never gave me no matter how good its metrics dashboard was.
What actually runs well on a board this small
The honest answer is more than people expect, provided you pick workloads that match the constraint rather than fight it. Pi-hole and AdGuard Home are the obvious starting point — DNS filtering is I/O-light and memory-light, and a Pi handles a household’s query volume without breaking a sweat. From there, a genuinely capable home server stack fits on a single board: I run K3s on a Raspberry Pi cluster for a handful of small services, which sounds like overkill for the hardware until you realise K3s was specifically built to be light enough for exactly this — a stripped-down Kubernetes distribution that drops the components a homelab has no use for and still gives you the declarative deployment model without a proper data-centre’s worth of hardware behind it.
Voice and audio workloads are the surprising one. Running Whisper for local speech-to-text on a Pi sounds implausible for anything that has a reputation as GPU-hungry, but the smaller Whisper model sizes trade a little accuracy for a footprint that a Pi’s ARM cores handle in a reasonable time for short home-automation utterances, which is a genuinely different use case from transcribing an hour of audio and does not need the larger models at all. A cluster of them running Home Assistant, similarly, can get remarkably close to continuous, dependable uptime for a fraction of what a proper redundant server setup would cost, provided you actually design the cluster for failover rather than assuming a single board never falls over.
Why the Pi is not always the right board
I want to be honest about where the enthusiasm runs out, because the homelab internet oversells the Pi for jobs a slightly different board handles better. Anything genuinely disk-throughput-bound — a NAS serving several simultaneous 4K streams, a backup target absorbing large nightly transfers — runs into the Pi’s shared USB/SATA bandwidth ceiling in a way that a proper SATA or NVMe-native x86 mini PC avoids entirely, and the honest conclusion after putting a Pi through that kind of workload is that an x86 board’s native storage bus gives it a real edge for anything storage-heavy, at a modest premium in price and power draw, while the Pi wins decisively on ecosystem, GPIO access, and the sheer volume of tutorials and pre-built images available for anything hobbyist-adjacent.
That trade-off is worth taking seriously rather than reflexively defaulting to whichever board is more fashionable this year. If the workload is compute-and-memory-bound and low-throughput — DNS, a small web app, a Git server for a household, a Home Assistant instance — the Pi’s ecosystem advantage wins outright. If it is storage-throughput-bound, pay the small premium for a board with a real storage bus.
The ecosystem is the actual product
The board itself is a commodity ARM single-board computer at this point, and several competitors match or beat its raw specifications for similar money. What the Pi Foundation actually sells, whether they frame it this way or not, is the ecosystem sitting on top of the board: Raspberry Pi OS images tuned specifically for the hardware, a community large enough that almost any error message you hit has already been asked and answered somewhere, and a first-party HAT (Hardware Attached on Top) standard that means an add-on board for sensors, displays or power management just physically fits and is electrically compatible without you needing to check pin compatibility yourself.
That ecosystem advantage is easy to underrate until you are debugging a genuinely obscure problem at midnight and discover that a competing board’s community is a fraction of the size, its documentation assumes more prior knowledge, and the specific error you are hitting has one forum post from three years ago with no reply. The Pi’s dominance in this space is partly inertia, but inertia in an ecosystem is a real and durable advantage, not a hollow one — it compounds every time someone else hits the same wall you did and writes up the fix.
Troubleshooting the Pi-specific failure modes
Undervoltage is the failure mode unique to this hardware that catches almost everyone at least once. A Pi drawing more current under load than a marginal USB power supply or a too-thin cable can deliver will throttle its CPU clock silently, and the only visible symptom is a service that gets inexplicably slow under load with nothing in its own logs to explain why. vcgencmd get_throttled returns a bitmask that tells you definitively whether undervoltage has happened, currently or historically, and it is the very first thing to check before assuming a software bug:
| |
A non-zero result after the 0x means undervoltage or throttling has occurred at some point since boot; decode the bitmask against the documented flag meanings to see whether it is a historical blip or an ongoing condition. The fix is almost always a proper official power supply rather than whatever 5V USB charger happened to be in a drawer, because the current delivery under sustained load is where cheap supplies fall short, not the voltage at idle.
SD card corruption after a power loss is the second Pi-specific gremlin, and it is really a Pi-flavoured version of the same “USB storage doesn’t survive a brownout” problem I have written about with mini PCs generally, made worse by microSD cards being cheaper and more failure-prone than a proper SSD to begin with. Booting from a USB SSD instead of the microSD slot, where the board supports it, removes most of this risk at a small cost in setup complexity, and is worth doing for anything you actually depend on rather than a weekend experiment.
Network throughput disappointing you on the older models is usually not a bug either — the Pi 3 and earlier share the Ethernet port’s bandwidth with the same USB bus everything else hangs off, so heavy USB storage traffic and Ethernet traffic genuinely compete for the same underlying interface. The Pi 4 onward moved to a proper independent Gigabit path, which is a real and meaningful upgrade if your workload pushes real network throughput rather than the DNS-query-sized traffic Pi-hole generates.
Overheating under sustained CPU load is the last one worth calling out specifically, because it interacts badly with the undervoltage problem above rather than being independent of it — a board running hot enough to throttle is also drawing more current at that clock speed than a cooler board would, and a marginal power supply that was fine at idle can start showing undervoltage flags once thermal throttling and current draw compound each other under a sustained compile job or a busy Kubernetes node. A basic heatsink and case with passive airflow resolves this for most workloads; anything genuinely CPU-bound for extended periods benefits from an active fan, which the official cases increasingly include by default for exactly this reason.
GPIO is the part cloud infrastructure can never give you
Everything above is about the Pi as a small, cheap server, and that alone would justify owning one. The GPIO header is the part that has no equivalent anywhere in the cloud infrastructure I spent years working with, because it is a direct, physical connection between software and the world outside the case. A temperature sensor wired to a couple of GPIO pins, read by a short Python script, feeding a value into Home Assistant is a genuinely different category of project from anything running in a data centre, because the feedback loop closes in the real room you are sitting in rather than in a dashboard three abstraction layers removed from anything physical.
I built a fairly basic garage door sensor this way — a reed switch, two GPIO pins, and a script polling the pin state every few seconds — and the satisfaction of that tiny project outstripped almost anything I shipped in a professional context that quarter, which says more about how removed cloud work had become from anything tangible than it does about the project’s actual sophistication. It is a magnetic switch and a polling loop. It is also the first time in years I built something where I could point at the actual physical mechanism making the software’s claim true, rather than trusting an abstraction several layers down that I had long since stopped being able to picture concretely.
That physicality changes how you debug too. A cloud instance that misbehaves gives you logs and metrics and not much else — the actual machine is unreachable by design. A Pi that misbehaves is on your desk, and you can measure its supply voltage with a multimeter, watch its power LED for the specific blink pattern that indicates a boot failure, or just physically reseat a cable that has worked itself loose. Half of the debugging skills I had let atrophy during the cloud years came back within a month of running real hardware I could hold.
Is it worth building a homelab around
For the low-power, always-on, unglamorous services that make a homelab actually useful day to day — DNS, a small dashboard, a Home Assistant hub, a lightweight Git remote — completely, and the ecosystem around the Pi specifically (images, community troubleshooting, GPIO projects) makes it worth the small performance concessions versus a same-priced x86 alternative. For anything storage-throughput-heavy, look elsewhere first and don’t let brand loyalty talk you out of the board that actually fits the job. What the Pi gave me back was not raw capability, which a cheap mini PC will comfortably beat on every metric that matters for a server. It was the reminder that a computer is a physical object with a power budget and a thermal envelope, and that designing around those limits honestly is a more interesting problem than provisioning yet another instance and forgetting it exists until the bill arrives.
Related Content
