Appearance
How it works #
When you install Dataplicity on a Linux device, the on-device architecture depends on the agent generation and install mode. A modern installation separates the rescue path used for identity and remote access from the optional supervisor used for product data and desired-state work. The legacy agent keeps the established remote-access path for existing fleets.
Start with Choose the right agent path if you are building, operating, or supporting the device. The rest of this page explains the cloud-to-device model common to both generations.
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 |
|---|---|
| Rescue or legacy agent | Maintains the outbound connection, device identity, and remote-access path appropriate to the installed generation. |
| Modern supervisor | Optional, unprivileged service for desired-state reconciliation, the local broker, and Software-managed containers. |
| 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 #
- Choose the right agent path - generation, role, architecture, integration, and operating runbooks
- 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
- Platform nomenclature - Device Class, device, Software, Product Application, portal, and network map
- Application and Software glossary - distinguish application, Software, and runtime terms
- Product runtime support matrix - check feature and device prerequisites