Skip to main content
A file rule is a standing instruction about files on a device: whenever files matching a source pattern appear, upload them to a bucket, and govern how long the device retains them. Rules are shipped to devices as part of a release.

Properties

string
required
A human-readable name for the rule.Examples: Robot Logs, Crash Reports, Camera Footage
string
A hash of the rule’s resolved definition. File rules are deduplicated by digest within a workspace: pushing a rule identical to an existing one returns the existing rule instead of a duplicate.Example: sha256:1234567890
Source
required
Which files on the device the rule manages. See Sources.
Upload
An optional field that defines where matching files are uploaded to. Absent when the rule only manages local retention. See Uploads.
Retention
An optional field that defines how long the device retains local copies of matching files. Absent when the device keeps them indefinitely — Miru never deletes them. See Retention.

File format

Each rule is defined as a single YAML file in your Git repository:
Rule files reference the rule’s upload collection by its slug (upload.collection_slug) and the bucket by name (upload.bucket), while the API object returns their ids (upload.upload_collection_id, upload.bucket_id). See sources, uploads, and retention for details on each field, and define file rules for how to release them.

Sources

A rule’s source declares what the rule matches on the device: which files it manages, and when a matching file is considered finished.
string
required
An absolute glob pattern that selects the files this rule manages.Must satisfy the following criteria:
  • Absolute — it starts with /
  • At most 1024 bytes, with no control characters
  • No .. segments, and no empty segments (// or a trailing /)
You must grant the Miru Agent read access to the files you want to upload. Visit the file system access section for more details.
Example: /var/log/robot/*.log
integer
default:"60"
How long, in seconds, a matching file’s size and modification time must stay unchanged (quiescent) before it is considered stable. Going quiescent is what makes a file eligible for upload and deletion.

Uploads

A rule’s upload block declares which registered bucket matching files are written to, and the object path within it. The upload block is optional. If omitted, the rule only manages local retention.
string
required
Slug of the upload collection the resulting uploads are grouped into.Example: robot-logs
string
required
Name of the registered bucket this rule uploads to.Example: my-uploads-bucket
string
The template which defines the object path to which the uploaded file is written.The following variables are supported, which are filled in when each upload’s object key is rendered:
Templates must contain the {upload_id} variable.

Retention

A rule’s retention block governs deletion of the local copies of matching files. When absent, the device retains matching files indefinitely (Miru never deletes them). The retention block doesn’t go into effect until a file is considered stable. That is, its size and modification time have stayed unchanged for source.stability_window_secs.
boolean
Whether a file must have its upload durably confirmed before it may be deleted. Must be set when the rule has an upload block.
  • true — files are never deleted before their upload is confirmed.
  • false — upload is best-effort; files may be deleted once they are eligible, even if their upload has not completed.
integer
required
How long, in seconds, the file lives on the device before it is scheduled for deletion. The clock starts as soon as the file is considered stable.Use 0 to delete the file as soon as it becomes eligible.Example: 604800
Local deletion is performed by the Miru Agent. Deleting a file requires write access to its parent directory — see file system access.

Immutability

File rules are immutable. A rule is created once, shipped to devices as part of a release, and never edited in place. To change what is managed, you must create a new rule, release it, and deploy it to your devices.

Git provenance

Rules are defined as YAML files in your Git repository and created by releasing them via the CLI. Each rule records the Git commits it was released from — the commit itself and the rule file’s path relative to the repository root — so any rule in Miru can be traced back to the exact lines of YAML that defined it.

Create a file rule

File rules must be created as part of a release. Visit the define file rules page to learn how to create file rules and releases.

View a file rule

To view a file rule in Miru, navigate to the Releases page, and click into the release that contains the file rule you want to view.
Releases Page
At the bottom of the page under the Overview tab, you will find a list of the release’s file rules.
Release File Rules List
To see more details about a file rule, simply click on the dropdown arrow next to the file rule.
Release File Rule Details
Last modified on August 18, 2026