Industries
Firmware rollouts for logistics robots.
Fleets living inside other companies' warehouses, behind their firewalls, on their maintenance windows. Temper maps rings to customers and treats version pinning as a supported state rather than a failure to standardise.
What breaks in logistics deployments, specifically
Warehouse connectivity is usually good, which moves the hard part somewhere else entirely: everything about the site belongs to somebody else.
You do not control the network
The robots sit on a customer VLAN with egress through their proxy and no inbound path at all. Anything that assumes you can reach in and fix a unit is designing for a network you will never be given.
Maintenance windows are contractual
You update at one in the morning on a Tuesday because that is what the agreement says, in the site's own timezone. Rings map to customers, not to internal cohorts, and a customer is either in or out.
One version fleet-wide is not the goal
A customer who validated 2.3 will not take 2.4 until peak is over, and they are right to refuse. Drift is deliberate here, and the job is tracking it with an expiry rather than eliminating it.
What a health gate looks like on a warehouse robot
| Signal | Why it gates here |
|---|---|
picks_per_hour vs trailing shift | Throughput compared against the same site's own recent shifts, because sites differ more than releases do. A five percent regression is a contractual conversation. |
safety_field_trips | A build that trips protective fields more often has not become dangerous, it has become slow and annoying, and the site will ask you to roll it back anyway. |
dock_success_pct | Docking and charging failures compound overnight. A unit that misses its dock is out of the shift, not just out of a job. |
handshake: wms, fleet-manager | Integration regressions are the most common real-world failure here, and they are invisible to any check that only looks at the robot. |
path_replan_latency | Congestion behaviour is where navigation changes actually show up. An empty aisle proves nothing about peak. |
The same rollout, written for someone else's warehouse
# Rings are customers, not internal cohorts. release: amr-nav@2.4.1 rollback_to: 2.3.0 network: egress_only: true # no inbound path through the customer firewall proxy: site_local cache: site_gateway # one download per site, not per robot verify: trial_boot: 3 attempts confirm_within: 1 shift checks: - service: amr-nav healthy - metric: picks_per_hour within 8% of trailing shift - metric: safety_field_trips <= baseline - metric: dock_success_pct > 99 - handshake: wms, fleet-manager on_failure: revert_and_report rings: - name: canary match: { site: internal-lab } soak: 2 shifts - name: site-dc3 match: { customer: northgate, site: dc3 } window: { tz: site_local, hours: 01:00-04:00 } soak: 5 shifts - name: remaining-sites match: { all: true } requires_approval: true pins: # drift on purpose, with an expiry - { customer: northgate, version: 2.3.0, until: peak_end } ring_gate: min_confirmed: 15 units max_self_reverts: 0 stale_after: 72h # dense wifi, so silence means something here on_timeout: escalate on_gate_failure: halt_and_rollback
The network block encodes the deployment reality: egress only, through the site's proxy, with a gateway cache so forty robots do not each pull the same image through a link the customer is paying for. Nothing in the design needs an inbound connection, which is what makes it deployable on a network the customer's security team owns.
pins is the piece most teams end up tracking in a spreadsheet. A customer held on an older build is a normal, supported state here, recorded with a reason and an expiry so it does not quietly become permanent.
How Temper handles it
01Rings that match your contracts
A ring can be a customer, a site or a building. Windows are evaluated in the site's own timezone, so a rollout does not arrive at two in the afternoon in Perth. See staged rollouts.
02Egress-only by design
The agent pulls. Nothing needs a port opened toward the robots, which is the difference between a security review that passes and one that does not.
03Pinning as a first-class state
Version pins carry a reason and an expiry, and the fleet view shows who is behind on purpose versus who is behind by accident. See fleet configuration.
04Evidence per site
When a customer asks what changed on their floor last month, the answer is a query rather than an archaeology project. See audit and compliance.
Early access
Running robots on customer sites?
If every release means coordinating windows across sites that all want something slightly different, that is the problem this was built for.
Founding customers get direct engineering time and a permanent founding rate.