Fleet Provisioning & Update
The second hundred is the hard part.
One device is a project and a hundred is a system, and the difference is almost entirely provisioning and update. A fleet without a remote recovery path is a fleet with a permanent travel budget, and a fleet whose update process has never been rolled back is one bad release away from a very expensive week. This is the unglamorous work that decides whether a successful pilot survives being multiplied.
- Enrolls without a technician
- Zero-touchEnrolls without a technician
- Rollback proven by causing a failure
- ReversibleRollback proven by causing a failure
- Keys, not one shared secret
- Per-deviceKeys, not one shared secret
Sounds like
You might recognise one of these.
The pilot worked. Now we need forty of them and nobody knows how.
Updating them means someone physically visiting every site.
A firmware update bricked a unit and we had to ship it back.
Every device was set up by hand and none of them are quite the same.
What this includes
The work, specifically.
Not every engagement needs all of it. This is the range we cover and what each part is actually for.
Zero-touch provisioning
A device is powered on at its destination and enrolls itself: identity, configuration, credentials and application, without a technician touching it first.
Staged over-the-air update
Updates reach a canary group before the fleet, with health checks between stages and an automatic halt when they fail.
Rollback and recovery
An A/B or dual-bank scheme so a bad image falls back on its own, and a documented recovery path for the unit that fails anyway. This is the capability that removes the travel budget.
Device identity and credentials
Per-device keys rather than a shared secret, issued at provisioning and rotatable afterwards. A fleet shipping one identical key is one extracted key away from all of them.
Fleet health monitoring
Connectivity, version, storage and error rates visible per device and in aggregate, with alerting that reaches a person.
What you get
Deliverables, not documents.
- A provisioning path proven on a real device, not described
- Staged update pipeline with canary, health gates and automatic halt
- Rollback scheme and a documented physical recovery procedure
- Per-device credentials with a rotation process
- A fleet dashboard with per-device version and health
Shapes
How this usually runs.
Fleet readiness review
1–2 weeksWhat provisioning, update and recovery look like today, and what breaks at ten times the current count.
Provisioning and update build
4–8 weeksThe pipeline built and exercised, including a deliberate bad release to prove the rollback works.
Fleet operations
OngoingRunning updates, monitoring health, and managing credentials as the fleet grows.
Tooling
What we build it with.
No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.
- Provisioning
- Update
- Observability
Questions
Fleet operations, honestly.
Sooner than most people expect — roughly the point where a site visit costs more than a day of engineering, which for geographically spread fleets can be under twenty units. Below that we will tell you to skip it.
It falls back to the previous image on its own. That is what the A/B scheme is for, and we prove it during the build by shipping a deliberately broken release to a canary device rather than by asserting it in a document.
No. This is purpose-built devices that are part of a system. Laptops, workstations and the end-user estate are the IT division's device lifecycle service, and the two use genuinely different tooling.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.