When Rapid Prototyping becomes Rapid Deployment

Imagine rolling out a new product idea to your fleet in a day. How about a couple hours? Now imagine rolling out an entire fleet in that same amount of time, and pulling in multiple connectivity types.

Engineers are being asked to do more with less. Many organizations are mandating that their employees “use AI”. Not the most specific dictum, but the sentiment is “be more productive”. And for all the thought pieces on how useful AI coding tools are or are not, the reality is they are improving enough that you can spin up ideas quickly. We continue to try out the process during our own hackathons.

So now you have the core of an idea, a new feature or capability for your customers. For a long time, that meant field engineers plugging a cable into the back of every product and manually updating each device, dealing with the variety of firmware versions that are out there. Connectivity improved some of the “how do I know what’s going on” problems, but not the the “reliable infrastructure to connect with devices” problems. Golioth does that, day in and day out.

Relying on sturdy infrastructure

Golioth has always been focused on delivering secure, reliable infrastructure to IoT device teams, and that continues into 2026. We spent last year improving resilience of our own internal infrastructure and hardening the already-rock-solid base we had in years past. We made changes to our security capabilities, introducing more ways to provision and deploy certificates and manage certificate infrastructure. Importantly, our engineering team also focused on the ease of use aspect of doing so, in order to make it less hassle to hardware and firmware teams that might not be used to X.509 certificate infrastructure. These improvements are ongoing, including a greater focus on large scale PKI providers.

If you decide to build a feature for your device with an LLM, you benefit from our teams’ focus on clear documentation and a range of examples to build upon. Our Management API is the control panel for you or your generative interface in order to orchestrate actions for your fleet; our Console is a practical starting place if you want a standard interface, as well. You can introduce new firmware images directly through the REST API, place devices into test cohorts (critical for those one-off test runs), and deploy and monitor devices as they go through the update process.

If your new device feature is generating a new type of data, you can route it efficiently using our ever-improving Pipelines. New destination examples arise as new services arise, including the bevy of AI processing tools out in the world. Pipelines have continued to take an important role on internal tooling as well, introducing destinations for LightDB State and Logs, as well.

The abundance of choice (of connectivity)

If your next rapid deployment is a device (instead of only a feature for an existing device), Golioth continues to introduce new connectivity options for building out a product. 2025 was the year we officially introduced Bluetooth connectivity to the platform. More generally, this introduced a new distinction between “directly connected” and “indirectly connected” devices. The former normally are devices that have an IP address assigned (think cellular, Wi-Fi, Ethernet, and Thread devices) and the latter are those that require a gateway…but also covers just about every other type of connectivity. We continue to look at transport options for “indirectly connected” devices like CAN, serial, LoRa, and more.

Bluetooth has been a particularly interesting target for new devices, simply because of the range of chipsets and vendors providing solutions. We continue to build upon and fawn over the Zephyr Project, since it enables compatibility across so many solutions. It also is a common RTOS for Bluetooth projects, having its own Bluetooth stack and vendors that build against it.

Golioth continues to refine the capabilities for indirectly connected devices, including our Pouch protocol and the associated SDK. On the cloud side, our APIs are evolving to serve devices that are offline-first, such as Bluetooth devices that only check-in when there is user activity. The examples we build around these application spaces will enable users looking to spin up generative tooling around a Bluetooth application quick, efficient, and easy to deploy.