Documentation

Appearance

Can I add Dataplicity to an existing Linux product without replacing my OS or application? ​

Yes. Replacing your Linux distribution or rewriting your product application is not a prerequisite for using Dataplicity.

For an existing product, the normal approach is incremental:

  1. install the Dataplicity agent on the device;
  2. keep your current product software and supervisor;
  3. prove secure connectivity and support access;
  4. define the product as a Device Class when you are ready;
  5. publish selected data or controls through the local product interface;
  6. add customer-facing functionality only where it creates value.

That makes Dataplicity suitable for brownfield fleets where the shipped Linux image, application architecture, certification, or update mechanism is already established.

What can stay exactly as it is? ​

Your existing application can remain under whatever runtime already owns it, including:

  • systemd;
  • Docker or Podman;
  • a proprietary supervisor;
  • AWS IoT Greengrass;
  • balena or another application runtime;
  • a Python, C/C++, Java, Go, Node.js, .NET, or other service;
  • a vendor BSP or custom embedded Linux image.

Dataplicity does not require the product application to be packaged as a Dataplicity-managed container.

If all you initially need is fleet inventory, remote diagnosis, shell access, file transfer, logs, monitoring, and jobs, you can stop there.

When you want to expose product data ​

The next step is usually a small adapter rather than a rewrite.

Your existing application or a companion publisher sends selected values to the local Dataplicity product interface. Those values become Device Class streams that Dataplicity can use in product pages, monitoring, and customer-facing views.

For example, a tank monitor might keep its existing sensor and transaction application untouched while publishing:

  • level_percent;
  • volume_litres;
  • sensor_state;
  • last_measurement_at.

An industrial gateway might expose:

  • upstream PLC connection state;
  • message throughput;
  • protocol error count;
  • application version;
  • dependency health.

You are creating a stable product contract around the application, not moving the implementation into Dataplicity.

When you want remote settings or actions ​

The same rule applies in the opposite direction.

Dataplicity can expose settings and actions, but your local application remains responsible for validating and applying them safely.

A useful pattern is:

text
Customer/OEM UI
      |
      v
Dataplicity setting/action
      |
      v
local Dataplicity runtime
      |
      v
your application adapter
      |
      v
existing product application / hardware

Your application should reject anything that is invalid for the current device state. Safety and domain rules remain local.

Do I have to replace my OTA system? ​

No.

If your existing product uses RAUC, Mender, SWUpdate, OSTree, a vendor updater, or another proven firmware mechanism, keep it unless you have a separate reason to change it.

Dataplicity can manage product workloads and fleet operations without becoming the bootloader or OS image updater. See software and firmware boundaries.

What about old or unusual Linux builds? ​

Dataplicity is deliberately designed for a broad Linux estate rather than one prescribed operating system.

Current first-class distributions include common Ubuntu, Debian, Raspberry Pi OS, and Arch-based environments. Older or highly customised systems can have different constraints because available Python/runtime/kernel facilities vary.

For an unusual Yocto-derived or heavily customised BSP, treat compatibility as an engineering qualification exercise rather than assuming either success or failure. The key questions are:

  • CPU architecture;
  • available runtime/library versions;
  • outbound TLS/network capability;
  • filesystem and process model;
  • whether the full current supervisor/runtime is appropriate or a more conservative agent mode is required.

See installation on different operating systems for the current supported contract.

A sensible brownfield rollout ​

Do not begin by changing every device.

Stage 1 - representative unit ​

Install Dataplicity on a device with the real production image. Reboot it, exercise its normal application, and confirm there is no interaction with the product runtime.

Stage 2 - support-only pilot ​

Deploy to a small set of real units. Use Dataplicity for inventory, connection state, logs, files, diagnostics, and remote support. Establish whether the installation solves an operational problem before adding product integration.

Stage 3 - product contract ​

Create the Device Class and expose a small set of useful streams/settings/actions. Keep the contract deliberately narrow.

Stage 4 - customer experience ​

If the product is sold to downstream customers, configure customer/site allocation and the Customer Portal. Validate tenant isolation with a test customer before production rollout.

Stage 5 - wider fleet ​

Roll out using your existing deployment mechanism or Dataplicity fleet tooling as appropriate. Monitor reconnects, application behaviour, resource use, and support outcomes.

Cases where migration needs more care ​

Brownfield does not mean zero engineering.

Pay particular attention when:

  • the root filesystem is read-only;
  • flash write endurance is tightly constrained;
  • the device has extremely limited RAM/storage;
  • outbound traffic is explicitly allow-listed;
  • clocks/certificates are unreliable;
  • the product has no safe remote update path;
  • application and OS versions vary substantially across the fleet;
  • a regulatory approval treats software additions as a material product change.

In those cases, qualify one real unit and one real network environment before planning fleet deployment.

The strategic advantage of incremental adoption ​

A platform that requires an OS replacement creates a migration project before it solves your support problem.

Dataplicity's brownfield path is deliberately the reverse: connect the product you already have, prove value, then adopt more of the platform only where it replaces work you would otherwise have to build and operate yourself.