Appearance
Configure container software #
Use Engineering > Software > Containers to manage application containers for a Device Class. A container is one application workload. It does not include the host OS, Dataplicity agent, bootloader, or physical device firmware.
Choose who owns the software #
The container catalogue contains two kinds of software:
| Kind | Ownership and workflow |
|---|---|
| Dataplicity-managed example | Dataplicity publishes the example and its parameter schema. Attach it to a class without uploading an OCI archive. |
| Your container | Your organisation owns the software definition, parameter schema, and immutable OCI releases. Attach an existing organisation container or create one. |
Managed examples are learning and integration aids, not hardware drivers. An organisation-owned container remains your responsibility to build, test, version, and qualify on the target hardware.
To attach software, select the Device Class, open Containers, and choose Add container. Pick a managed example or Your container. A container already present in the organisation catalogue can be attached to more than one compatible class.
Define an environment parameter schema #
The software owner can define which environment values operators may configure. Each parameter has:
- an environment key and operator-facing label
- a type: text, number, on/off, or choice
- an optional default, group, hint, and placeholder
- optional conditional display
- a list of allowed values for a choice parameter
Treat this as an operator contract. Use stable keys, meaningful labels, safe defaults, and bounded choices. Do not expose Dataplicity credentials or unrestricted command fragments as parameters.
The schema belongs to the software definition. A Device Class stores its own values as class environment overrides. Those overrides apply when a Build ships, so the same organisation-owned container can use different settings in different product classes without creating another software release.
Changing a class override does not alter the immutable OCI archive. Review the effective values with the same care as a version change, especially for thresholds, hardware paths, sampling intervals, and actuator behaviour.
Upload an immutable version #
For organisation-owned software:
- Open the container from Containers.
- Choose Upload version.
- Supply the version and built OCI archive.
- Wait for verification and delivery preparation to finish.
- Open Builds to select the version in a new Build.
The upload is a built OCI archive, not source code. Accepted archive suffixes are .tar, .tar.gz, and .tgz. Build it for the Device Class architecture.
Dataplicity prepares uploaded archives for efficient delivery. Devices with casync can reconstruct the artefact from shared chunks and local seeds. Devices without usable delta support download the complete archive. In both cases the complete artefact is verified against the registered identity before import.
Configure hardware access deliberately #
Review I/O before relying on serial, GPIO, video, sockets, files, or other host interfaces. Request only the interfaces the application needs. An environment value can identify an interface; it cannot grant access that the class runtime does not expose.
Keep an existing hardware-owning process under its current supervisor when moving it into a container would weaken isolation or recovery. It can publish selected product data through the local agent broker where the qualified runtime supports that connection.
Next step #
Create a Software Build after every attached container has a version. A version is stored and available; a Build decides which versions a device should run.