TL;DR:
- Golioth is a managed cloud platform for IoT device operations — OTA firmware updates, device state management (LightDB State), time-series data streaming (LightDB Stream), and remote logging, all accessible via REST API and device SDKs
- The SDK integrates natively with Zephyr RTOS but also supports ESP-IDF, Arduino, and bare-metal targets; authentication uses device certificates or PSK for lightweight devices
- For teams shipping more than a few dozen IoT devices, Golioth eliminates the need to build and maintain your own MQTT broker, OTA backend, and device management API — the alternative to not using a platform like this is typically many months of backend engineering
Most embedded firmware developers know how to make a device work. The harder problem is making a fleet of devices work over time — pushing firmware updates without breaking devices in the field, collecting sensor data reliably, diagnosing failures remotely, and managing credentials across hundreds or thousands of endpoints.
The standard path for handling this has been to build it yourself: stand up an MQTT broker, write an OTA update service, build logging infrastructure, create a device management API. This is substantial backend work that has nothing to do with your core product. Golioth is a managed platform that provides all of this as a service, designed specifically for embedded systems teams.
What Golioth Provides
Golioth’s platform has five core capabilities:
OTA Firmware Updates (OTA) — schedule and deploy firmware updates to devices or device groups. Golioth manages the rollout, tracks which devices have successfully updated, handles partial rollouts, and supports rollback if a bad update is detected. Updates use delta compression where supported to minimise data transfer on bandwidth-constrained cellular or LoRa links.
LightDB State — a per-device key-value store for device configuration and state. Think of it as the digital twin for your device: the desired state (what you want the device to do) and the reported state (what it is actually doing) are both stored and synchronised. When a device reconnects after being offline, it pulls the current desired state immediately. This replaces the common pattern of building a custom MQTT topic hierarchy for device configuration.
LightDB Stream — a time-series data pipeline for sensor telemetry. Devices publish readings to LightDB Stream, which is queryable via REST API and supports streaming output to external systems (S3, BigQuery, Databricks, custom webhooks). For most IoT products, this replaces the need for a self-managed time-series database and ingestion layer.
Remote Logging — devices can emit structured log messages to Golioth at runtime. These appear in the Golioth console and are queryable via API. For diagnosing field failures without physical device access, this is the most immediately useful feature — the alternative is typically waiting for a device to be returned.
Remote Procedure Calls (RPC) — invoke commands on a device from the cloud. Trigger a sensor reading on demand, request a device restart, change operational parameters at runtime. Responses are returned asynchronously.
Protocol and Connectivity
Golioth uses CoAP over DTLS for the device-to-cloud transport by default — a deliberate choice for constrained devices where MQTT’s TCP connection overhead is too expensive. For devices with more capable TCP/IP stacks, MQTT over TLS is also supported, as is WebSocket for browser-based devices.
Device authentication uses X.509 certificates for production environments or Pre-Shared Keys (PSK) for development and for extremely constrained devices that cannot handle certificate operations. The Golioth CLI handles credential provisioning for development; a device provisioning API supports factory programming workflows for manufacturing at scale.
Zephyr Integration
Golioth’s native SDK is a Zephyr module. For teams already using Zephyr RTOS — which has become the most widely adopted RTOS for new IoT designs in the past few years — adding Golioth is a west manifest entry:
# west.yml
manifest:
projects:
- name: golioth-firmware-sdk
url: https://github.com/golioth/golioth-firmware-sdk
revision: main
path: modules/lib/golioth-firmware-sdkOnce integrated, the SDK provides Kconfig options and device tree bindings for the Golioth connection. Connecting a device and starting to push data is a few dozen lines of C:
#include <golioth/client.h>
#include <golioth/lightdb_stream.h>
static void connected_handler(struct golioth_client *client,
enum golioth_client_event event,
void *arg) {
LOG_INF("Golioth connected");
}
int main(void) {
struct golioth_client_config config = {
.credentials = {
.auth_type = GOLIOTH_TLS_AUTH_TYPE_PSK,
.psk = {
.psk_id = CONFIG_GOLIOTH_SAMPLE_PSK_ID,
.psk_id_len = strlen(CONFIG_GOLIOTH_SAMPLE_PSK_ID),
.psk = CONFIG_GOLIOTH_SAMPLE_PSK,
.psk_len = strlen(CONFIG_GOLIOTH_SAMPLE_PSK),
},
},
};
struct golioth_client *client = golioth_client_create(&config);
golioth_client_register_event_callback(client, connected_handler, NULL);
/* Push a temperature reading */
char buf[64];
snprintf(buf, sizeof(buf), "{\"temp\": %.2f}", read_temperature());
golioth_lightdb_stream_set_json_async(client, "env", buf, strlen(buf),
NULL, NULL);
return 0;
}Golioth also provides a Hardware-in-the-Loop (HIL) test runner for CI that runs firmware tests on real hardware connected to Golioth’s testing infrastructure — a practical addition for teams that want CI-integrated device testing.
Non-Zephyr Support
For teams not using Zephyr, Golioth provides:
- ESP-IDF component for ESP32-series devices — the most popular microcontroller family for connected products
- Arduino library for prototyping and simpler applications
- C SDK as a portable base layer for integration into other RTOS environments (FreeRTOS, ThreadX) or bare-metal systems
- Python SDK for edge devices running embedded Linux (Raspberry Pi, industrial gateways)
The feature parity between targets varies. Zephyr gets first-class support and all features. ESP-IDF and the C SDK are close behind. Arduino support covers the core features but not advanced OTA or RPC capabilities.
What You Get via the REST API
Everything on the device side is accessible from the cloud via a REST API. Useful patterns:
- Query a device’s last reported state:
GET /v1/projects/{project}/devices/{device}/data/lightdb/state - Retrieve time-series sensor data:
GET /v1/projects/{project}/devices/{device}/data/lightdb/stream - Trigger a firmware update:
POST /v1/projects/{project}/releases - List all devices by firmware version:
GET /v1/projects/{project}/devices?filter.fields.firmware.version=1.2.0
The API is what connects Golioth to your product backend, dashboard, or operations tooling. Device management events can also be pushed to your backend via webhooks.
Pricing
Golioth operates a freemium model. The free tier supports up to 50 devices with 1GB of data per month and full access to all platform features — workable for development, small pilot deployments, and prototyping.
Paid tiers start at roughly $0.50—$1.00 per device per month depending on volume, with data transfer billed separately at cloud-provider data rates. For a fleet of 1,000 devices, annual platform costs run in the range of $6,000—$12,000 — meaningfully less than the engineering cost of building and maintaining equivalent backend infrastructure.
Golioth vs. Building Your Own
The comparison is not Golioth vs. AWS IoT Core or Azure IoT Hub — it is Golioth vs. the custom backend you would otherwise build on top of those platforms.
AWS IoT Core handles device connectivity and message routing, but does not provide device state sync, structured OTA management, or a device-optimised data query layer out of the box. Teams typically build these on top of IoT Core using DynamoDB, Lambda, and custom OTA workflows — which is significant additional work and ongoing maintenance.
Golioth’s opinionated data model (LightDB State and LightDB Stream) covers the common cases without requiring you to design a data schema for basic device management. For early-stage products or teams without dedicated backend IoT engineering capacity, this is a large productivity advantage.
The cases where a custom backend makes more sense: extreme data volumes where custom infrastructure is more cost-effective, proprietary protocol requirements that Golioth cannot accommodate, or organisations with existing IoT backend investments that are more complete.
For teams shipping a new connected product in 2026 without an existing backend, Golioth significantly reduces the time to having a managed, observable fleet in production.