Unattended device RMM guide — kiosks, signage, industrial PCs
Store kiosks, digital signage in stations and hospitals, industrial PCs and PLC gateways on a factory floor — unattended devices need a different management style entirely. There's no one in front of the screen to ask for consent, so the job becomes bulk provisioning, remote command execution, and status monitoring instead. This guide covers building unattended device RMM (remote monitoring and management) behind CGNAT and firewalls, with no VPN.
How unattended fleet management differs from ordinary remote control
Kiosks, signage, and industrial PCs mostly need status checks and commands, more than someone watching a screen. A persistent RMM (remote monitoring and management) channel needs to stay open, continuously collecting telemetry — online/offline, disk/CPU load, running processes — and executing remote commands or pushing config/firmware when needed. Watching the screen directly is the fallback for when something's already gone wrong.
The core challenge — bulk provisioning
The moment a fleet passes a few dozen devices, configuring each one by hand breaks down. Pre-register the fleet from a console or CLI and issue a unique enrollment bundle (agent.json) per device; each device then flips awaiting → online automatically on first contact. At a scale of hundreds or thousands, the only manual step left is generating and distributing the bundles.
Crossing CGNAT and firewalls with no VPN
Store and factory-floor networks usually sit behind CGNAT or a firewall, and opening an inbound port often isn't an option. An unattended device's agent keeps an outbound-only connection to the coordinator; when an operator requests access, the two ends connect directly via hole-punch P2P where possible, or fall back automatically to a relay. There's no VPN tunnel or port-forwarding to configure, and devices on a home network or closed network are reachable this way — with the connection end-to-end encrypted (J-PAKE / AES-256-GCM) so even the relay server can't see the content.
Key features
📦 Bulk provisioning & enrollment
Pre-register a fleet from console/CLI and issue a per-device enrollment bundle. Auto-flips awaiting → online on first contact.
🛠️ Remote management (RMM)
Inventory and status, remote command execution, versioned config-push.
⬆️ File & firmware delivery
Chunked, resumable, SHA-256-verified, atomically applied — updates safe even for headless devices.
🖥️ Browser live screen
See and control the screen from a browser, no install — control, telemetry, and screen ride one connection.
🚨 Fleet monitor & alerts
Detect offline / low-disk / high-load transitions and alert via webhook / Slack early.
🔒 Self-hosted · data sovereignty
Run the connection servers and console yourself so screen, commands, and data never pass through an outside cloud.
An approach for every scale
| Scale / situation | Approach |
|---|---|
| Small-scale experiment / PoC | Prototype directly with ConnectKit + DeviceKit SDKs — starting with RPC and telemetry |
| Need to see the screen too | Mount SessionKit on DeviceKit's session sub-channel so control and screen ride one connection |
| Production at tens to thousands of devices | EdgeReach — an onboarded, on-prem solution with a provisioning CLI, central console, and web viewer |
EdgeReach packages these building blocks into an onboarded solution. Its agent runs on Windows, Linux, and macOS, with real screen capture and input injection verified on Linux and macOS, and it has passed a real-NAT field test connecting a home-network device to the cloud coordination server with no VPN.
Firmware and config rollout strategy
At a scale of hundreds to thousands of devices, a staged rollout is safer than pushing everything at once.
- Canary group — deploy to a slice of the fleet first (say, 5-10%) and watch its status.
- Version tagging — record which config / firmware version each device is running, so you can look up exactly what shipped if something goes wrong.
- Auto-halt thresholds — stop a rollout and investigate when signals like offline transitions or boot failures cross a threshold.
- Maintenance windows — schedule pushes outside store hours or signage operating hours.
Fleet monitoring and alerts that detect offline / low-disk / high-load transitions let you catch anomalies during a rollout right after they appear.
Frequently asked questions
How do I reach an unattended device behind CGNAT with no VPN?
The device's agent first opens an outbound connection to the coordinator (signaling server). When an operator
requests access, it connects directly via hole-punch P2P where possible, or falls back automatically to a
relay. Since the device never needs an inbound port open, it's reachable behind CGNAT and firewalls with no VPN
or port-forwarding.
How do I enroll hundreds to thousands of devices at once?
Pre-register the fleet from a console or CLI and issue a per-device enrollment bundle (agent.json). Distribute
the bundle and each device automatically flips from awaiting to online on first contact — no manual per-device
setup.
Won't a bad config or firmware push brick devices?
File and firmware delivery is chunked, resumable, SHA-256-verified, and applied atomically, which prevents a
partial or corrupted transfer from ever being applied. Even so, a staged rollout to a subset of devices before
a large push is the safer practice.
What if I need to see an unattended device's screen live?
You can view and control it straight from a browser, no install. ServerKit's web-viewer gateway terminates and
decodes the session on-prem and re-serves it to the browser, with control, telemetry, and screen riding one
connection.