Delivery profiles
Most config gets shipped one of two clumsy ways: baked into a full image, or pushed by hand over SSH. The platform treats configuration as a first-class artifact instead — signed, versioned, rolled out, and rolled back like any model or container. A delivery profile is the piece that tells a device what to do with a config file once it has verified it: where to write it, with what permissions, and what to reload afterward.
What a profile carries
When you publish a config artifact, you can attach a small set of delivery fields. The platform wraps your file and those fields into a single signed descriptor that travels with the update metadata. The descriptor declares:
| Field | Meaning |
|---|---|
| activator | How the file is applied. Today this is place-file. |
| destination | An absolute, normalized path where the file should land. |
| mode | File permission bits, octal (for example 0644). |
| reload | Optional follow-up action: a systemd unit, an allowlisted command, or nothing. |
The file's contents are carried inside the descriptor alongside a SHA-256 digest, so the bytes that reach the device are exactly the bytes you published, and the device can prove it before writing anything. The platform never inspects what your config says — it only records metadata about the delivery itself.
Declarative, not scripted
A delivery profile describes an outcome — "this file belongs here, then reload that service." It is not a script. There is no embedded shell, no arbitrary command string, no hook that runs as part of the payload. A reload is either a named systemd unit or a fixed command line with an absolute binary; nothing else is expressible. This is deliberate: configuration delivery is one of the easiest ways to turn a fleet-management tool into a remote-code-execution channel, and a declarative profile keeps that door shut by construction.
Signed like everything else
A config artifact with a delivery profile rides the same signed path as a model or container. It is signed into the update metadata at publish time, and the agent on each device verifies that metadata and the content digest before it touches the filesystem. There is no separate, lower-trust route for "just a config file."
Backward compatible
Attaching a delivery profile is opt-in. A config published without a destination keeps the simpler behavior of being delivered into the agent's data directory for your application to read on its own terms. Profiles add placement and reload for the cases that need it, without changing how existing configs flow.