Skip to main content
Create a release along with its associated git commit and schemas in Miru. Both the git commit and the schemas associated with the release are created idempotently. If the git commit does not yet exist in Miru, it is created. If it already exists, it is not recreated and no error is returned. Similarly, if the provided schemas do not yet exist in Miru, they are created. If they already exist, they are not recreated and no error is returned. Git commits are identified by their SHA while schemas are identified by their content. Schemas with equivalent content are considered identical in Miru (even if the comments, spacing, or other formatting is different). For a more detailed guide on creating releases, visit the create releases documentation.

​
Requirements

  • The release’s config schemas must be committed to a local Git repository
  • The schemas must be annotated with their config types (see annotations below)
  • The Git repository must have a remote URL (GitHub, GitLab, Bitbucket, etc.) configured

​
Usage

Use the --schemas flag to specify a directory containing the schemas to include in the release.
miru release create \
  --version {version} \
  --schemas {/path/to/schemas/directory/}
Flags
​
--version, -v
string
required
A semantic version, unique for a given release.Versions must be dot-separated integers. You may optionally use a v prefix, a prerelease suffix (e.g. -alpha.X, -beta.X, -rc.X), or a build suffix (e.g. +build-metadata).Examples: v1, 1, v2.1, 2.1, v3.2.1, 3.2.1, v4.3.2-beta.1, 4.3.2-rc.1, v5.4.3+metadata, 6.5.4-beta.2+metadata
​
--schemas
string
A directory containing the config schemas to include in the release. May be specified multiple times for multiple directories.Must be specified if no schema files are provided.Examples: ./schemas
​
--schema
string
The path to a config schema to include in the release. May be specified multiple times to include multiple schemas.Must be specified if no schema directory is provided.Examples: ./schemas/schema1.yaml, ./schemas/schema2.yaml

​
API key scopes

If creating a release from a CI pipeline, the following API key scopes are required:
  • config_schemas:manage
  • git_commits:manage
  • releases:manage

​
Schema Annotations

​
config type
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.
x-miru-config-type: "{config-type-slug}"
Examples: mobility, safety-features, perception
​
instance file path
The instance file path is the file system location that config instances for this schema are deployed to relative to the /srv/miru/config_instances directory.This annotation is optional and defaults to {config-type-slug}.json, which deploys config instances to /srv/miru/config_instances/{config-type-slug}.json on a given device.
x-miru-instance-filepath: "{instance-file-path}"
Examples: /v1/mobility.json, /safety.json, configs/perception.json

​
CUE packages

CUE supports the concept of a package—a way to spread a schema’s definition across multiple files. For example, say we have a communication schema which contains the following files:
communication
peripherals.cue
network.cue
sensors.cue
main.cue
Each file defines a portion of the schema, which is then aggregated by the main.cue file to define the schema. Miru fully supports CUE packages, treating the communication directory as a single schema. Identifying packages The Miru CLI automatically identifies CUE packages for you when creating a release using the package clause at the top of each schema file (as described in the CUE documentation). You don’t need to explicitly specify the package in the CLI command—just provide the path to the package directory or to the individual schema files within the package. Annotations To annotate a CUE package, annotate exactly one file in the package. Annotating multiple files or no files will result in an error.

​
Examples

If the provided git commit and schemas do not exist in Miru, they are created and attached to the new release. This is indicated by the (new) suffix in the output.
command
$ miru release create \
  --version v1.0.0 \
  --schemas ./cue/strict-schemas/

◐ Creating release v1.0.0

  ✓ Pushed git commit (new)
    1c7f7a8 · miruml/getting-started

  ◐ Pushing schemas
    ✓ Mobility · SCH-D5nFP (new)
    ✓ Planning · SCH-37QAr (new)
    ✓ Communication · SCH-9WfCx (new)

✓ Created release v1.0.0
Last modified on February 12, 2026