Linux compatibility #

Dataplicity is designed for a broad range of Linux devices. Raspberry Pi OS, Ubuntu, and Debian are common choices, while specialised distributions, custom images, and industrial hardware can also run the agent when they provide its runtime and network requirements.

This flexibility is useful when your product does not fit a short hardware catalogue. If you are working with an unusual board, architecture, or Linux image, we will help you assess it and get the agent running wherever the platform makes that possible.

You can also use Dataplicity OS, the ready-made CM5 Yocto quickstart with the agent and RAUC A/B layout already integrated. Most products still bring their own distribution or custom image; Dataplicity OS is convenient when that board and layout match, not the required OS path.

Choose the generation before the requirements #

There are three paths in active fleets:

Path	Use it for	Detailed guide
Modern rescue-only	New/current installs that need remote support but not the product runtime	Modern integration
Modern rescue plus supervisor	New/current products using streams, settings, actions or Class Software	Modern integration
Legacy classic agent	Existing compatibility-frozen remote-access fleets	Legacy agent

The rescue and supervisor requirements below describe the modern installer modes. Do not infer a legacy unit's service names or lifecycle from them. If the generation is unclear, identify it first.

Modern installer modes #

Requirements depend on whether the device needs remote access only, or also the optional supervisor used for Class Software and connected-product on-device functions.

Remote access only (rescue) #

Rescue is the remote-access agent for mixed-age Linux fleets:

Python 2.7 or newer (package requirement)
Build and test coverage includes 2.7, 3.5–3.7, and 3.9–3.12 (including Ubuntu 24.04 / Python 3.12)
Outbound HTTPS and accurate system time
Writable /var/lib/dataplicity, /etc/dataplicity, and /home/dataplicity

That Python floor is intentional: decade-old gateways and current build images can share one Dataplicity organisation and inventory.

Rescue plus supervisor #

Install the supervisor when the device needs Class Software, the local stream broker, or other management-plane functions:

Python 3.8 or newer, with pip and venv
Debian / Raspberry Pi OS 11 (Bullseye) or newer, Ubuntu 20.04 or newer, or a current Arch, Alpine, or Fedora image with equivalent packages
Architecture x86_64, aarch64, or armv7 for the published management package
docker, podman, or nerdctl on PATH when Class Software is used
Writable install and state paths described in Dataplicity agent

Field devices are Linux. The workstation Dataplicity CLI is a separate tool.

Install the agent #

In the Dataplicity web console or the native mobile app, open Add device, then copy and run the generated command on your Linux device (or use the phone’s guided LAN SSH install for a Raspberry Pi on the same Wi-Fi). This is the supported installation route. The command includes the correct installer and provisioning details for your organisation.

Phone-specific steps: Native mobile app.

When the management-plane installer is used and the device only needs remote access, append --rescue-only so the supervisor is not installed.

Custom hardware and images #

Email support@dataplicity.com with the distribution, release, architecture, and any image customisations. We can help identify the agent's runtime, certificate, service, permission, and connectivity requirements for your platform.

Linux images vary, so validate the exact image you plan to ship. This gives you a repeatable installation for production devices and catches image-specific changes before a fleet rollout.

For the complete image-engineering contract, including persistent paths, service users, A/B layout, and custom Yocto builds, see Integrate Dataplicity with your Linux image.

Validate your Linux image #

Before a fleet rollout:

Confirm outbound HTTPS access and accurate system time.
Generate a fresh install command from Add device.
Run it on the exact OS image and architecture you will deploy. Use --rescue-only when validating a remote-access-only cohort.
Confirm the device enrols, reconnects after a reboot, supports the remote-access features you need, and completes an agent upgrade.
When you use Class Software, confirm the supervisor, container runtime, and a successful application deploy on the same image.
Repeat the test whenever you change the base image, architecture, security policy, or service manager.

Once the image passes these checks, use the same validated build and installation process for your production rollout.