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

You should keep ownership of the software that makes the product distinctive. Dataplicity is there to remove the generic software and operating work required to run and support it after shipment.

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 Software Builds and the delivery 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.