Problem
Fleet can send firmware updates, but it does not have a first-class rollout workflow or durable history that ties a firmware payload to the miners it reached. Operators need to quickly answer:
- Which miners were targeted by a firmware update?
- Which miners completed the update, are still in progress, or need attention?
- Which firmware updates has a miner gone through?
Without this visibility, large updates are harder to operate safely and audit after the fact.
Desired outcome
Add a dedicated firmware rollout experience in Fleet. Operators should be able to choose a firmware payload and a compatible group of miners, pace the update in controlled batches, monitor progress, and manage an active rollout when conditions change.
Each rollout should preserve per-miner status and a durable timeline. Active and completed rollouts should remain available so operators can inspect results, retry miners that need attention, and understand firmware update history across the fleet.
What good looks like
- Operators can create and start a rollout for a compatible set of miners.
- Operators can control the rollout pace and pause, resume, or stop an active rollout.
- Fleet shows overall progress plus per-miner outcomes, attempts, and relevant error details.
- Completed rollout history and operator or system events remain available for inspection.
- Active rollout status is visible from the broader Fleet experience.
- The feature has appropriate permissions and auditability.
Prototype reference
The rongxin/firmware-rollouts-prototype branch explores this workflow, including model-scoped rollouts, controlled batches, lifecycle controls, per-miner results, history, and global rollout status. Treat it as product and technical discovery rather than the final design.
Problem
Fleet can send firmware updates, but it does not have a first-class rollout workflow or durable history that ties a firmware payload to the miners it reached. Operators need to quickly answer:
Without this visibility, large updates are harder to operate safely and audit after the fact.
Desired outcome
Add a dedicated firmware rollout experience in Fleet. Operators should be able to choose a firmware payload and a compatible group of miners, pace the update in controlled batches, monitor progress, and manage an active rollout when conditions change.
Each rollout should preserve per-miner status and a durable timeline. Active and completed rollouts should remain available so operators can inspect results, retry miners that need attention, and understand firmware update history across the fleet.
What good looks like
Prototype reference
The
rongxin/firmware-rollouts-prototypebranch explores this workflow, including model-scoped rollouts, controlled batches, lifecycle controls, per-miner results, history, and global rollout status. Treat it as product and technical discovery rather than the final design.