Appearance
What Dataplicity is for
Dataplicity gives teams a post-shipment operations layer for Linux IoT devices. It connects device identity, fleet context, evidence, response, and controlled access without replacing the application runtime or every specialist system around it.
Use this page as the quick map. For the full evaluation path, start with After devices ship. For a concrete OEM picture, see SiloSentry - a fictional grain-bin sensor company walkthrough of devices, ops walls, incidents, and fleet fixes on Dataplicity (illustrative, not a real customer product).
Before shipment
Use Dataplicity during development and production preparation to:
- test the agent and outbound network path on representative hardware
- validate Remote Shell, Wormhole, and file retrieval under the intended Linux permissions
- include the agent in a repeatable image or provisioning process
- establish device class, organisation, and support context before scale
After shipment
Use Dataplicity when a deployed unit becomes an operational responsibility:
- see device and fleet connectivity state
- organise product, rollout, and network context, and customer or site records where those modules are enabled
- gather device-scoped logs and monitor evidence
- move alerts into owned incident response where enabled
- use remote access or bounded fleet actions when intervention is justified
- review supported platform history and communicate selected customer-safe status
Common problems Dataplicity solves
| Problem | How Dataplicity helps |
|---|---|
| Device is behind NAT or on a customer network | Agent-initiated route without per-device inbound port forwarding; restricted networks may require approved outbound destinations |
| Support needs a consistent field access path | Browser-based Remote Shell and Wormhole through the Dataplicity application |
| Device is offline and nobody knows why | Fleet visibility, online/offline status, and notifications |
| Logs are scattered or not tied to the device/customer | Centralised logs with device and fleet context |
| Engineering keeps getting pulled into routine support | Individual team access, shared evidence, and an explicit escalation path |
| Custom admin panels are growing out of control | Operational workflows around the device instead of bespoke internal tools |
| Customer needs selected status information | Customer-facing status surfaces where enabled, separated from internal diagnostics |
| Team needs access and action history | Supported product history for operational and security review, subject to feature coverage and retention |
Fit Dataplicity into your stack
Keep the application runtime, organisation-wide observability, full ITSM lifecycle, CRM, and corporate networking tools where they are authoritative. Use Dataplicity for the joins centred on the deployed Linux device.
See Dataplicity beside your existing stack for the comparisons and integration boundaries.
Next steps
- After devices ship - how remote access grew into the operations layer
- One device record from factory to field ticket - identity across the lifecycle
- Getting started - install your first device
- How it works - understand the architecture
- Production rollout - prepare devices for the field
- Business workflows - short stories for internal ops and connected-product companies
- Illustrative customers - demonstration fleets that make those stories concrete
- SiloSentry - fictional OEM walkthrough of post-shipment ops (illustrative)