← Back to articles
News· 3 min read

Canonical brings fleet management down to microcontrollers with Golioth and Ubuntu Core

Escritorio de Ubuntu 26.04 LTS con el entorno de escritorio GNOME
Imagen: Canonical Limited / GPL · Wikimedia Commons

If you run a fleet of Ubuntu devices in the field, you already update them, watch them and keep them in line from one place. That model stopped at the microcontroller layer, though. The tiny chips that drive sensors, valves or radios with a few kilobytes of memory needed their own consoles and their own processes. On 18 June 2026 Canonical announced an integration with Golioth that closes the gap: Golioth’s microcontroller device management platform now ships as a snap inside Ubuntu Core.

How it works: the gateway pattern

Each microcontroller does not talk to the cloud directly. An Ubuntu Core device acts as a local hub for the MCU nodes around it. The Golioth snap runs as an isolated, strictly confined system process, translates protocols (BLE, serial, Wi-Fi HaLoW, wired) and forwards encrypted data to the Golioth cloud.

Canonical’s example makes the point well. A Qualcomm Dragonwing IQ9 can host a heavy local AI model, run your existing business applications as snaps, and operate as a Golioth gateway for dozens of nearby Bluetooth MCU nodes, all on one machine, with the same separation between base system and workload that Ubuntu Core already gives you.

On the microcontroller side, the named examples are the Nordic nRF52840 (which can run for years on a small battery and wake in microseconds) and the STM32 series. These chips run Zephyr RTOS, which the post calls “the de facto standard for connected MCU development” and “the Linux of microcontrollers,” with its kernel, hardware abstraction layer and board support packages.

What Golioth adds

The capabilities are what you would want from serious fleet management, now stretched down to very small chips:

  • OTA updates with rollback. Push firmware to a single device or to an entire fleet, with rollback built in.
  • Certificate-based security. Each device gets its own certificate at manufacturing, and mutual TLS handles certificate rotation through PKI/OpenID Connect. Connected MCUs use CoAP over DTLS; Bluetooth nodes use Pouch end-to-end encryption.
  • Real-time data streaming. LightDB Stream, Golioth’s time-series database, plus Pipelines to route the data.
  • Remote logging. Device logs stream through Golioth Pipelines to any destination, with no serial cable required.

The Pouch protocol and the memory problem

The most interesting piece technically is Pouch, a transport-agnostic application-layer protocol. It moves data securely and efficiently between nodes that go offline intermittently, across multiple network hops, and it does this on devices with less than 100 KB of flash and memory. That is exactly where most management stacks give up.

The limit is not academic. The post frames it with a sharp question: how do you rotate certificates on a device with 256 KB of flash? When you work with less than a megabyte of flash, every byte counts and a heavy client stack simply does not fit.

Why it matters

If you manage hardware in the field, the same Ubuntu Core operating model (OTA, fleet visibility, strict security) now reaches the microcontroller layer without standing up a second management system in parallel. The post also ties the announcement to regulation: the EU Cyber Resilience Act and evolving US IoT cybersecurity frameworks are turning certificate rotation and security updates into hard requirements rather than optional extras.

If you want to understand how the snap format fits into all this, our comparison of Flatpak, Snap and AppImage covers the confinement and packaging this article takes for granted.

Source

Based on the original Canonical post on ubuntu.com/blog. Announcement and technical details: Canonical.