Skip to main content
This quick-start guide walks through deploying your first configuration with Miru. Here’s what we’ll cover:
1

Creating a release

We’ll define our config schemas, install the Miru CLI, and create a release in Miru.
2

Provisioning a device

Next, we’ll provision a device by installing and provisioning the Miru Agent on your target machine.
3

Deploying config instances

Finally, we’ll deploy config instances and make some edits.
If you don’t already have an account, navigate to the sign-up page and follow the instructions.

Concepts

To begin, let’s define the primary concepts in Miru.

Config instances

A config instance, also known as a config or an instance, is a set of parameters used to modify the behavior of code. Config instances are stored as text files (JSON or YAML), which applications parse into a structured format for consumption. The following YAML file defines a config instance used to control a robot’s motion.

Config schemas

A config schema defines the structure, types, and constraints of a config instance. It serves as a contract between code and configuration, ensuring that config instances are valid before being deployed to devices. Below are some example schema definitions in the JSON Schema and CUE schema languages.
If you don’t already use a schema, we recommend starting with an empty schema — one that treats all config instances as valid.

Config types

A config type is a named grouping of config schemas and their config instances. Every config instance and config schema belongs to exactly one config type. Config types gives the configurations in your fleet records a stable, human-readable identity (Mobility, Perception) that survives across the schemas and instances that come and go beneath it. For example, a Mobility config type houses configs related to the robot’s motion while a Perception config type houses configs related to the robot’s perception. Each config type has its own versioned schema, which its config instances must adhere to depending on the release they are deployed under.

Devices

A device is a machine to which config instances are deployed. This could be an NVIDIA Jetson, Raspberry Pi, industrial PC, or any other computer running your robot’s application.

Releases

A release is a version of software and its compatible config schemas. Within a fleet of robots, multiple software versions may be deployed—each release defines which config schemas are valid for that version. For example, software release v1.7.0 might specify the following schemas: Before deploying config instances to a device, the deployment’s release (v1.7.0) is used to verify that all required config instances are present and that each instance complies with the release’s schemas.

Deployments

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.
If these concepts are a bit fuzzy at the moment, don’t worry! Seeing these concepts in action will solidify their meaning.
Last modified on July 21, 2026