Quick Start
Define and deploy your first configuration.
Concepts
Gain an understanding of Miru’s core concepts.
Introduction
As you scale your fleet of robots, configuration complexity scales with it! Each robot diverges from the fleet’s baseline configuration:- Hardware upgrades introduce new parameters
- Customer environments require site-specific tuning
- Feature flags evolve independently of application code
What makes config management so difficult?
Tedious and error-prone workflows
In the early stages, robot configurations are managed manually. Engineers SSH into robots, edit text files directly, copy configurations between devices, and eyeball diffs to understand what changed. This is problematic for several reasons:- Typos and other simple mistakes lead to unnecessary downtime and slow fixes
- SSH requires an open inbound port, increasing the surface area for security breaches
- Teams must hire software-savvy Deployment Engineers, despite a preferred background in Mechanical or Electrical Engineering
Difficult versioning
Compared to software releases, versioning configs is more complex. Every robot maintains its own configuration for each software release. As releases are rolled out, each device must be patched with the new release’s configurations while carrying over any device-specific parameters from previous releases. With hundreds of devices and dozens of releases, there is no longer a clear answer to basic questions such as:- What configuration was this robot running last week?
- Which changes were applied fleet-wide versus locally?
- What state do we return to when something breaks?
Lack of auditability
The history of configurations is scattered across developer terminals, Slack messages, and the heads of field engineers. As the fleet grows, teams lose track of:- Who made a change?
- When it was made?
- Why was it made?
- What exactly changed?

