Frequently asked questions¶
Direct answers to the questions operators and integrators ask first about RemoteGenius (RG Platform). Each answer leads with the bottom line.
Does RemoteGenius require port forwarding or a public IP?¶
No. RG never needs port forwarding, UPnP, a public IP, or a DMZ. Every connection is initiated by the device, outward, to its cluster — the platform accepts nothing inbound at the edge. The only thing a site owner allows is a single outbound encrypted connection from the device. Because reachability rides that outbound channel, a device becomes manageable from wherever it sits without any inbound network change.
Does it work behind CGNAT or cellular?¶
Yes. CGNAT and cellular networks deny devices a publicly reachable address, which defeats any inbound-based remote access. RG doesn't need one: the device dials out to its cluster and holds the channel open, so it works behind CGNAT, cellular, and firewalls the operator doesn't administer. When the link drops, the device reconnects on its own with backoff, so intermittent mobile connectivity self-heals rather than requiring intervention.
Can it manage devices from different vendors?¶
Yes — mixed-vendor and mixed-firmware fleets are the norm, not an exception. Each device is represented by a canonical, vendor-neutral device shadow, and a per-device adapter translates that shadow to and from the device's native API. The adapter is selected by vendor, model, and firmware, so different generations of hardware stay managed together. Operators work with one uniform schema across unrelated hardware, which is what makes bulk changes and drift detection possible fleet-wide.
What if my device has no API?¶
It's still managed. A device with no usable API is brought in through an RG Bridge in appliance form factor — a standalone Linux device that fronts the hardware over Ethernet and tunnels its services. If the device has a web dashboard, that dashboard is reachable through tunneled native GUI access. There is no "unsupported" tier: fully integrated, partially integrated, and non-integrated devices all sit under one control surface.
Can it run fully offline or air-gapped?¶
Yes. An air-gapped cluster is a first-class mode, not a degraded fallback. It runs with local identity, local RBAC, and local audit, delivering full device management with zero external connectivity. If it is ever reconnected, it reconciles safely, and it can export its audit on demand. Everything you do on a connected cluster — pairing, control, monitoring, audit — you do on an air-gapped one, entirely within your boundary.
What happens if the cloud is unreachable?¶
The fleet keeps running. RG clusters are autonomous regional execution planes: identity, pairing, channels, configuration, adapters, telemetry, RBAC, and audit are all local to the cluster. The cloud is a global control plane for accounts and cluster registry and sits on no device data path, so a cloud outage doesn't sever devices from their cluster. During an outage, only new cross-cluster sign-in and registry changes pause; existing cluster-scoped credentials keep working until they expire.
How is access controlled per customer on a shared cluster?¶
Through two-tier RBAC plus enforced tenant isolation. Every authorization decision combines an organization-scope role with an optional per-cluster override, resolved per request, so a customer's users get authority over only their own fleet. Tenant isolation is enforced at the query, allocation, and audit layers — not the UI — and cross-tenant lookups return "not found", so one customer can't even detect another's resources. A provider can delegate scoped control to each customer on the same shared cluster.
What gets audited?¶
The consequential actions: authentications, permission changes, pairing approvals, configuration changes, adapter invocations, firmware upgrades, native-GUI access, credential issuance and revocation, and secret access. Each event carries actor, target, outcome, source, and a correlation identifier; configuration changes also carry before/after metadata. Audit writes are transactional with the action, so the record is authoritative. High-frequency heartbeat and telemetry are deliberately excluded so the trail stays investigation-grade rather than buried in noise.
How are devices paired securely?¶
With no pre-shared secret. Pairing combines a short-lived, operator-visible code with a fresh asymmetric key the device generates itself. The code is useless without explicit operator approval, and the device's private key never leaves the device — it becomes the permanent trust anchor and is valid only on that cluster. Per-serial lockouts and rate limits defeat brute force and enumeration, and the credential bundle is delivered atomically, so pairing either completes fully or leaves the device cleanly un-provisioned.
Is device traffic exposed to the internet?¶
No. Devices accept no inbound connections and hold no public address, so there's no listening port or exposed service to reach from the internet. Device traffic — control, native GUI, telemetry, and media preview — travels only inside the encrypted reverse channel the device opened to its cluster. Even a device's own web GUI is reachable solely through that tunnel and only to RG-authorized users, so the device's zero-inbound posture is preserved end to end.
Can it show live video from a camera or encoder?¶
For media-capable devices, yes. An operator can view low-latency live video in the browser with no extra connection to the device: preview reuses the device's existing control tunnel, a cluster-side media relay ingests the device's native stream and republishes it as WHEP, and the browser renders it over WebRTC. It inherits the device's tenant scope and permissions, adds no inbound exposure, and follows the device on node failover. Devices without a media stream simply don't use this path.
What deployment options are available?¶
Three orthogonal dimensions you combine freely: hosting (cloud-hosted or on-premises), connectivity (connected or air-gapped), and tenancy (shared or private). Any combination is valid — for example an on-premises, air-gapped, private cluster, or a cloud-hosted, connected, shared one. One organization can run several combinations at once under the same identities and permission model, so hosting, security posture, and customer separation are each chosen independently for their own reasons.
How much does RemoteGenius cost?¶
Pricing has two parts: a per-managed-device subscription and, when you use RemoteGenius-provided cloud, the underlying cloud infrastructure cost. The per-device subscription scales with the number of devices you manage, and on-premises or air-gapped deployments change the infrastructure component because you host the cluster yourself. For a current quote against your device count and deployment model, contact RemoteGenius — the exact figures depend on scale and hosting choices.
Does it work with legacy hardware?¶
Yes — legacy hardware is a core use case. Devices don't need any agent or SDK compiled into their firmware. An adapter speaks whatever native API the device already has, tunneled native GUI access reaches its existing web dashboard for anything the API doesn't cover, and hardware with neither is fronted by an appliance bridge over Ethernet. This is the main difference from cloud-IoT platforms that require devices to be built on their SDK: RG meets aging hardware where it is.