Firmbridge Platform.
One platform for devices that run a single application and have to keep running. It comes as two runtimes — you choose by the class of hardware, not by rewriting your software.
Two runtimes, one platform
Some devices are a sealed instrument running off a battery; others need a screen, a camera and a full software stack behind them. Firmbridge covers both, and the choice between them is a hardware decision — your application, and the way you build, deploy and operate the device, do not change.
Firmbridge RTOS
The runtime for sealed, low-power instruments that wake fast and stay up for years. Built on Zephyr RTOS and tuned to the board it ships on.
- Application
- One portable binary
- Delivered
- BLE · serial · USB
- Built for
- Battery life, boot time, sealed enclosures
- Planned
- Rust and Python SDKs
Firmbridge Linux
The runtime for arm64 and x86 single-board and panel computers. An immutable, self-updating container OS that boots straight into your application, fullscreen — with a boot menu and on-screen touch keyboard already there. It runs the same portable binary the RTOS does, and container images when the job needs a fuller stack.
- Application
- The same portable binary, or a container image
- Delivered
- Network · USB
- Built for
- Browser interfaces, cameras, heavier processing
- Planned
- Rust and Python SDKs
Different hardware, the same platform contract — see below.
One platform, with critical systems built-in
The parts you'd otherwise rebuild on every device — handled once, by the platform, on either runtime.
Sleep, wake and power budgets handled for you — not rebuilt for every device.
The application runs in its own protected space, so one fault stays contained.
Signed, verifiable updates kept current — with a safety net if one goes wrong.
Log shipping and remote control built in, for devices working far from a desk.
A clean abstraction over the board's peripherals, behind one stable interface.
A consistent on-device interface layer, the same across the hardware you ship.
Shared at the top, forked at the metal
Each layer rests on the one below. Your application sits on top and only ever talks to the Firmbridge interface — never the raw hardware. The top two layers are the same whichever runtime you're on; the stack forks only where the platform meets the board. That is how we keep firmware-grade reliability and security at the platform layer while preserving software-level portability and update speed.
The software you write — one portable build, running on every device below, and the only thing that changes often.
What your code is written against, so it is written against the platform rather than the board.
Power, memory and protection, updates, logging, security, hardware interfaces and UI — tuned per board.
The same responsibilities on a container OS, with the application running in its own isolated image.
One contract, two runtimes
What makes these one platform rather than two products is the interface between them. Both runtimes present the same one: system control, persistent settings, A/B slot management, application upload and live log streaming. The same tooling drives either — pushing an application to a microcontroller and to a Linux device is the same operation, not two integrations.
That interface is a written contract with a conformance suite behind it, and both runtimes are tested against the same recorded sessions — so the two implementations cannot quietly drift apart.
Your integration, your fleet tooling and your operating procedures survive a change of hardware class.
Not a desktop stack in a device shell
Firmbridge is designed for single-application devices, not general-purpose computing — and that holds on both runtimes. No desktop shell, no multi-user session model, and no unnecessary background ecosystem.
Less CPU and memory spent on platform noise, more on your application.
Efficient runtime behavior supports smaller battery targets on field devices.
Fewer exposed services and tighter control points reduce compromise pathways.
Deterministic behavior for deployments that must remain stable around the clock.
Safe to update by default
New applications are hot-deployed — over the air by BLE or network, or by USB — with no full re-flash and no re-imaging of the device. Each application's signature is checked and the application verified when it's uploaded and again on boot, before it runs, and the previous working version is always kept intact.
How A/B slots work
One slot runs while the other stands by. The new version is written to the standby slot — if it verifies, the device switches to it; if not, the active slot keeps running, untouched. The next update targets whichever slot is now standby. The active slot can also be selected manually — with the device's hardware buttons, or from the boot menu on screen.
If the new version won't stay up
Verification catches a bad artifact; the rollback guard catches a bad application. A version that installs cleanly but then won't keep running is swapped back to the other slot on its own, and a device that exhausts its retries stops in the boot menu rather than looping. On Firmbridge Linux the operating system updates the same way the application does — one slot at a time, rolling back automatically on a failed boot — so the guarantee holds at both layers.
An instant rollback to a known-good application — something firmware-based devices can't offer easily.
Write once, run across the fleet
The application is a cross-platform binary, and one build runs on every Firmbridge device — across different microcontroller architectures and on Linux hardware alike. A sealed instrument and a panel computer run the same application, with no port in between. The same binary runs on the desktop too, which is useful for developing and demoing away from hardware.
Firmbridge Linux also takes a container image where the job needs a fuller stack — its own language, its own libraries, its own device configuration declared by the image itself. Two ways in, one fleet.
Same binary, every Firmbridge device.
Build on Firmbridge
Firmbridge is available as an SDK. Applications are written in C today, with Rust and Python support on the roadmap, and one build targets both runtimes.
Firmbridge Linux takes a container as well, for work that needs a fuller stack: bring whatever language and libraries the job calls for, and the image itself declares how the device should run it.
Firmbridge RTOS is built on the Zephyr RTOS, used under the Apache License 2.0. Zephyr and Zephyr Project are trademarks of the Linux Foundation. Zephyr Project, a Linux Foundation Project — all rights reserved. Firmbridge and Steadrock Systems are not affiliated with, sponsored by, or endorsed by the Zephyr Project or the Linux Foundation; references to Zephyr are for identification only.
Firmbridge Linux is built on Flatcar Container Linux, a Cloud Native Computing Foundation project. Flatcar Container Linux is a trademark of its respective owner. Firmbridge and Steadrock Systems are not affiliated with, sponsored by, or endorsed by the Flatcar Container Linux project, the Cloud Native Computing Foundation or the Linux Foundation; references to Flatcar Container Linux are for identification only.