RG versus cloud IoT¶
RG differs from generic cloud-IoT device management in what hardware it manages and where it keeps running. Cloud-IoT platforms manage devices built on their SDK and depend on the cloud being reachable; RG manages existing and legacy hardware with no firmware SDK integration, via adapters and tunneled native GUI, on autonomous clusters that survive cloud outages and run air-gapped. Hyperscaler IoT fits greenfield fleets built on its SDK at massive scale.
Comparison at a glance¶
| Dimension | Generic cloud IoT | RG Platform |
|---|---|---|
| Existing/legacy hardware | Needs an agent/SDK compiled into device firmware | Adapter speaks the device's native API; tunneled native GUI covers the rest |
| Cloud-outage behavior | Control plane is cloud-dependent | Regional clusters are autonomous; operation continues without the cloud |
| Air-gap support | Generally not a first-class mode | Air-gapped cluster is a first-class deployment |
| Native GUI tunneling | Not typically offered | Device's own dashboard tunneled, permissioned, and audited |
| Multi-tenancy for MSPs | Account-oriented, not device-fleet delegation | Enforced tenant isolation plus two-tier RBAC on shared clusters |
Working with hardware that has no SDK¶
The sharpest difference is what it takes to onboard a device. Cloud-IoT platforms generally require a vendor to embed the platform's agent or SDK into device firmware, which works for devices designed for that platform and is a non-starter for hardware already in the field, closed appliances, or legacy equipment you can't reflash. RG takes the opposite approach: an adapter speaks the device's existing native API, and where the API doesn't cover something, tunneled native GUI access reaches the device's own dashboard. Nothing needs to be compiled into the device. This is why RG manages the mixed, aging, multi-vendor fleets that hyperscaler IoT can't — it meets devices where they are instead of requiring them to be rebuilt.
Cloud-outage behavior and air gaps¶
Cloud-IoT device management typically places the control plane in the cloud, so when the cloud is unreachable, device control degrades or stops. RG's regional clusters are autonomous: identity, pairing, channels, configuration, adapters, RBAC, and audit are all local, so a cluster keeps operating through a cloud outage and the cloud is never on the device data path. RG extends the same architecture to a fully air-gapped deployment — a first-class mode with local identity, RBAC, and audit and zero external connectivity — which cloud-dependent platforms generally can't offer at all. For operators who must keep running when the internet doesn't, or who are barred from the internet entirely, this is a categorical difference rather than a tuning knob.
Where hyperscaler IoT fits¶
This comparison is not a claim that RG replaces cloud IoT everywhere. Hyperscaler IoT platforms fit greenfield fleets of devices built on their SDKs at massive scale — millions of purpose-built endpoints designed from day one around the platform's messaging, provisioning, and data pipeline, feeding cloud analytics in the same ecosystem. If you are designing new devices and can standardize on a hyperscaler's SDK and services, that integration is deep and scales enormously. RG's strength is the opposite quadrant: existing, heterogeneous, hard-to-reach hardware that was never built for any single platform, managed uniformly without touching firmware and without depending on the cloud to stay reachable.