Appearance
Software workspace #
Open Engineering > Software to define and deliver the software for a hardware product. Use the Device Class picker in the page header to choose the product you are changing.
The workspace is ordered around the release path:
| Section | Purpose |
|---|---|
| Containers | Attach application containers, upload immutable versions, and configure class values |
| I/O | Describe the device interfaces available to class software |
| OS | Choose the OS update mode and manage Dataplicity or organisation-signed RAUC images |
| Builds | Compose exact container versions and an optional managed OS image |
| Delivery | Release and observe the staged OS-image part of a Build |
Containers can also be viewed across the organisation by choosing All containers in the class picker. I/O, OS, Builds, and Delivery always require a Device Class.
Choose the Device Class first #
A Device Class is the compatibility and delivery boundary. Select the class that represents the hardware model, CPU architecture, and software contract you intend to ship.
The class architecture is optional until first set. Once saved, the single CPU architecture is permanent. Confirm it against representative hardware before uploading releases. Create a new class for a different architecture rather than reusing an existing class identity.
The organisation's default provisioning class appears as provisioning only. It is the landing place for brand-new devices before they belong to a product, so Software configuration is unavailable there. Create or select a normal product class before attaching containers, configuring I/O, composing Builds, or delivering OS images.
Follow the workspace in order #
For a new product:
- Select the product Device Class.
- Attach and configure its application containers under Containers.
- Review required device interfaces under I/O.
- Under OS, keep OS management off, observe an existing RAUC integration, or enable managed OS updates after qualifying the image and rollback path.
- Compose a Build under Builds.
- Make the Build current or assign it to a tag cohort.
- If the Build includes an OS image, open Delivery and start its staged rollout.
Container versions begin applying from the selected Build. A managed OS image is held until its Delivery rollout releases eligible devices. This separation keeps application changes and rebooting OS changes independently observable and recoverable.
Keep the layers distinct #
The workspace does not turn every device update into firmware. A container is an application artefact. A Build is the desired combination of container versions and an optional OS image. The Dataplicity agent reconciles that desired state but has its own lifecycle. Board, modem, bootloader, and microcontroller firmware remain separate.
See Software and firmware boundaries before designing a production release process.