So you need to add microcontrollers to your fleet: now what?

Wait 5 sec.

Your Ubuntu Core fleet is running beautifully. OTA updates roll out in minutes. Every device is strictly confined, cryptographically attested, and carrying a 10 to 15 year long term support (LTS) commitment. The operational team sleeps soundly.Then the product roadmap meeting happens. The industrial floor needs vibration sensors on every motor. The smart building needs temperature nodes in every room. The cold chain system requires dozens of low-power Bluetooth tags. And someone just said the words: “we need these on a coin cell.”You’ve just crossed into microcontroller (MCU) territory and your Ubuntu Core gateway is about to get a new best friend.The challengeUbuntu Core excels at managing Linux-class edge devices: CPUs and MPUs with an OS, a filesystem, and real RAM. Microcontrollers address a different challenge: less than a MegaByte (MB) of flash, a Real Time Operating System (RTOS), milliwatt power budgets, and bespoke firmware. These two worlds need to coexist in virtually every real-world IoT deployment and now they can, seamlessly. Why microcontrollers go where Linux can’tMicrocontrollers are a deliberate engineering choice for the outermost edge of your infrastructure and are typically used for constrained environments: limited power access, limited communications, small spaces, plus time and temperature sensitive environments, etc. An MCU like the Nordic nRF52840 or an STM32-series device can run for years on a small battery, wake in microseconds to sample a sensor, and return to sleep, for a relatively low hardware cost. Linux-capable SoCs would require outlandish compromises to get even close to that power profile.In industrial IoT, the typical deployment layers microcontrollers – handling real-time sensing and actuation – underneath Linux-based edge computers doing aggregation, AI inference, and local logic. These feed back to cloud infrastructure for fleet-wide management. How do you manage, update, secure, and observe thousands of MCU nodes with the same confidence you have in your Ubuntu Core fleet? How do you push a firmware fix at 2AM to 10,000 temperature sensors in the field? How do you rotate certificates on a device with 256KB of flash?That’s exactly the problem Golioth was built to solve. As a part of the Canonical stack, developers now have an end-to-end solution that runs from MCUs to apps. Meet Golioth: device management for the tiny half of your fleetGolioth is a cloud platform and firmware SDK built specifically for microcontroller-class devices. Where Ubuntu Core brings order to your Linux edge layer, Golioth brings the same operational discipline to the MCU layer beneath it. Together, they cover the full stack from the smallest sensor node to your enterprise cloud infrastructure.The foundation is the Golioth Firmware SDK, which often runs alongside the Zephyr Real Time Operating System (RTOS). This open source project has become the de facto standard for connected MCU development. Think of Zephyr as the Linux of microcontrollers: a kernel, a hardware abstraction layer, a thriving ecosystem of board support packages, and a community of tens of thousands of embedded engineers. The Golioth SDK layers cloud connectivity on top, giving you everything from secure device authentication to OTA firmware updates in a package your MCU can actually run.LayerProductComponentsCloudCanonical InfraUbuntu · K8s · JujuCloudGolioth PlatformFleet · Pipelines · APILinux edgeUbuntu CoreGateway Snap · MPU/CPUMCU layerGolioth + ZephyrSensors · Actuators · MCUsHow Canonical and Golioth cover your full fleetWhat Golioth gives youHere’s what the Golioth platform delivers for your MCU fleet, available the moment your firmware includes the SDK: OTA firmware updatesPush firmware to individual devices or entire fleets. Rollback built in. MCUs stay current at scale.Certificate-based securityUnique cryptographic identity per device. Mutual TLS, rotating certs via PKI integrations using OpenID Connect.Real-time data streamsPipelines route anywhere, including LightDB Stream: Golioth’s in house time-series database.Fleet managementConsole + REST API for device health, logs, last-seen, and remote actions across all MCUs.Remote loggingDevice logs streamed via Golioth Pipelines to any destination. No serial cable required in the field.Rapid deploymentPrototype to production fleet in days — build on top of proven, well documented infrastructure that coding assistants love. Where Ubuntu Core and Golioth meetThe most natural integration point is the gateway pattern: an Ubuntu Core device acting as the local hub for a cluster of MCU nodes, forwarding data to the Golioth cloud. Because Golioth’s gateway software is packaged as a snap – the same containerized packaging format used throughout Ubuntu Core – you can deploy it with a single command on any Ubuntu-based edge device. As an example of where Ubuntu Core and Golioth meet, let’s take a demo we ran at Embedded World 2026. In this setup, the Golioth Snap runs as an isolated, strictly confined system process alongside your other Ubuntu Core applications.  The gateway device handles local protocol translation (BLE, serial, Wi-Fi HaLoW, wired, etc), applies Golioth’s Pouch protocol to encrypt and package the data, and forwards it to the Golioth cloud. The MCU nodes never need their own internet connection: they just need to reach the gateway. More about Golioth PouchPouch is Golioth’s transport-agnostic application layer protocol that enables secure and efficient transmission of data between intermittently offline nodes across multiple network hops. Pouch allows for highly constrained MCU devices (< 100 KB flash and memory) to communicate with the Golioth cloud platform, whether directly over protocols like CoAP, HTTP, or MQTT, or indirectly via a gateway over BLE, serial, etc.This architecture scales well. A single Qualcomm Dragonwing™ IQ9 running Ubuntu, for instance, can simultaneously host a heavy-duty local AI model, run your existing business applications as Snaps, and operate as a Golioth gateway for dozens of nearby Bluetooth MCU nodes. Security from MCU to cloud (the regulatory clock is ticking)In 2026, IoT security is no longer a best-practice checkbox. The EU Cyber Resilience Act and evolving US IoT cybersecurity frameworks are creating hard compliance requirements for connected products. Every device in your fleet, including that $4 MCU on the factory floor, needs demonstrable, auditable security features.Canonical and Golioth address this at every layer:Device identity: Every Golioth device is provisioned with a unique certificate at manufacturing time. No shared secrets, no default credentials.Certificate rotation: The Golioth Firmware SDK supports rotating device certificates via external PKI providers, authenticated with OpenID Connect which is automated credential hygiene even for field-deployed MCUs.Encrypted transit: CoAP over DTLS for connected MCUs, Pouch end-to-end encryption for Bluetooth nodes. Data is encrypted before it leaves the device.Ubuntu Core confinement: The gateway layer benefits from Ubuntu Core’s immutable, strictly confined architecture. Each Snap is sandboxed, preventing lateral movement even if one component is compromised.Audit trail: Golioth’s Management API provides a programmatic interface to query the state, last-seen, firmware version, and log history of every device for compliance reporting.Together, these properties mean you can demonstrate to auditors, customers, and regulators that every device in your fleet, from the Ubuntu Core gateway to the smallest Bluetooth sensor node, has a known identity, a current firmware version, and an encrypted communication channel.Golioth and Ubuntu Core are built on open sourceGolioth and Canonical share an open source philosophy. Both companies believe the best infrastructure for long-lived devices is built on open standards, maintained by active communities, and designed to outlast any single vendor relationship.The Golioth Firmware SDK is open source. Ubuntu Core is built on open source foundations. The Snap packaging format is public. When you build your MCU firmware on Zephyr + Golioth running under an Ubuntu Core gateway, you’re choosing a stack with no proprietary lock-in at any layer.Your IoT products need to run for a decade or more. The infrastructure underneath them should be able to make the same promise.What this means for Ubuntu Core customersIf you’re already running Ubuntu Core at the edge, adding Golioth for your MCU layer means you’re extending the same operational model including OTA updates, fleet visibility, and strict security to every device on your network, regardless of whether it runs Linux. One team, one console, one support relationship, all the way to the sensor.Want to discuss your IoT needs?Tell us about your MCU use case and we’ll connect you with a solutions expert who can map out the right architecture for your deployment. Talk to Canonical about your MCU use case