Rollouts · Coming soon

Staged rollouts and automatic rollback

A pre-flight report first, then waves that widen only when the last one confirmed, and pause on their own when something looks wrong.
Staged rollouts

Waves that widen only when it's safe.

Release management for OTA firmware updates: a release reaches 1% of your devices, then 10%, 50% and everyone, each wave only once the last one installed and confirmed. A failure rate over your threshold pauses the deployment by itself, and you can roll back.
In development
Target a product, a device group or cohort by tag, or a list of devices
Schedule a rollout into update windows, with a minimum battery level
Automatic pause on failures; pause, resume or roll back by hand
Every device's outcome kept per release: installed, confirmed, rolled back
Wave 3 of 4 · thermo 1.4.2
Example
Paused automatically
Confirmed
2,410 devices
Rolled back
64 devices
Failure rate
2.6% (pause at 2%)
Most failures
hw:rev2, firmware 1.21
Roll back
Resume
Pre-flight report

A report back as soon as you package.

Whenever you package a release, from the CLI, the GitHub Action, an upload or a managed build. otalite simulates the whole update and reports back, like a build report, before any rollout. A failed pre-flight blocks the rollout until someone overrides it.
Planned
Boots, checks in, verifies its signature, installs and rolls back cleanly
Update size and delta size
Estimated energy to install it on your fleet
RAM and flash headroom on each chip
Bytes sent per check-in
The chips it is compatible with
Example
$ otalite package build/app.otb
pre-flight · thermo 1.4.2
✓ boots, checks in, verifies its signature
✓ installs and rolls back cleanly
update 212 KB · delta 38 KB
est. install energy ≈0.3 mAh per device
headroom ESP32-C3: RAM 61 KB · flash 1.2 MB
per check-in 312 bytes
compatible ESP32-S3 · C3 · C6
advisories none matched (best-effort)
Example data · energy figures are estimates
In the CLI output, as a GitHub check on the pull request or commit, in the dashboard, and in Discord. Simulators can't measure real power: its energy figures are estimates. Device Lab boards give measured numbers. The report also lists vulnerability advisories (Planned): known CVEs in the release's firmware and packages.
Wait or force

You choose when to roll out.

The battery projection and the pre-flight report take minutes. Wait for them, start now and let them catch up, or skip them on purpose.
Planned
1
Recommended

Wait for the projection

The rollout starts once the report is ready.
2
Middle option

Roll out now

Analysis keeps running; the next wave waits if the release looks worse.
3
Lighter option

Force

Skips the analysis. Needs an admin and a passkey, and is recorded.
Forcing skips the analysis: the danger is that your first real devices become the test, and we offer no protection against that.
otalite Device Lab

Wave 0, on our hardware.

Every release can run on our own boards and simulators before it reaches a single customer device.
Planned

Real boards on power monitors

ESP32, S2, S3, C3 and C6 on power monitors: real current through boot, check-in, install and rollback.

Simulators on every release

QEMU and the MicroPython Unix port: quick checks that a release boots and rolls back. No power figures.
Recommended
Lab boards are isolated: they reach only otalite's endpoints, are fully erased between customers, and use throwaway test keys, never your production keys.
Lighter option
Run the lab runner on your own bench, such as a Raspberry Pi with your boards. Your hardware and peripherals are more realistic, but we can't vouch for the measurements, and the runner holds a token for your organization.
Approvals by passkey

A person, a passkey, a record.

The decisions that matter take a passkey: phishing-resistant, and recorded with who and when. From the dashboard, or from your phone.
Planned
Approve a release, open the next wave or pause a rollout from the mobile app
Forcing a rollout past pre-flight needs an admin and a passkey, and is recorded
Agents get no publishing rights by default, and never see or create your release signing key. Device keys are provisioned by the CLI, outside the agent's context. A rollout an agent drafts waits for your approval with a passkey.
Status

Where each piece stands.

Nothing here is available yet. In development is being built for the first release; Planned is on the plan, not started; Exploring is still being researched.
Delivery

Staged rollouts

Waves of 1%, 10%, 50% and 100%, with an automatic pause on failures, and rollback.
In development
Testing

Pre-flight report

Every packaged release simulated end to end; a failed pre-flight blocks the rollout.
Planned
Testing

otalite Device Lab

Every release run on our own boards and simulators as wave 0, before any customer device.
Planned
Community

Follow the build.

otalite isn't available yet. Register your interest to hear first, or join the Discord to see what we're building and tell us what your fleet needs.