What's New

You can now send logs from your Zephyr devices without sending the log text. Your LOG_INF() calls stay exactly as they are.

Until now, every character of a log message cost bandwidth on the radio, and every format string took flash on the chip. So messages got trimmed, DEBUG got compiled out, and the detail you needed when a device failed in the field wasn't there. With Compact Logs, the device sends only the format string address and the raw argument values, and Spotflow rebuilds the readable message from your firmware's ELF file. Message size now depends on the arguments, not the text.

What you can do

• Write the descriptive message: LOG_WRN("Sensor %u failed after %u retries; check power supply", 7, 3) drops from 90 bytes to 43, the same size as a much shorter log with two arguments.

• Send fewer bytes per log: In our examples, complete log messages are 26 to 52% smaller than formatted CBOR logs.

• Keep DEBUG logs in production firmware: Strip format strings from flash and keep them only in the ELF file. On our OTA sample for NXP FRDM-RW612, a DEBUG build with stripping was smaller than a WARNING build without it.

• Turn on detail only where you need it: Keep the fleet on WARNING and raise the log level from the web app for the one device that misbehaves, without reflashing.

• Skip text formatting on the device: The logging backend sends the arguments as they are.

• Use it from any MQTT integration: The compact logs protocol is documented, so custom integrations can send compact logs in CBOR too.

Get started

1. Enable compact logs: Add CONFIG_SPOTFLOW_COMPACT_LOGS=y to prj.conf. Keep CONFIG_SPOTFLOW_GENERATE_BUILD_ID on (the default) so Spotflow matches each log to the right ELF file.

2. Upload the ELF file for every build: Use Firmware Management, or add it to your release pipeline with the Management API. Upload it before the firmware reaches devices: logs without a matching ELF file show up unresolved.

3. Optionally, strip format strings from flash: Add the lines below. Stripping turns off Zephyr's text log output, so check the UART logging options first.

For setup and the full measurements, see Compact logs with Zephyr and Using Spotflow with resource-constrained devices. Building your own MQTT integration? Follow the compact logs protocol reference.

Check our Roadmap. Join our community on Discord. Follow Spotflow on LinkedIn.

You can now automate Spotflow from your own scripts and CI/CD pipelines. Everything you do in the Spotflow web application is also available through the Management API.

Until now, getting a new firmware version onto your devices meant manual steps in the portal: create the version, upload the image, attach the ELF file so crash reports decode, start the rollout. Skip one, and the first crash from the new version shows up undecoded. Now your pipeline does every step on every release, the same way each time. The guide includes a ready-to-use GitHub Actions workflow.

What else you can automate

• Software Bill of Materials (SBOM) uploads: Upload the SBOM for each firmware version from the same pipeline, so vulnerability tracking always covers what you actually shipped.

• Device provisioning: Create ingestion keys and tag devices from your manufacturing or provisioning systems.

• Alerts and dashboards as code: Create alert rules and dashboards from scripts instead of clicking through the portal.

• Data export: Pull events and metrics into your own reporting tools.

• AI-assisted debugging: Give your AI assistant access to logs, metrics, and crash reports so it can help you find and fix firmware bugs. A dedicated Model Context Protocol (MCP) server is coming soon.

Get started

1. Generate an API key: In your workspace Settings, open API Keys and create a key with the scopes your automation needs. See Authentication.

2. Call the API: Pick the endpoints you need from the Management API reference. For example, this creates a firmware version and uploads its image:

For the full release pipeline, follow the Programmatic access guide.

Check our Roadmap. Join our community on Discord. Follow Spotflow on LinkedIn.

You can now deploy firmware updates over the air, straight from the Spotflow portal. Find a bug in the field, change the code, and roll the fix to every affected device without a truck roll or a site visit.

This closes the observability loop. Alongside logs, crash reports, metrics, dashboards, and alerts, you can now push firmware updates straight to your devices, so you can detect a problem, ship the fix, and verify the result all in one place.

How you can use Spotflow Over-the-air (OTA) Updates:

Deploy from the cloud: Upload a signed firmware image and roll it out to your fleet from one portal, no manual reflashing.

Target with deployment cohorts: Group devices manually or by Device Tags (location, hardware revision, any attribute), so you can pilot on a small cohort, verify the telemetry, then expand to the full fleet. Active deployments also apply to devices added to the cohort later.

Track every device to completion: See which devices succeeded, which are pending, and which failed, and retry the ones that need it.

Roll back automatically: The device boots the new image in test mode first. If your application doesn't confirm it, the next reboot reverts to the previous firmware, so a bad update can't strand a device in the field.

Integrate with minimal application code: The Spotflow device module handles the download, the image swap, and the reboot. Register update callbacks to delay the download or defer the reboot until a safe, idle window. The device-side integration is currently available for Zephyr.

Get started:

• Over-the-air (OTA) Updates Fundamentals

• Deploy OTA Updates — Step-by-Step Guide

• Over-the-air (OTA) updates with Zephyr

• Over-the-air (OTA) updates of external MCUs

Full walkthrough on the blog: Over-the-Air Firmware Updates on Zephyr RTOS with Spotflow

Check our Roadmap. Join our community on Discord.