Skip to main content
A deployment is a set of config instances delivered to a device for consumption by your software. Deployments tie together config instances, releases, and devices to simplify configuration management and delivery. Deployments have a variety of constraints designed to simplify configuration updates:
  1. A deployment’s config instances are immutable Once created, the configs in a deployment cannot be updated. A new deployment must be created to modify a device’s configs.
  2. Deployments belong to a single release Deployments belong to exactly one release, whose config schemas are used to validate the configurations in the deployment.
  3. Deployments belong to a single device Deploying the same configs to two devices requires a deployment for each device.
  4. Deployments are one-time use Once removed from a device, a new deployment must be created to restore a device’s previous configurations.

​
Properties

​
string
A user-provided description of the deployment.Example: “increase acceleration limit to 1.2 m/s^2”
​
enum
The desired state of the deployment.Allowed values:
  • staged
  • deployed
  • archived
​
enum
The deployment’s last known activity state.Allowed values:
  • staged
  • drifted
  • queued
  • deployed
  • removing
  • archived
​
enum
The deployment’s last known error state.Allowed values:
  • none
  • failed
  • retrying
​
string
The status is a merged property of the activity status and error status fields, with error states taking precedence over activity states when errors are present.So, if the error status is none, then the status is simply the activity status. If the error status is not none, then the status is the error status.Below are examples of status values for different activities and error states.Enum: staged, drifted, queued, deployed, removing, archived, failed, retrying
​
Deployment
The deployment from which this deployment was patched.Examples: DPL-L5B8b
​
Release
The release which the deployment adheres to.Examples: 1.0.1, 1.7.0-beta.1
​
[] Config Instance
The config instances in the deployment, each of which satisfies a different config schema in the deployment’s release.Examples: CFG-68hdX, CFG-Cpa13

​
Deployment methods

Broadly speaking, there are two methods for creating and deploying configurations. Configurations can be:
  1. Edited per device via the config editor
  2. Staged in a release’s staging area to be deployed at a later time
Per-Device Editing Each device has a dedicated config editor for viewing and editing its configurations. Changes made in the config editor are immediately deployed to the device. The config editor deals only with a single device’s configurations. It does not support multiple devices at once nor does it support staging new deployments. For more information, check out the config editor documentation. Release Staging Staging a deployment is the process of creating a new deployment in a release’s staging area to be deployed in the future. Staging is primarily used to rollout a new release, providing an unobtrusive place to create and review deployments before being deployed to devices. A release’s staging area is also useful for batch operations. Deployments can be created, deployed, and archived in bulk, which helps manage large numbers of deployments at once. For more information, check out the staging area documentation.
Last modified on September 23, 2026