Artifact kinds
An artifact is one signed, versioned unit of update payload. Every artifact is named, versioned, hashed, and recorded in the update metadata before it can be shipped - there is no unsigned path. The platform stores, hashes, signs and delivers payload bytes for file-backed kinds. It does not execute them in the control plane or include them in metadata-only integrations.
The platform publishes three general artifact kinds, plus RAUC bundles through the operating-system update path.
Model
A machine-learning model packaged for the fleet - for example an ONNX, TensorRT, or TFLite file. A model artifact carries a manifest describing it:
- framework - onnx, tensorrt, tflite, and so on
- input specification - what the model expects
- evaluation metrics - how it scored
- target hardware profile - the device class it is built for (for example a specific Jetson profile)
That manifest is metadata you supply alongside the file. It is what lets the platform reason about whether a model fits a given device before sending it.
Container
A container artifact is a signed, digest-pinned reference to an OCI image - not a
copy of the image bytes. When you publish, you give a registry reference (a tag or
an explicit sha256: digest); the platform resolves the tag to an immutable
digest at publish time and freezes it. The device runs exactly that digest. A
later tag move in the upstream registry surfaces as a new version you choose to
publish, never a silent swap under a running rollout. See
Registry connections.
Each container also carries a closed capability profile for the devices, GPU,
mounts, secrets, network, ports, environment, resource limits and candidate
health command it needs. Raw runtime arguments are not accepted. The agent
starts a candidate without the live host ports and runs the signed health
command as direct in-container arguments. The executable is resolved using the
candidate image's PATH, not the device host's PATH, so the image must contain
the command. For example, use curl -fsS http://127.0.0.1/health only when
curl is present in that image. The current workload stays in place until that
check passes. Replacements declared stateful with an irreversible migration are
refused because automatic rollback would not be truthful.
The console reviews this command as the exact signed argument vector and blocks
known port and wget -O mistakes before publication. If a signed command is
wrong, publish a corrected artifact revision. It can reuse the same immutable
image digest while changing the signed capability profile; the original revision
remains unchanged for audit and rollback.
Config
A configuration artifact ships a file to devices. In its simplest form it is a signed file the agent retains. A config artifact can also carry a delivery profile that tells the agent where to place the file and how to apply it:
- destination - a clean, absolute path on the device
- mode - the file's octal permissions
- reload - what to do after placing it: nothing, restart a systemd unit, or run an allowlisted command
The delivery instructions are signed as part of the artifact, and the agent re-validates them against its own allowlist before acting. Nothing in a config artifact grants an arbitrary command channel onto the device.
OS bundle
Full operating-system images are published as customer-signed RAUC .raucb
files. Meshanics delivers the exact bundle through TUF and integrates with the
native RAUC D-Bus service. RAUC owns inactive-slot installation and bootloader
state; the agent marks a new boot good only after the signed product health probe
passes. Support requires a qualified product image with a working A/B layout and
bounded boot-attempt policy. See
Linux A/B system updates.
Lifecycle
Every artifact has a status (active or archived) and a release channel (stable, beta, or canary). Archiving and channel changes touch catalog metadata only - they never alter the signed content. Each change is written to the append-only audit trail.