Footprint
1 GB Pi-3 floor
No fat runtime, no libc. One HAL with two backends means the same system runs on
the smallest board and scales up — you maintain one image, not one per SKU.
INDUSTRY PACKET · EMBEDDED & EDGE / IoT
Lean on the device. Locked down by default. Alive in the field.
Appliances · Gateways · Sensor & edge nodes · Kiosks & fixed-function terminals
An edge device has to be small, has to trust nothing it plugs into, and has to keep running when no one can drive out to reboot it. sigilOS is built for all three — the same capability model that secures a workstation runs on a 1 GB Raspberry Pi 3, and a self-healing bootloader means a device can boot hardware the image never shipped a driver for.
The problem
Embedded Linux is powerful but heavy, and its default posture is trust: a compromised component or a malicious USB device often has far more reach than it should. Small RTOSes are lean but give you little isolation and no real OS underneath. And every fleet hits the same wall — a device in the field meets hardware the shipped image can't drive, and now someone has to re-flash it by hand. You end up maintaining a different build per board and praying nothing plugs in that you didn't foresee.
Why sigilOS fits
Untrusted peripherals
Capability-isolated hardware
No ambient authority: a driver or app reaches exactly the device it was handed.
An untrusted USB drive lands in a cap-scoped sandbox and is trusted only on verified diff.
Field resilience
Self-healing agnostic boot
Missing the driver for the hardware it's on? The bootloader brings up the network
and fetches what it needs — loading it for the session or persisting it for next
boot — all from one
boot.json. Architecture →Uptime
Fault-isolated, auto-restart
A crashing component fails in isolation and restarts without taking the device
down — the STABLE pillar, aimed at devices no one can babysit.
One safe language
Zero C on the device
Firmware-to-app in one memory-safe language. The buffer-overflow class that
powers most IoT botnets is absent by construction.
Remote & fleet
SRDX from boot
A capability-secured remote display/control lane, kernel-native — bring up a
headless device and see it from the first boot. SRDX →
Industrial & OT, too
The same properties answer the operational-technology security problem — SCADA/ICS gateways where "verify the artifact, don't trust the source" and hard isolation matter more than raw features. The functional-safety framing (IEC 61508) lives in the Safety-Critical packet; the security-and-resilience framing is here.
Where we actually are — no hype
- sigilOS boots on real x86-64 hardware; the capability model, fault isolation, and USB-quarantine trust model are real in-tree.
- IN PROGRESS Raspberry Pi 4B bring-up and the unified one-image board-detect (Pi 3B→4B→5) are active work, in the open on our blog.
- IN DESIGN The self-healing agnostic bootloader +
boot.jsonare specified and being built — see the architecture doc. - NOT YET Pre-1.0. We're a fit for teams designing their next device generation, not a drop-in for a fleet you need to ship next month.
Who this is for
Product teams building appliances, gateways, kiosks, or edge nodes who are tired of the per-board-image tax and the trust-everything default — and who want a device that heals itself in the field instead of demanding a truck roll. If you need it shipping in volume this quarter, that's not us yet; if you're architecting the next generation, we should talk.
Building a device that has to be lean, locked down, and unattended?
The agnostic bootloader All packets