Zephyr vs FreeRTOS for IoT in 2026: Memory Footprint, Ecosystem, and DevEx Compared

Most “Zephyr vs FreeRTOS” comparisons you’ll find were written in 2022. They’ll tell you FreeRTOS is lighter, Zephyr is more full-featured, and “it depends on your use case.” Then they leave you exactly where you started.

Here’s the problem: both of those claims have shifted significantly. Zephyr’s 4.x LTS line has aggressively pruned its minimal kernel footprint. FreeRTOS has bolted on coreMQTT, corePKCS11, mbedTLS integration, and SMP support, making its “lightweight” reputation harder to defend at the system level. If your mental model is from 2023, you’re making a 2026 decision on stale data.

This article compares both RTOSes on three axes that actually determine project success: memory footprint, ecosystem breadth, and developer experience. The scope is MCU-class devices only: Cortex-M, RISC-V RV32, 64–512 KB flash. If your device runs Linux, you’re in the wrong article. If you’re choosing an MCU for IoT in 2026, read that guide first, then come back here.

I have a recommendation at the end, and it’s not “it depends.”

Memory Footprint in 2026: The Kernel Number Is a Lie

Every RTOS comparison leads with kernel size. FreeRTOS wins that contest handily: around 9 KB of flash and 2 KB of RAM for a minimal scheduler on Cortex-M4 with GCC 13 at -Os. Zephyr’s kernel-only image lands near 18 KB flash and 4 KB RAM under the same conditions. Case closed?

Not remotely. Nobody ships a kernel-only image. The moment you add networking, crypto, and OTA—the middleware stack that makes an IoT product an IoT product—the gap narrows dramatically. Here’s what the numbers look like on an nRF52840-DK, both compiled with GCC 13, -Os, and stripped of debug symbols:

* FreeRTOS BLE via NimBLE or vendor SDK, not a first-party integration. Numbers are illustrative 2026 ranges based on publicly available release benchmarks; verify against your exact version tags before committing to a BOM.

Two things matter here. First, at the system level, the difference is 15–25 KB of flash and 4–6 KB of RAM. That’s real on a 64 KB RAM part. It’s irrelevant on a 256 KB part. If you’re on the 64 KB RAM cliff, FreeRTOS gives you more headroom, full stop.

Second, Zephyr’s Kconfig system lets you strip subsystems surgically. A disciplined team can prune Zephyr’s image down to within spitting distance of FreeRTOS for a fixed feature set. For FreeRTOS projects on constrained devices, FreeRTOS Memory Management: Which Heap Scheme for Constrained BLE Devices covers optimizing heap allocation to minimize that 2-6 KB RAM difference. But “disciplined” is doing a lot of work in that sentence. The default Zephyr configuration pulls in logging, shell, and device power management scaffolding you may not need. FreeRTOS defaults to almost nothing. The difference isn’t capability; it’s which direction you build from: adding up (FreeRTOS) or trimming down (Zephyr).

The takeaway: Stop comparing kernels. Compare the full system image for your actual feature set. If you need BLE + MQTT + TLS + OTA, the footprint gap is far smaller than the kernel numbers suggest.

Ecosystem and Protocol Support: Zephyr’s Integration Lead

Three years ago, FreeRTOS had a clear ecosystem story: mature kernel, well-documented AWS IoT libraries, and a vast universe of vendor SDKs filling the gaps. Zephyr had ambition and rough edges. That’s no longer the balance.

The critical difference isn’t the feature list; it’s integration testing. Zephyr’s subsystems live in a single source tree and pass CI together. When you enable BLE on Zephyr, the BLE stack, the GATT layer, and the underlying HCI driver are versioned and tested as a unit. On FreeRTOS, you’re assembling pieces from different repositories, often from different organizations, and hoping the versions are compatible.

FreeRTOS’s ecosystem advantage is narrower but genuine: if you’re building exclusively for AWS IoT Core, FreeRTOS + coreMQTT + AWS IoT Device Shadow + OTA via IoT Jobs is a cohesive, well-documented path. Amazon maintains it, Amazon tests it, and the reference implementations are solid. Replicating that exact workflow on Zephyr is possible but requires more integration work.

Silicon vendor support has also tilted. Nordic’s nRF Connect SDK is built on Zephyr. NXP’s MCUXpresso SDK supports Zephyr alongside their proprietary tooling. STMicro, Intel, and Renesas all contribute Tier-1 board support to the Zephyr tree. FreeRTOS remains vendor-neutral in theory, but in practice, every vendor’s FreeRTOS port is slightly different, and you’re dependent on their HAL quality and update cadence.

Developer Experience: Honest About the Learning Curve

This is where Zephyr’s critics have a point, and being honest about it matters more than cheerleading.

Build system. Zephyr uses west (a meta-tool) wrapping CMake, with hardware configuration split across devicetree files and Kconfig options. It is powerful. It is also bewildering the first time you encounter it. A senior embedded engineer who has spent a decade in Keil or IAR will lose a day or more just understanding the devicetree model. FreeRTOS, by contrast, drops into your existing vendor IDE. You add source files, set a few FreeRTOSConfig.h defines, and you have a running scheduler in an hour. That simplicity is a feature, not a limitation.

Debugging. Both support GDB and OpenOCD, so the on-target experience is roughly equivalent. Zephyr adds two capabilities FreeRTOS lacks out of the box: a tracing subsystem (for RTOS-aware trace visualization) and the native_sim target, which compiles your Zephyr application as a native Linux binary for host-side unit testing without hardware. If you value CI/CD for embedded firmware, this is a significant advantage. Zephyr’s twister test runner can script hardware-in-the-loop test suites across dozens of boards. FreeRTOS has no equivalent; you’ll build your own test harness.

Documentation. FreeRTOS’s kernel docs are concise and focused, but the broader ecosystem documentation (coreMQTT, corePKCS11, backoffice AWS integration) is scattered across multiple sites with inconsistent depth. Zephyr’s docs are comprehensive to the point of overwhelming. The sheer volume can make it hard to find the one API page you need. Neither is great. Both are adequate.

Community and governance. Zephyr lives under the Linux Foundation with a vendor-neutral Technical Steering Committee. Contribution velocity is high; over 1,500 individual contributors as of early 2026. FreeRTOS is stewarded by Amazon. Amazon has been a responsible maintainer, but contributions from outside Amazon are lower, and strategic direction ultimately follows AWS priorities. If vendor neutrality matters to your organization’s risk model, this is worth weighing.

The honest summary: FreeRTOS gets you to “hello world” faster. Zephyr gets you to “production firmware with CI/CD, automated testing, and multi-board support” faster. The crossover point is roughly two to three weeks into a project.

Portability: Where the Decision Actually Gets Made

Here’s the scenario that separates these two RTOSes structurally, not just superficially.

You design a product on STM32L4. Eighteen months later, supply chain forces you to second-source on nRF5340. A year after that, you need a RISC-V variant on ESP32-C6 for cost reasons.

On Zephyr, you change the board target in your build command, adjust a few devicetree overlay pins, and rebuild. The application code, your task management, your protocol handling, your sensor drivers, doesn’t change. Devicetree and Kconfig form a hardware abstraction contract. You write to the contract; Zephyr maps it to the silicon.

On FreeRTOS, you rewrite the HAL integration layer for each vendor. The kernel is portable. Everything around it (GPIO, SPI, I2C, DMA, power management) is vendor-specific. You’re maintaining three separate hardware integration layers, each with its own bugs and testing requirements.

This isn’t theoretical. It’s the primary reason Nordic, NXP, and STMicro have invested engineering resources in Zephyr board support. They understand that customers who can port between MCU families easily are customers who stay in the ecosystem by choice, not by lock-in.

The caveat is equally important: if you know with certainty that your product will live on one MCU family for its entire lifecycle, Zephyr’s portability layer is overhead you’re carrying but never using. In that case, FreeRTOS plus your vendor’s mature BSP is simpler, leaner, and perfectly valid.

Picking the Right RTOS for Your 2026 IoT Design

Use this decision logic:

Choose Zephyr when:

• You’re likely to span multiple MCU families
• Your product uses multiple protocols (BLE + Thread, or BLE + LoRaWAN + LwM2M)
• You need host-side testing and scriptable CI/CD from day one
• Your team can absorb two to three weeks of build system learning curve

Choose FreeRTOS when:

• You’re on a single MCU family with a mature vendor BSP
• You’re ultra-constrained (under 64 KB RAM) and every kilobyte counts
• Your cloud backend is AWS IoT Core and you want the shortest integration path
• Your team is small, familiar with vendor IDEs, and needs to ship fast

The editorial stance: For a new, multi-vendor, or protocol-diverse IoT product starting in 2026, default to Zephyr. The portability contract, the integrated protocol support, and the CI/CD tooling make it the stronger long-term foundation. But FreeRTOS remains the right tool when simplicity and minimal footprint are the primary constraints, and there’s no shame in that choice. The worst decision is the one you make from a 2022 blog post.

Before you commit, prototype on both. Same dev board, same baseline feature set. Two days with each will tell you more than any article, including this one.

Common Zephyr vs FreeRTOS Questions: Memory, RISC-V, and LTS Support

Is Zephyr heavier than FreeRTOS? At the kernel level, yes, roughly 2× the flash and RAM. At the system level (RTOS + networking + crypto + OTA), the gap narrows to 10–15%. The right comparison depends on your actual feature set, not the kernel alone.

Can FreeRTOS run on RISC-V? Yes. FreeRTOS has supported RISC-V (RV32) since 2019, and ports exist for ESP32-C3/C6, GD32V, and other RV32 MCUs. However, HAL support varies by vendor, and you’ll handle hardware abstraction yourself.

Which RTOS has better long-term support? Both offer LTS releases. Zephyr’s LTS cycle (currently 4.x) includes two years of security patches under Linux Foundation governance. FreeRTOS LTS is maintained by Amazon with a similar cadence. Neither is at risk of abandonment.

Hubble Network connects your devices directly from a Bluetooth chip to satellite — no gateways, no terrestrial infrastructure. See how it works →