Appearance
Software and firmware boundaries #
Use a precise name for each layer before planning a release. Dataplicity Software Builds are application desired state; they are not automatically the firmware understood by a board vendor, bootloader, modem, microcontroller, or Linux distribution.
Five separate layers #
| Layer | What it is | Normal owner |
|---|---|---|
| Application container | An immutable OCI release for one product application | You, or Dataplicity for a managed example |
| Software Build | A sequenced selection of container versions plus an optional managed OS image for one Device Class | Dataplicity control plane plus your release decision |
| OS image | A signed Linux/rootfs image installed through qualified RAUC A/B delivery | You and the OS image and boot-chain process |
| Dataplicity agent | The device identity, broker, update-reconciliation, and remote-operation component | Dataplicity, qualified in your product image |
| Physical firmware | Bootloader, board support package, modem, MCU, peripheral, or vendor firmware | You and the component update mechanism |
An existing product application can remain under systemd, Docker, Greengrass, balena, or another supervisor. It does not become a Dataplicity-managed container merely because it publishes selected values through the local agent broker.
Runtime boundary #
Engineering > Software > Containers can install and version supported OCI application images on a qualified device. It does not:
- 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.
Build and rollout boundary #
A Software Build is sequenced. Making a Build current selects the class default. Assigning a Build to a tag cohort selects matching devices. If a device matches several cohorts, the Build with the highest sequence number wins as a unit, including its containers and optional OS choice. Without a matching cohort, the current class Build is the fallback.
Container versions begin reconciling from that Build selection. A referenced OS image remains held until its staged rollout is started under Delivery. Follow Software Builds and cohorts for targeting and Software delivery for result and rollout handling.
A Fleet job is command fanout, not a substitute for Build selection, deployment results, or OS delivery state.
Rollback boundary #
Dataplicity can select previously uploaded compatible container versions in a new effective Build. That is an application rollout operation, not a transactional reversal of every change the application made.
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.
For Device Classes that deliberately use managed RAUC OS images, your image and boot chain must provide A/B root filesystems, persistent device data, automatic failed-boot fallback, and casync in both slots when you want delta downloads. Dataplicity does not supply the Linux/RAUC image. Run dataplicity rauc-ready on a representative unit, then complete the physical lab checklist in RAUC image OTA requirements.
The same casync pipeline indexes Software container tarballs. A device without usable casync receives the complete artefact. Delta reconstruction and full download both end with verification of the registered artefact.
Naming in customer communication #
Use precise names:
- Application version for your product process or OCI image
- Software Build for the class selection of container versions and optional OS image
- 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 Software Build sequence to a customer as though it were the complete appliance firmware version unless your release process deliberately makes those concepts equivalent.