Canonical, the company behind Ubuntu, acquired Golioth on March 3, 2026. The deal was announced on the Golioth blog by founder and CEO Jonathan Beri, and the financial terms were not disclosed.
If you are running production firmware on Golioth, or evaluating it for a new project, the obvious question is what this means for you. This post is a practical read on what actually changes, what does not, and how to think about the decision.
Full disclosure: we are OmnIoT. We build a full-stack IoT platform, which is a different category of product from Golioth. We will be honest about where Golioth is still the right answer, because recommending a bad fit is how you lose the trust of everyone who does fit. If you came here looking for validation to switch, you might not find it.
What actually happened
Canonical acquired Golioth. The combined pitch, per both companies, is “a complete stack for modern IoT” spanning Zephyr-class microcontrollers up through Ubuntu Core edge gateways and Canonical’s cloud infrastructure. Canonical already has an IoT practice centered on Ubuntu Core, which runs on gateway-class and single-board-computer-class devices. What they were missing was the sensor tier: battery-powered microcontrollers, low-power cellular, over-the-air firmware updates for constrained devices. Golioth fills that gap.
From Golioth’s side, the stated benefits are enterprise support, compliance and regulatory expertise, and the scale of a publicly recognizable brand. IoT products live for a decade or more, and Golioth leadership has said explicitly that they wanted the backing to service customers for that long.
Jonathan Beri’s public statement is worth reading literally: “The Golioth you know and trust will continue doing what we do best.” That is what founders always say at acquisition time. Sometimes it turns out to be true, and sometimes the roadmap quietly bends toward the acquirer’s priorities over the next two years. There is no way to predict which one this will be.
What does not change
The things Golioth is good at are the things Canonical has no reason to disrupt:
- Zephyr-first firmware experience. Canonical is not going to rewrite Golioth’s SDK to target Ubuntu Core; that would erase the reason they bought it. Zephyr support stays.
- Device management, OTA, pipelines, device twin. The core platform capabilities are the asset. They continue.
- Existing integrations. Including the Memfault observability integration, which shipped in 2024 and has nothing to do with Canonical.
If your architecture is “Zephyr on a microcontroller, Golioth managing the fleet, our own backend doing everything else,” none of that is forced to change.
What does change, honestly
Three things always shift post-acquisition, regardless of how sincere the continuity messaging is:
- Roadmap priorities realign with the acquirer. Features that serve Canonical’s strategy get priority. Features that do not, do not. This is not cynicism, it is how parent-company economics work. Expect more Ubuntu Core integrations and less work on features that only matter to non-Canonical users.
- Pricing rationalizes within 12 to 24 months. Typically this means the free tier gets tighter, and enterprise packaging changes. Sometimes existing customers get grandfathered. Watch your contract renewal dates.
- Key people leave on 2 to 4 year earn-out cliffs. The founders and senior engineers usually have retention clauses tied to the acquisition. After those expire, some leave. Institutional knowledge shifts. This is normal, but it is a real thing to plan for.
None of these are red flags. They are just facts about how acquisitions play out. If you are operating a Golioth fleet in production, you should be tracking them.
The gap that Canonical does not fix
Here is the part that matters more than the acquisition: Golioth’s scope was always bounded at the same place, and Canonical does not change that boundary.
Golioth gives you firmware and device management. It does not give you:
- A multi-tenant customer cloud. Your end customers need accounts, scoped permissions, invite flows, role management. Golioth is not that layer.
- A branded mobile app in the App Store and Play Store under your identity. Golioth does not publish apps. You build that yourself.
- End-user workflows like billing, reports, alerts, and dashboards that your customers log into. Golioth has an internal-facing console for fleet operators. That is a different thing.
- Hardware. You pick, source, and certify the devices yourself.
Before the acquisition, if you were building an IoT product, you needed Golioth plus your own backend plus your own mobile team plus a hardware partner. After the acquisition, you still do. The acquisition does not move that boundary.
This is not a criticism of Golioth. They chose that scope deliberately, and they do a good job inside it. But if the gap between “my fleet is managed” and “my customers use my product” has been the painful part of your project, that is a problem Canonical is not going to solve for you.
Three kinds of Golioth team, three answers
Type 1: You love the Zephyr-plus-Golioth model and you run the rest of the stack yourself.
Do nothing. Stay. Monitor for signals: key engineering staff departing, pricing changes at renewal, roadmap stagnation in areas you care about. If those things come up, reassess. Until then, changing platforms for no reason is expensive.
Type 2: You are shipping a connected product and Golioth plus Firebase plus Retool plus your mobile team has felt like too much glue.
This is the group for whom the acquisition is a useful trigger to step back. The integration burden you are carrying is not going to be fixed by Golioth, by Canonical, or by any firmware-focused platform. The real question is whether you are in the market for a firmware tool or a finished product. If it is the latter, a full-stack IoT platform is a different category of answer. We cover the cost math of that choice in depth in our post on the real cost of building on AWS IoT Core, and Golioth is in the same architectural position as the hyperscalers for that purpose: you still own the full product build on top.
Type 3: You were evaluating Golioth and now you are second-guessing.
Do not let the acquisition be the deciding signal. Ask the real question: are you in the market for firmware device management, or for a finished connected product? If you need firmware tooling, Golioth is still a reasonable choice and Canonical’s backing is probably a net positive. If you need a product, no firmware tool was going to be the answer anyway.
What are the real alternatives
Pick based on what you actually need, not on what is in the same SERP as Golioth.
| You need | Reasonable options | Why |
|---|---|---|
| Firmware device management on your own Zephyr stack | Stay on Golioth, or Nordic nRF Cloud (for Nordic silicon), or Blues Wireless, or self-hosted Memfault | Firmware-tier platforms. All in Golioth’s category. |
| Hardware plus firmware SDK, prosumer polish | Particle.io | They own this segment. Not an apples-to-apples Golioth competitor, but a common alternative when the buyer is actually shopping for hardware-plus-SDK. |
| Open-source, self-hosted, Linux-class edge devices | Balena or roll your own on Ubuntu Core | Different device class. If your devices look more like gateways than sensors, this is a better fit than Golioth was. |
| A branded IoT product delivered end-to-end | Full-stack IoT platform or ODM | Different category. You stop evaluating firmware tools and start evaluating who will ship the product. |
The point is that Golioth, Canonical, Particle, Balena, and OmnIoT are not five competing firmware platforms. They are five answers to different questions. The acquisition is a good forcing function to ask which question you are actually asking.
Where OmnIoT fits
We are not a drop-in Golioth replacement, and anyone who tells you otherwise is selling. Golioth is firmware device management you build a product around. OmnIoT is hardware, firmware, multi-tenant cloud, and branded mobile apps delivered together under your brand. You do not integrate OmnIoT into your product; OmnIoT is the product.
That fits some teams and does not fit others. If your competitive advantage is your firmware and cloud architecture, stay on a firmware-focused platform like Golioth. If your competitive advantage is your vertical domain (you understand cold-chain, or aquaculture, or precision ag better than anyone) and the IoT stack is in your way, a full-stack platform or ODM engagement is a different tier of solution worth a conversation.
Talk to us if the second description sounds like you. If the first one does, stay put; acquisitions are usually less disruptive than the blog posts about them suggest.