Appearance
What does Dataplicity replace, and what do I still have to build?
Dataplicity replaces much of the post-shipment operating and customer software layer around a Linux product. It does not replace the product itself.
A useful boundary is:
- you own the hardware, Linux image, product application, domain logic, safety behaviour, and commercial rules that make the equipment valuable;
- Dataplicity supplies device identity and connectivity, fleet visibility and support, product classes, product data and controls, customer/site/device tenancy, customer-facing pages, and optional bounded application workflows;
- specialist systems remain specialist systems where their job is outside that boundary, for example secure boot, board firmware, a safety PLC, a payment ledger, or a full A/B operating-system updater.
The stack in practical terms
| Layer | Typical owner |
|---|---|
| Sensors, actuators, electronics | You |
| Bootloader, BSP, kernel, Linux distribution | You / silicon or board vendor |
| Your control, measurement, media, or appliance software | You |
| Safety interlocks and hard real-time behaviour | You / local controller |
| Device identity and secure outbound Dataplicity connection | Dataplicity |
| Fleet inventory, remote support, diagnostics, jobs, drift visibility | Dataplicity |
| Product model: streams, settings, actions, dependencies | Dataplicity + your product integration |
| Customer/site/device allocation and permissions | Dataplicity |
| Customer-facing product pages | Dataplicity, configured by you |
| Bounded records/rules/processes around the product | Product Applications, where appropriate |
| ERP, accounting, CRM, tax, warranty and commercial contracts | Your business systems |
| Authoritative financial or safety-critical state | Your application/backend/local controller |
The point is not that Dataplicity should own every line of software. The point is that you should not have to build a second company around the software needed to operate and support the thing you already make.
What Dataplicity can remove from your backlog
For a typical connected-product OEM, the repeated undifferentiated work includes:
- finding and authenticating deployed devices;
- reaching equipment behind customer NAT, firewalls, or mobile networks;
- deciding how support engineers obtain controlled access;
- maintaining a fleet inventory and grouping devices by product model;
- collecting operational data and showing it to the right customer;
- separating one customer's devices and sites from another's;
- exposing safe product settings and actions;
- building customer-facing device and site pages;
- creating support, incident, monitoring, and fleet-change workflows;
- tracking which software or system state differs from the fleet;
- maintaining the authentication, tenancy, and operational plumbing around all of that.
Those are expensive to build well, but they are rarely the reason a customer buys your machine, controller, camera, energy system, or appliance.
What you should not try to move into Dataplicity
Product-critical local behaviour
If a behaviour must continue safely with no Internet connection, it belongs in the device or a local controller. Dataplicity can configure, observe, and initiate work around it; the cloud should not become the safety interlock.
Examples:
- compressor protection in HVAC;
- pump dry-run protection;
- emergency stop behaviour;
- fuel dispenser metrology and hard safety chains;
- access decisions that must complete within a deterministic local deadline.
Authoritative commercial state
A Product Application can coordinate useful operational workflows, but your accounting, settlement, tax, invoicing, contractual entitlements, and other authoritative commercial records should remain in systems designed for those jobs.
If a workflow involves money or entitlement, Dataplicity can participate without becoming the ledger of record.
Board and OS update mechanics
Dataplicity can distribute and operate product software, including class-managed OCI workloads where that fits. It does not make a specialist bootloader/OS update system unnecessary when your product requires atomic image replacement, signed A/B slots, rollback at boot, or board-specific firmware handling.
Keep RAUC, Mender, SWUpdate, OSTree, vendor bootloaders, or your existing mechanism where those are already the right answer. Dataplicity can sit above or beside them operationally.
Three common adoption patterns
1. Existing appliance, minimal change
You already have a systemd service, Docker workload, Greengrass component, or proprietary supervisor.
Keep it. Add Dataplicity for connectivity and fleet operations, then publish only the product values and controls that should be exposed to the platform.
This is the lowest-risk brownfield path.
2. Dataplicity also manages the product workload
If you want Dataplicity to install and version an OCI application for a Device Class, use class software and the firmware/release workflow. Your application remains your application; Dataplicity manages its distribution and lifecycle.
3. Full connected-product layer
Use Device Classes, streams/settings/actions, Customer Portal, customer/site allocation, and Product Applications where useful. This gives the downstream customer a product-specific application while the OEM retains a separate engineering workspace.
A test for whether something belongs in Dataplicity
Ask these questions:
- Is this primarily about operating, supporting, exposing, or coordinating a deployed Linux product?
- Is the behaviour safe if the Internet disappears?
- Does the OEM still own the authoritative business or safety state somewhere appropriate?
- Would implementing this independently require another generic SaaS/fleet/portal subsystem rather than adding product differentiation?
If the answers are yes, yes, yes, and yes, it is usually a good Dataplicity fit.