MeshanicsDocs
Artifacts & bundles

Publishing & signing

Publishing is the single act that turns content into a shippable artifact. The content is signed into the update metadata first; only then does a catalog record exist. There is no way to register an artifact that was not signed — the same code path runs in development as in production, with development keys instead of production ones.

What "publish" does

When you publish — whether you upload a file directly or pin an image from a connected registry — the platform:

  1. Computes the content hash and writes the blob as a signed target in the update metadata, under a stable name/version/file path.
  2. Records the catalog entry: name, version, kind, target path, hash, size, and any manifest you supplied.
  3. Appends an audit event describing exactly what was published.

If signing the target fails, no catalog row is created. The audit event is part of the same operation, so every artifact that exists has a published-by record behind it.

The signing model

Update payloads are protected with The Update Framework (TUF), which separates signing responsibilities across roles so that no single online key can forge an update. The platform follows a strict split:

  • Offline roles (root and targets) establish the root of trust and delegate who may publish. Their private keys are produced in an air-gapped key ceremony and never touch the running service.
  • Online roles (a delegated publisher, plus snapshot and timestamp) are what the running service holds. The publisher role signs new targets; snapshot and timestamp keep the repository fresh so that agents can detect a frozen or rolled- back view as an attack rather than a hiccup.

Online metadata is re-signed well before it expires, and the repository uses a consistent-snapshot layout so that a published target can never be silently replaced. On the device, the agent runs a full TUF client: it verifies the metadata chain and the target's signature before applying anything. For a deeper treatment see The Update Framework and the Trust Center, which exposes the public role material — key identifiers, thresholds, and expiry — for independent verification.

SBOMs

When you publish an artifact you may attach a software bill of materials. The platform recognizes CycloneDX and SPDX, validates that the document parses, and stores it against the artifact so it counts toward compliance coverage and feeds continuous vulnerability matching. You can also attach or replace an SBOM on an existing artifact later; the signed content is unchanged when you do. The SBOM describes components, not your payload's data — the platform handles metadata only.

Honest framing

The platform is not agentless. A small agent runs on each device and performs the load-bearing security work: it verifies signatures and metadata, swaps the artifact atomically, and rolls back on a failed health probe. What is zero-integration is your application and model code — it rides as containers and artifacts on top of a signed, A/B, rollback-safe base, with no changes to how you build it.

Related