Originally published at: Balena cycle roundup - March 2026
Another six-week cycle is in the books here at balena, and as always, we are excited to share what we have been working on.
Are you able to provide a bit more information on what the OS update queuing is doing internally? Does this deploy Helios to devices that we queue updates on or is it implemented server side and internally running the same SSH based update process?
For a bit of context on this we’re currently dealing with some devices where we’re not permitted to enable Cloudlink due to client security policies and keeping a keen eye on Helios as from my read it moves the OS update process to the local supervisor and is probably the last missing piece in our ability to fully support that configuration.
@JonWood your assumptions are correct, when Helios is released it will initiate a pull of the target OS rather than the push model of current Supervisors. We’ll be providing more details in the blog as the release date gets closer, and thanks for following along with our progress on this new feature.
I think you’ve answered a different question to the one I asked. My understanding is that we can turn on queuing OS updates now, despite Helios not yet being available for production use, so I’m curious how the current solution is implemented to understand whether its suitable for our needs.
Hi Jon, Queued OS updates are a feature to asynchronously update the OS on a device, including retries. Conceptually the feature is similar to pinning an application or the Supervisor to a particular release.
We are planning two implementations for Queued OS updates: in the back end for devices not running the Helios enabled Supervisor, and on the device for Helios based Supervisors. So far we have released only the back end implementation. This implementation adds a property to the device portion of the API to track the selected OS release. This property means the release can be selected while the device is offline. Then when the device comes online, the backend will trigger the OS update.
The Supervisor already polls the device API periodically for target state. A Helios based Supervisor also will read the selected OS release property and independently pull the release to the device. You are correct that Cloudlink will not be required in this case. Helios is under development, and we will announce when it is ready.