cloudparts

Zephyr

A real-time operating system for microcontrollers: the firmware on the sensor, wearable or controller at the edge of an IoT system, with its own networking, Bluetooth and MQTT client, built for more than 1,000 boards.

Linux Foundation project
Type
Open source
Made by
Zephyr Project (Linux Foundation), based on Wind River’s Rocket kernel
Foundation
The Linux Foundation, joined February 2016. A member-funded Linux Foundation project with its own governing board and technical steering committee
License
Apache 2.0
Facts checked
28 October 2026

What it is

In an IoT system, Zephyr is the software on the device. It is a small real-time kernel for microcontrollers and other resource-constrained hardware, from environmental sensors and LED wearables to smart watches and embedded controllers, compiled together with your application into a single firmware image. Kconfig options choose which subsystems go in and how big their buffers are, and devicetree describes the board’s hardware, so the image holds only what the application uses. It supports Arm Cortex-M, -R and -A, RISC-V, x86, ARC and Xtensa, plus Hexagon, MIPS, SPARC, TriCore and a few others, on more than 1,000 boards. The kernel offers preemptive and cooperative threads, an earliest-deadline-first scheduler option, semaphores, message queues and power management, plus memory protection and user-mode threads on Arm, x86 and ARC.

Connectivity is in the tree rather than bolted on: a native IP stack with BSD sockets, an MQTT client for MQTT 3.1.0, 3.1.1 and 5.0 over TCP or TLS, LwM2M for device management, OpenThread, Wi-Fi and a qualification-ready Bluetooth Low Energy host and controller with Mesh. So a Zephyr device is typically the client that keeps an MQTT connection open to a broker such as EMQX or AWS IoT Core. Around the kernel come file systems (LittleFS, FAT, ext2), key-value settings in flash, logging and an interactive shell. The west tool fetches Zephyr and its modules, such as vendor hardware layers, then builds and flashes; native_sim runs the same application as a Linux process for testing.

Major releases come every six months, in April and October: 4.4.0 shipped on 14 April 2026, and 4.5 reached its third release candidate on 22 October 2026. A long-term-support release follows every 2.5 to 3 years and is maintained for about five years; the current one, 3.7 LTS from July 2024, is supported until July 2029, and the next is planned as 4.6 in April 2027. Chip makers build their SDKs on it: Nordic Semiconductor’s nRF Connect SDK, for example, is Zephyr plus Nordic’s libraries and drivers.

Why teams pick it

  • Vendor-neutral and broad: one RTOS, build system and driver model across more than 1,000 boards from many chip makers
  • Networking, Bluetooth LE, MQTT, LwM2M, TLS and file systems come with the kernel instead of being assembled from separate projects
  • Long-term-support releases maintained for about five years, with security fixes and an auditable branch aimed at certification
  • Apache 2.0, so device makers can ship firmware without publishing their own code

Watch out for

  • More to learn than a bare scheduler: an application is shaped by Kconfig, devicetree overlays, CMake and west as much as by its C code
  • APIs keep changing between releases; each release has a migration guide, and a non-LTS release is supported for only about a year
  • A full workspace pulls in many modules and vendor hardware layers unless you limit them with project groups
  • An RTOS for microcontrollers: devices with an MMU that need full Linux processes, drivers and package managers are better served by embedded Linux

Alternatives

What all iot device messaging have in common →Compare side by side →

How it fits with other technologies

samples/basic/blinky: the board’s LED comes from devicetree, so the same code runs on any board with an led0 alias · c

#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>

#define SLEEP_TIME_MS 1000
#define LED0_NODE DT_ALIAS(led0)   /* defined in the board's devicetree */

static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);

int main(void)
{
	bool led_state = true;

	if (!gpio_is_ready_dt(&led) || gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE) < 0) {
		return 0;
	}

	while (1) {
		if (gpio_pin_toggle_dt(&led) < 0) {
			return 0;
		}
		led_state = !led_state;
		printf("LED state: %s\n", led_state ? "ON" : "OFF");
		k_msleep(SLEEP_TIME_MS);
	}
	return 0;
}

Get the code, build for a board and flash it#

From Zephyr’s getting-started guide; west creates a workspace from the zephyr repository’s manifest.

bash
pip install west
west init -m https://github.com/zephyrproject-rtos/zephyr ~/zephyrproject
cd ~/zephyrproject && west update     # fetches Zephyr’s modules and vendor HALs

cd zephyr
west boards                           # list board targets
west build -p always -b <your-board-name> samples/basic/blinky
west flash                            # program the connected board

west build -p always -b native_sim samples/hello_world   # or run it as a Linux process

See it in a real stack

No architecture uses Zephyr yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2001–2026

Zephyr’s kernel goes back to Virtuoso, a real-time OS for digital signal processors from the Belgian company Eonic Systems, which Wind River bought in 2001. In November 2015 Wind River renamed it Rocket and released it as open, royalty-free software for IoT devices; it could fit in as little as 4 KB of memory, where Wind River’s VxWorks needed 200 KB or more.

Linux itself was too big for the smallest IoT devices, so on 17 February 2016 the Linux Foundation launched the Zephyr Project around the Rocket kernel, backed by Intel (with Wind River and Altera), NXP, Synopsys and UbiquiOS. It started with four boards, including the Arduino 101 and NXP’s FRDM-K64F, and with Bluetooth, Bluetooth Low Energy and IEEE 802.15.4 networking. In December 2016, version 1.6 replaced the original nanokernel and microkernel split with a single kernel.

Chip makers and device companies joined as members, and Zephyr became one of the most active RTOS projects on GitHub. Long-term-support releases (1.14, 2.7 and 3.7 in July 2024) gave product makers a base to certify against, and the list of architectures kept growing, most recently with OpenRISC in 4.4 in April 2026. From 2026 the project moved to two major releases a year, in April and October.

Why it’s built this way

Configured and sized at compile time
On a microcontroller with a few kilobytes of RAM there is nothing to spare, so Kconfig and devicetree decide at build time which code and resources exist, and unused features cost nothing.
Hardware described as data, borrowed from Linux
Devicetree describes each board’s peripherals in a file, so one driver serves every board with the same hardware block and the build includes only what the board has.
A permissive licence under a neutral foundation
Apache 2.0 under the Linux Foundation lets competing chip makers contribute drivers to one RTOS while device makers keep their own firmware closed.

Timeline

  1. 2001

    Wind River buys Eonic Systems, maker of the Virtuoso RTOS

  2. 2015

    Wind River releases Virtuoso as the open-source Rocket RTOS

  3. 2016

    Linux Foundation launches the Zephyr Project on 17 February; 1.6 moves to a single kernel in December

  4. 2024

    3.7, the third LTS release, ships in July

  5. 2026

    4.4 in April adds OpenRISC and Zephyr SDK 1.0; six-month release cadence begins

Sources10 · facts checked 28 October 2026

Improve this page on GitHub