Until now, the gateway in my reference IoT setup has been running on my MacBook laptop and a dedicated Dell Linux Debian machine. That was the right choice in the early phase. It made development faster, simplified debugging, and helped me get the first end-to-end device-to-gateway flow working without adding unnecessary operational complexity too early.
As the setup evolves, that tradeoff starts to change.
Moving the gateway to a Raspberry Pi 5 is not about hardware for hardware’s sake. It is about moving the gateway closer to the kind of environment it is actually meant to run in: a dedicated edge node rather than a general-purpose development machine.
Evolving my gateway from running on a development laptop to a Raspberry Pi 5
In early-stage IoT work, running gateway services on a laptop is often the right decision. You get easy access to logs, shell tools, IDE workflows, and quick iteration when the priority is to get the system working end to end.
That is exactly how I approached the first development phase for this gateway setup. The gateway setup consists of a Rust-based ingest path for device telemetry with durable storage and acts as a boundary between edge and cloud - the full architecture I described in my earlier Rust IoT gateway blog post.
But a laptop is still a development convenience. It smooths over a number of conditions that matter later:
- Boot sequencing and startup dependencies
- Restart behavior after power loss
- Resource and runtime constraints
- Recovery after intermittent connectivity
- What “always-on” actually means in practice
I did not rush straight into running the gateway on dedicated edge IoT hardware on a Raspberry Pi with “stricter” constraints for compute, storage, network and power.
When the gateway was working end-to-end and was stable enough to run on it’s own, I moved it from my development laptop to a dedicated Dell Linux Debian machine. This forced me to run the gateway on a separate computer with plenty of compute and storage in the early development phase without too many constraints.
I could then focus on working with the operational conditions by maturing the code base for production and instrument the gateway with observability for faster troubleshooting and root cause analysis. You can read more about this in my blog post about Operational lessons from running an edge IoT gateway 24/7.
Operating the gateway 24/7 on a dedicated general purpose machine gave me some good experience on what breaks when running a gateway and device in production, and allowed me to practice the whole software development life cycle from device to gateway to cloud before diving into constraints running it on dedicated edge IoT hardware like a Raspberry Pi 5.
What changes when an IoT gateway runs on dedicated edge hardware
A dedicated gateway platform changes the engineering questions in useful ways.
It becomes possible to validate boot behavior, restart handling, resource usage, network recovery, and local runtime assumptions on hardware that is much closer to a real edge environment. That matters when the goal is not only to prove that telemetry flows, but to build confidence that the system behaves well outside the development setup.
This is also where weaker assumptions start to show up faster. A development laptop can hide fragility because it is powerful, interactive, and easy to inspect. A dedicated node forces more realistic thinking about failure, recovery, and operational discipline.
Why Raspberry Pi 5 makes sense for this stage of IoT development
Raspberry Pi 5 is a strong fit for this next step. It provides enough performance for gateway workloads while keeping the setup small, affordable, and practical to deploy. For this kind of reference architecture, that matters more than raw compute.
I want a platform that is realistic enough to behave like edge hardware, simple enough to leave running continuously, and accessible enough to use as the baseline for repeatable testing and demos.
The Raspberry Pi 5 kit for the next gateway migration step, including case, power, and storage.
The point is not to create a lab full of hardware. The point is to move one important runtime component into a form factor that better reflects real edge conditions.
Why separating the gateway from the development machine matters
This transition also improves the structure of the setup itself. The development machine can stay focused on coding, testing, and analysis, while the gateway becomes an independent runtime component.
That separation is useful both technically and operationally:
- Demos become easier to reproduce
- Failure and recovery testing becomes more realistic
- Runtime behavior is less coupled to the developer workflow
- It creates a cleaner path toward unattended or field-style operation
This is a small architecture shift, but it makes the setup much easier to reason about.
How Raspberry Pi 5 supports the audit engine and multi-device roadmap
This move also strengthens the rest of the Combotto stack.
The Combotto Audit Engine becomes more useful when it is evaluating a gateway running on dedicated edge IoT hardware, because the evidence is closer to the environment that actually matters in production. Boot behavior, restart recovery, local buffering, and connectivity loss all become more meaningful when they happen on an always-on edge node instead of a dev machine.
It also creates a better foundation for the next step I want to test: scaling the gateway from one to three devices. Once the gateway is setup on a Raspberry Pi, it becomes much easier to observe multi-device behavior on edge IoT hardware in the field, intermittent connectivity, and per-device evidence quality without everything being collapsed into a single dedicated workstation.
What I want to validate next on Raspberry Pi 5
With the gateway running on dedicated IoT edge hardware, these are the questions I care about next:
- How the system behaves after power loss or forced restart
- How local buffering handles short network interruptions
- What recovery looks like when the broker or upstream path disappears
- How observability works on a smaller always-on node
- Which assumptions in the current setup only hold because a laptop was doing the work
Those are the kinds of questions that move a setup from “works in development” toward “behaves predictably as an edge system.”
This is more than a Raspberry Pi 5 hardware swap
So this is more than a hardware upgrade. It is a maturity step for the gateway.
The platform is moving from a development-friendly host into something that more closely resembles an operational edge system. That is where the next useful lessons are, especially around reliability, recovery, and auditability.
I will share more as the migration progresses and as the setup expands into broader multi-device testing.