Appearance
Product runtime support matrix #
Use this page before designing an application or release. A feature can be available to the organisation while a particular device is still ineligible because its architecture, agent, operating system, or local runtime does not meet that feature's requirements.
Organisation and role requirements #
| Capability | Plan | Required access |
|---|---|---|
| Device Classes | Standard+ | Engineering write |
| Device Class I/O and UI Designer | Standard+ | Engineering write |
| Product Applications | Standard+ | Engineering write |
| Software, Containers, Builds, and Delivery | Standard+ | Engineering write |
| Customer Portal | Standard includes one portal and one downstream customer organisation; Business+ supports multiple | Organisation and portal administration as appropriate |
| Device Class Inventory | Business+ and its published availability conditions | Engineering write |
Organisation entitlement controls whether the workspace is available. It does not prove that a device can run a container, activate an offline dataset, or install an OS image.
Device and runtime requirements #
| Job | Device requirements |
|---|---|
| Streams, actions, and settings | A qualified agent generation and the local product-data contract required by the Device Class |
| Product Application commands | Product Runtime capability plus a device handler that validates, deduplicates where required, applies the physical action safely, and reports the result |
| Offline datasets | Product Runtime support, durable local state, enough storage for the active and last-known-good generations, and an application that verifies and activates the payload |
| Cloud Process | No edge Process runtime. Bound device commands still require eligible target devices |
| Edge Process | A Device Class with the Dataplicity Edge Runtime and a device that can run its Software Build |
| Mixed Process | Cloud Process support plus an eligible bound device for each explicit Edge segment |
| Class container | Matching linux/arm/v7, linux/arm64, or linux/amd64 class architecture, modern supervisor, and a qualified container runtime |
| Dataplicity OS container | The built-in containerd and nerdctl runtime, persistent dpdata, and a compatible Software Build |
| Custom Linux container | Docker, Podman, or nerdctl installed and qualified with the modern supervisor |
| Managed RAUC OS update | A/B slots, persistent data outside the root filesystems, matching RAUC compatible, rollback proof, verification trust, and the required agent capability |
| casync delta delivery | casync available on the device. Devices without it receive the complete artefact |
Placement boundaries #
Cloud runs the complete Process in Dataplicity. It is suitable for work that needs cloud records, integrations, or customer-wide coordination.
Edge runs the complete bounded Process on one selected device. It is appropriate when the workflow must continue locally while disconnected.
Mixed keeps the outer Process in the cloud and sends explicit Edge segments to one device as atomic local work. It does not provide transparent cloud-to-edge failover.
Keep hardware interlocks, watchdogs, emergency behavior, and authoritative physical safety in the device product. Process placement does not move that responsibility to Dataplicity.
Operating-system choices #
| Starting point | Container runtime | OS update path |
|---|---|---|
| Dataplicity OS on CM5 | containerd and nerdctl are included | Official Dataplicity OS or a deliberately selected custom RAUC image |
| Your own Linux image | Optional; install and qualify Docker, Podman, or nerdctl when using Software-managed containers | Keep your existing updater, or qualify the image for managed RAUC delivery |
| Existing product runtime only | No new container runtime is required | Keep the updater already owned by the product |
Dataplicity OS is optional. Choosing it does not change the ownership of your board support package, product qualification, signing decisions, or physical release acceptance.
Before enabling a production path #
- Confirm the organisation plan and the operator's role.
- Confirm the Device Class architecture and required runtime capabilities.
- Test one representative device with its real peripherals and storage.
- Exercise offline, reboot, duplicate-delivery, and rollback behavior.
- Use a bounded cohort before selecting a Build as the class default.
- Verify the customer-visible result, not only the control-plane status.