Skip to main content
To keep things simple, we’ve provided a getting-started repository that contains everything you need to create a release. Follow along with us by cloning the repository.

Define the schemas

Releases are defined by the config schemas they contain. The getting-started repository contains two sets of schemas for each of JSON Schema and CUE:
  • Empty schemas - regard all config instances as valid
  • Strict schemas - constrain the valid fields, types, and values for instances of the config type they belong to
For this tutorial, choose one of these schema sets to create your release with. If you’re unfamiliar with schema languages, we recommend starting with JSON Schema. If you don’t currently use a schema, we recommend starting with an empty schema and gradually adding constraints as needed.
Empty Schemas
Strict Schemas

Schema annotations

Each of the above schema examples carries annotations — metadata that Miru uses to process the schema and deploy config instances to the correct location on the device. The config type is the only required annotation; the rest are described below.
required
The config type is a required annotation that identifies the config type to which a schema belongs. Below is the syntax for annotating a schema with a config type slug.
If the provided config type slug does not yet exist, it is automatically created. To edit a config type after creation, visit the config types documentation.Examples: mobility, communication, perception
The schema language declares the language that a schema is written in. This annotation applies to Opaque schemas only, and is required for them.JSON Schema and CUE schemas have no schema language annotation. Their language is inferred from the schema file itself, so a .cue file is read as CUE, and a .json or .yaml file is read as JSON Schema unless it declares itself opaque.
Opaque
Because an opaque schema is written as JSON or YAML — the same formats as a JSON Schema — this annotation is what distinguishes the two.
The instance file path is the absolute file system path where config instances for this schema are written on the device.
The Miru Agent ships with out-of-the-box access to /srv/miru. To deploy configs to a custom directory, please visit the File system access page.
This annotation is optional and defaults to /srv/miru/configs/{config-type-slug}.{instance-format}. To share the same schema amongst multiple config instances, declare instance slots instead.
Examples:
  • /srv/miru/configs/mobility.json
  • /home/myapp/configs/communication.yaml
  • /var/lib/myapp/configs/safety.yaml
Instance slots define one or more config instances that are valid for a given schema. Instead of maintaining a near-identical config type for each destination, declare several slots to allow multiple config instances to share a single schema.
A schema may declare an instance file path OR instance slots. Declaring both will error.
This annotation is optional. Omitting it will either use the instance file path annotation, or create a single slot with default values.
For more information about instance slots, visit the Instance slots section of the schemas documentation.
The instance format declares the format that config instances for this schema are deployed as on the device.Visit the File formats section of the schemas documentation to learn which formats are supported for each schema language.This annotation is optional and is inferred from the instance file path’s extension. Under the default instance file path of /srv/miru/configs/{config-type-slug}.json, the instance format therefore defaults to json.
Examples: json, yaml, xml, text

Set up the CLI

Next, we’ll install the CLI—the primary method of creating releases in Miru. Creating releases via the CLI is a deliberate design choice. We believe a release’s schemas should live in a Git repository. This allows them to be versioned alongside the code that uses them and encourages better software development practices. While this tutorial covers creating releases on your local machine, the CLI can also be used to create releases in a CI pipeline. Install The CLI is only available on macOS and Linux. Windows is not supported.
Install via Homebrew.
If you are not seeing the latest CLI version, refresh Homebrew with brew update.
Login To log in, run the login command.
The CLI prints a verification URL and a short code, then opens the URL in your default browser. Confirm that the code in the browser matches the code in the terminal.

Create a release

With the CLI setup, we are ready to create a release in Miru. Navigate to the root of the getting-started repository and create the release with a schema set of your choice.
Upon a successful creation, you’ll see a confirmation message similar to the following:
Git metadata is pulled from the local Git repository that the schemas are defined in.
To view the release in Miru, navigate to the releases page and click into the release.
Releases page
Then select the overview tab at the top of the page to view the release’s details.
Release overview page
For a more comprehensive guide on creating releases, visit the define releases documentation. For a concise reference of the CLI command, visit the CLI Reference.
Last modified on August 11, 2026