Most industrial edge devices run general-purpose Linux or Windows with layers of configuration on top. You install the OS, configure it, add your software, and hope nothing drifts between the image you tested and what is actually running on the floor six months later. When something breaks, you find out from an operator, not a monitoring system.
EmberRTOS takes a different approach. The OS is immutable.
What immutable means in practice
An immutable OS ships as a read-only image. The running system cannot write to the OS layer. Software installations, configuration changes, and patches do not happen in-place on a live device. Instead, a new image is built, validated, and pushed to the device atomically. Either the whole image applies cleanly or the device stays on the previous version and reports the failure.
This eliminates an entire category of problems:
- No configuration drift between commissioning and production
- No "it worked in staging" failures caused by someone touching the device manually
- No partial updates that leave a device in an unknown state after a power loss mid-patch
- No persistent malware that survives a reboot
The Crucible firewall
Every EmberRTOS node runs Crucible, the built-in application firewall. Crucible operates at the process level. Rules define exactly which processes can communicate with which endpoints. Anything not explicitly permitted is denied by default.
This is not a perimeter firewall bolted onto the outside. It is enforcement at the OS level, applied to every process running on the node.
Auto-rollback patching
When a new EmberRTOS image is deployed to a node, the node validates it against a cryptographic signature before applying it. If validation fails, the device rejects the image and reports the error. If the new image applies but the node fails its post-update health check, the device rolls back automatically to the last known-good image.
The result is that you can push updates to a fleet of edge devices without manual intervention at each site, and without accepting the risk that a bad update takes down production.
Two form factors: Edge and Desktop
EmberRTOS ships in two versions.
EmberRTOS runs on edge-class hardware: compact, fanless nodes deployed close to equipment. It handles real-time data acquisition, protocol conversion, and local compute.
EmberRTOS Desktop runs on control-tier hardware: higher-performance machines that act as local servers for a facility. It runs the same immutable OS with the same security posture, at the compute scale needed for historians, MES workloads, and AI inference.
Both connect into the same EmberNet deployment and are managed from the same EmberCORE dashboard.
Why this matters for OT
IT teams have had immutable infrastructure patterns (containers, auto-rollback deployments, read-only images) for years. OT has mostly been left out because general-purpose edge hardware runs general-purpose OS software that was never designed for this model.
EmberRTOS brings the same operational discipline to the plant floor without requiring a rip-and-replace of existing PLCs, HMIs, or SCADA systems. It connects to what is already there and adds a secure, manageable, auditable OS layer that does not require an on-site technician every time you need to update it.
