Appearance
Software and firmware boundaries
Dataplicity uses the word firmware for a versioned set of class container releases. That object is not automatically the firmware understood by a board vendor, bootloader, modem, microcontroller, or Linux distribution.
Four separate layers
| Layer | What it is | Normal owner |
|---|---|---|
| Product application | Your existing systemd service, container workload, Greengrass component, balena service, or other runtime | You and your chosen runtime |
| Class container release | A versioned OCI image uploaded under Device Class Software | You; Dataplicity stores and orchestrates the selected image |
| Dataplicity firmware set | A sequenced set that pins one version of each class container, optionally selected by tag rollout groups | Dataplicity control plane plus your release decision |
| OS or device firmware | Linux image, kernel, bootloader, board support package, modem firmware, MCU image, or vendor update package | You and the hardware or OS update mechanism |
The Dataplicity field agent is another software component with its own upgrade and recovery lifecycle. Do not assume that releasing a class container upgrades the agent, Linux packages, the kernel, or physical device firmware.
Runtime boundary
Class Software can install and version supported OCI application images on a qualified device. It does not promise to:
- replace systemd, your existing supervisor, or a general container platform
- update the host OS, boot chain, kernel, drivers, modem, or microcontroller
- grant access to a serial port, GPIO, file, or socket that the runtime has not explicitly exposed
- make a privileged image safe
- migrate application data or validate hardware behaviour for you
If the existing product process already owns the hardware interface, keep it there and publish selected values to the local agent broker where supported.
Rollout boundary
A Dataplicity firmware set is sequenced. Make current selects the class default. Pin to tags selects a tag-defined cohort; where a device matches multiple pins, the highest matching sequence currently wins.
That selection expresses desired class-container state. A production rollout still needs:
- a compatible architecture and qualified agent/runtime
- a staging device with realistic peripherals and data
- a bounded first cohort
- per-device deployment result review
- application health and stream verification after restart
- a decision to expand, pause, or restore a previous known-good set
Do not use Fleet jobs as a substitute for version selection and deployment results.
Rollback boundary
Dataplicity can select a previously uploaded, compatible container version by creating or restoring the intended firmware-set selection. That is an application rollout operation, not a guaranteed transactional rollback.
Your image must remain rollback-compatible with:
- files and databases changed by a newer application
- device settings and artefacts already delivered
- old and new stream bindings used by the customer page
- external services and protocol versions
Dataplicity does not claim to reverse host OS migrations, bootloader changes, hardware fuses, modem firmware, MCU state, or irreversible product data changes. Those need the rollback or rescue path supplied by the system that owns them.
Naming in customer communication
Use precise names:
- Application version for your product process or OCI image
- Dataplicity firmware set for the class container-version set
- Dataplicity agent version for the field agent
- OS image or Linux release for the host operating system
- Device firmware with the component name for modem, MCU, bootloader, or board firmware
Do not show the Dataplicity firmware-set sequence to a customer as though it were the complete appliance firmware version unless your release process deliberately makes those concepts equivalent.