Appearance
Core concepts
Dataplicity connects Linux products to two separated SaaS workspaces: OEM product and fleet operations, and a branded customer application. Start with the activation guide when you are building a product customers will use, or the five-part operating model when evaluating installed-base operations.
Operating connected products
Read the series in order for the complete evaluation path:
| Part | Article | Decision it supports |
|---|---|---|
| 1 | After devices ship | Why remote access alone is not an operations model |
| 2 | One device record from factory to field ticket | How identity survives provisioning, ownership, support, and change |
| 3 | Dataplicity beside your existing stack | What stays in your runtime, observability, ITSM, and network stack |
| 4 | From signal to verified recovery | How operators move from scope and evidence to a checked outcome |
| 5 | Trust on someone else's network | Which platform, network, and Linux permission boundaries apply |
If you need the short version, read What Dataplicity is for. If your devices already use Dataplicity Remote Shell, use Expand beyond remote access as the bridge.
Architecture and product fit
| Page | Description |
|---|---|
| What Dataplicity is for | Operational problems Dataplicity solves after devices ship. |
| How it works | Agent, IoT Router, and outbound connection architecture. |
| Expand beyond remote access | Add product definition, customer portal, evidence, monitoring, and fleet operations to devices already online. |
Device and fleet context
| Page | Description |
|---|---|
| Devices | Individual Linux devices in your account. |
| Fleets, groups, and tags | Organising devices at scale. |
| Customers, sites, and ownership | Mapping devices to customers and deployment locations. |
Access and connectivity
| Page | Description |
|---|---|
| Remote access | Shell, desktop, SSH, and file transfer options. |
| Wormhole | Outbound tunnels to web services on devices. |
| Dataplicity Lens | Open-source host inspection used with Remote Shell on IoT devices. |
Operations
| Page | Description |
|---|---|
| Logs | Collecting and viewing device output. |
| Configure logs in the dashboard | Add sources, search, and filter. |
| Monitors | Service, journey, heartbeat, and connectivity checks. |
| Create monitors and alerts | Health checks and notifications. |
| Alerts | Notifications when something needs attention. |
| Scheduled tasks | Running scripts across devices on a schedule. |
| Create scheduled tasks | Dashboard walkthrough. |
| Status pages | Customer-facing device or service visibility. |
Teams and governance
| Page | Description |
|---|---|
| Set up roles | Design a practical role set for an OEM or customer-scoped organisation. |
| Permission areas | Complete verbs, areas, and grants behind each role. |
| Audit trails | History of operational access and actions. |
| Trust on someone else's network | Outbound connections, authentication, and production security. |
| Production rollout | Moving from prototype to managed fleet. |
Follow a complete journey
Concept pages explain what and why. Continue into:
- Business workflows for the situation and people involved
- SiloSentry for a fictional OEM walkthrough of the post-shipment picture (illustrative)
- Fleet operations for provisioning, cohorts, and fleet actions
- Production operations for logs, monitors, incidents, and customer support
- Remote access for choosing an interactive access method
- Gateway API for supported server-side integration
- Security and compliance for production review