Publishing & signing
Publishing is the single act that turns content into a shippable artifact. The service reserves one catalog identity, stages immutable bytes, and publishes the signed update metadata. Only the final published state is visible to customers or eligible for rollout. There is no unsigned rollout path.
What "publish" does
When you publish - whether you upload a file directly or pin an image from a connected registry - the platform:
- Reserves the name, version, immutable artifact ID, digest, and target path.
- Stages the content-addressed bytes without changing signed metadata.
- Queues a durable TUF publication job. A service restart resumes this job.
- Publishes the signed metadata and atomically exposes the catalog entry, appends the audit event, and queues applicable SBOM generation.
File uploads are read as a bounded stream while the service computes SHA-256 and
size. New model, configuration, and service descriptors refer to a separate
immutable payload target instead of embedding the payload in JSON. The default
hosted upload policy is 2 GiB and operators can set ARTIFACT_MAX_UPLOAD_BYTES to
match their storage and ingress policy. Descriptor documents remain capped at
16 MiB.
If publication is interrupted, the reserved row remains hidden and the worker retries the exact staged digest. Once a path is published, the repository refuses to associate it with different bytes. Retrying the exact same publication does not create a second artifact or a new metadata version.
Correcting a signed definition
The image digest, candidate health command, runtime profile, and TUF target are immutable after publication. If a command is wrong, use Correct beside the container artifact. The console starts a new version with the same pinned image digest and existing profile, then lets you correct and review the definition. The original revision is not edited or deleted, so rollout and audit history stay truthful.
Before signing a container definition, the console shows the exact argument
vector the agent will execute. It catches common mistakes such as using the live
host port inside an isolated candidate or giving wget -O no output destination.
You must also confirm that the executable and arguments exist in the selected
image. This confirmation matters because the control plane does not run untrusted
customer images during publication.
Interrupted transfers
The device endpoint supports byte ranges with a stable digest ETag. Linux agents keep an agent-owned partial file and journal bound to the exact trusted target digest, size, and metadata view. After a process restart or link interruption, the agent requests only the remaining bytes when that identity is unchanged. If the metadata changes, the partial is discarded and the transfer starts again.
Only a complete file that passes the signed size and SHA-256 checks can be handed to an activator. Corrupt partials fail verification and are removed. Transfer completion and failure events contain the rollout, release and artifact IDs, byte counts, resumed bytes, retry count, digest verdict, duration and a bounded terminal reason. Signed webhooks carry those metadata fields, never payload bytes.
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.