Appearance
How it works
When you install the Dataplicity agent on a Linux device, it establishes and maintains an outbound connection to Dataplicity. That connection supports more than Remote Shell: on qualified releases, your product application can publish selected values through an agent-local broker for OEM and customer product pages.
When you connect to remote shell or reach a web service through a Wormhole URL, traffic is routed between the browser and device through Dataplicity.
Outbound connections
The agent initiates the Dataplicity connection from the device. The Dataplicity access path does not require an inbound internet route to Remote Shell, RDP, or a device-hosted web service. This means:
- No port forwarding on customer routers
- No inbound firewall exception for Dataplicity access
- Restricted networks can allowlist the documented outbound destinations
- Portable devices reconnect automatically when they move between networks
Traffic is routed over encrypted WebSocket connections. Availability still depends on the device's network path, DNS, time configuration, and permitted outbound traffic.
Components
| Component | Role |
|---|---|
| Agent | Software installed on each Linux device. Maintains the outbound connection, device identity, and remote access. On installs that include the optional supervisor, it also runs Class Software and the local stream broker. |
| IoT Router | Dataplicity service that routes connections between your browser and devices. |
| Dashboard | Web interface for device list, remote shell, fleet management, logs, and monitors. |
| Device Class | Product definition for compatible software, streams, actions, settings, and customer layout. |
| Customer Portal | Branded, customer-separated application for assigned products and locations. |
| Local broker | Loopback boundary through which a compatible product process publishes class streams without a cloud API key. |
| Wormhole | Persistent outbound tunnel to a web service running on the device. |
| File retrieval | Resilient transfer for support artifacts. |
What this means in practice
You can access devices when the agent has a viable, authorised route to Dataplicity. NAT and dynamic public addressing do not require a per-device inbound rule because the agent connects outward.
The OEM workspace and Customer Portal use different authorisation boundaries. A portal user does not gain OEM Remote Shell, fleet-wide logs, or software rollout access.
Dataplicity hosts these SaaS surfaces and the device-operating connection. You keep the hardware, Linux, product application, local safety behaviour, customer contract, billing, and physical service lifecycle. See Customer lifecycle and automation for the complete boundary.
Related pages
- Dataplicity agent - on-device layout, requirements, and checks
- Security model - authentication, permissions, and production recommendations
- Firewall requirements - URLs and ports the agent needs
- Remote access - shell, Wormhole, and file retrieval
- Port forwarding compared - how this differs from traditional SSH setup
- Build your first connected product - prove the complete OEM-to-customer path
- Device data and control contract - implement the local product boundary