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 the supported schema languages:
  • 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 are annotated with the x-miru-config-type and x-miru-instance-filepath fields. These annotations are crucial metadata that Miru uses to process the schema and deploy config instances to the correct location on the device.
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 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.
Instance file paths control the type of file that config instances are deployed as. Currently, JSON (.json) and YAML (.yaml, .yml) are supported.This annotation is optional and defaults to /srv/miru/configs/{config-type-slug}.json.
Examples:
  • /srv/miru/configs/mobility.json
  • /home/myapp/configs/communication.yaml
  • /var/lib/myapp/configs/safety.yaml

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.
Retrieve your authentication token from the Secrets page.
Paste the token into the CLI.

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 July 21, 2026