Language: EN PL — Polski

Book Demo

The Platform

An operating system built for unattended hardware

HurricaneOS eliminates the complexity between your code and your edge fleet. Push containers, not kernel patches.

The Platform

  1. 01 · Survival

    Built so an unclean shutdown has nothing to corrupt

    The system volume is mounted read-only, so an unclean shutdown has nothing to damage. Updates write to the idle bank and switch only after a health probe passes; if it fails, the bootloader returns to the bank that was working. No operator, no site visit.

  2. 02 · Security

    Hardware-backed identity, locked down by default

    Every device holds its own identity key in a TPM 2.0 — which we require to certify any hardware profile — and the identity is designed so it cannot be copied to another device. Device and cloud authenticate each other with mutual TLS, the firewall denies by default, applications run isolated in containers, and communication ports and other I/O interfaces stay closed until they are explicitly approved. These are table stakes for edge Linux and we treat them that way; where they matter is that they map directly onto RED Article 3.3 and the Cyber Resilience Act essential requirements, set out on the compliance page.

  3. 03 · Operated

    We run the platform. You write the application.

    OS patching, rollout scheduling, health monitoring and failure response are ours, not a console we hand you. Your team pushes code to a repository, every build is CVE-scanned and stored in your own private registry — never public — and it reaches the fleet. Most comparable platforms maintain their OS but leave you to operate it — which means hiring someone who knows embedded Linux, or discovering you needed one.

  4. 04 · Sovereignty

    An EU vendor, for buyers who have to care

    The OS, the control plane and the engineering are ours — built and operated from Poland, hosted within the EEA. For defence, critical infrastructure and NIS2-scoped operators, the jurisdiction of the vendor maintaining your boot chain is a procurement question — and every comparable platform we evaluated answers it from outside the EU. EU rules have teeth now: cybersecurity has been mandatory for new wireless connected products since August 2025, and Cyber Resilience Act reporting since September 2026.

Separately: for teams who need more than running their own code at the edge, we also take on data collection and processing engagements. That is a distinct offering, contracted on its own — it is not part of the OS subscription.

Get Started

See HurricaneOS in action

Book a 30-minute demo, or ask about a trial on a board we certify or a leased unit. No commitment to talk.

Book a Demo

01 / Boot

Watch it boot.

The console output of a complete HurricaneOS start-up, from the bootloader to the login prompt. Unedited, 14 seconds.

tty1 · hurricaneos · boot online
boot → login → online unedited recorded in a VM
Console capture of a HurricaneOS boot, recorded in a virtual machine. Muted.
Two OS slots.
The bootloader chooses between Root A and Root B. A new operating system is written to the standby slot; if it fails to boot, the device falls back to the previous one automatically.
Identity in hardware.
At first boot the device generates its private key inside the TPM 2.0. The key never leaves the chip, so the device cannot be cloned.
Locked down by default.
Deny-by-default firewall, isolated containers, and serial/COM and other I/O interfaces disabled until a capability is granted.

02 / On the device

What's on the device

Four partitions, one of them writable. The system volume is mounted read-only, so a power cut during a write is not a failure mode — there is nothing to corrupt.

What's on the device. Every image carries the same four partitions. The TPM holds the identity; the runtime only grants what an application declares.
Cloud control plane
mutual TLS · TPM-backed identity

Edge device

Application runtime
  • Isolated containers
  • Deny-by-default firewall
  • I/O disabled by default
  • Hardware via capability broker
TPM 2.0 Hardware identity key generated inside · never leaves

Disk · eMMC or NVMe/SSD · ≥ 16 GB

  1. EFI Bootloader selects slot A or B
  2. Root A Operating system running
  3. Root B Operating system standby — next OS update
  4. Data Apps, images, identity survives OS updates

Data — expands to fill the disk on first boot

Drawn from the HurricaneOS user manual.

Why two banks.
An update never touches the running system. It is written to the idle bank, verified, then booted. If the health probe fails, the bootloader falls back to the bank that was working.
Why read-only.
Field failures in unattended hardware are dominated by filesystem corruption after unclean shutdowns. Removing write access to the system volume removes the class of failure.
Why keys in hardware.
The device generates its identity key inside the TPM 2.0 chip and the key never leaves it, so the identity is designed not to be copied to another device.

03 / OS updates

An OS update that falls back instead of bricking

Operating-system updates are delivered over the air by Global Storm only. Application data is never touched.

An OS update that falls back instead of bricking. Operating-system updates are delivered over the air by Global Storm only. Application data is never touched.
  1. 1 OTA image arrives delivered by Global Storm
  2. 2 Written to the standby slot running slot untouched
  3. 3 Bootloader switches slot EFI selects the new OS
  4. Boots?
    • yes Runs the new OS
    • no Falls back to the previous slot — automatically

Data partition: never touched by an OS update

Drawn from the HurricaneOS user manual.

04 / Delivery

From git push to a running container

You never SSH into a device to deploy. A new build never ships by itself — you choose which build goes live.

From git push to a running container. You never SSH into a device to deploy. A new build never ships by itself — you choose which build goes live.
  1. Your team: 01 · git push Push to the connected branch standard Git
  2. Global Storm cloud: 02 · build Multi-arch image Intel + ARM, per service
  3. Global Storm cloud: 03 · registry Private registry your images are never public
  4. Global Storm cloud: 04 · scan CVE scan per service, by severity
  5. Your team: 05 · deploy Pick a succeeded build → Deploy manual · 1 device or 10,000 manual gate
  6. Your fleet: 06 · pull Each device pulls its CPU variant attached devices only mutual TLS
  7. Your fleet: 07 · run Isolated container not installed → installing → running

health · logs · status → dashboard

Drawn from the HurricaneOS user manual.

05 / Control plane

Every device, every version, one view

Fleet state is authoritative in the cloud and reconciled by the device. See every device's health, OS version and running containers, deploy a chosen build to one device or the whole fleet in a single action, and redeploy a known-good build to roll back — without sending anyone to site.

fleet / profiles / partner-industrial-pc 1284 devices
On target version
1276
Staging
6
Rolled back
2
Unreachable
0
DeviceOS versionBoot bankStateLast seen
gs-3f9a21c42.4.1A healthy 12s ago
gs-8b7e04d12.4.1A healthy 34s ago
gs-1c55ba902.4.2B staging 8s ago
gs-d024e7f62.4.1A healthy 2m ago
gs-47ab9e022.3.8A reverted 1m ago

Illustration of a fleet view, not a product screenshot. Device identifiers and figures are illustrative.

06 / Hardware

Three ways to get the hardware under it

Start on certified, off-the-shelf hardware from our hardware partner — the recommended route and already validated against the OS. Or bring your own x86 or ARM platform that meets the requirements. For a few genuinely punishing projects, we build bespoke hardware ourselves.

  1. 01 · Hardware partner

    Start on HurricaneOS-ready hardware from our hardware partner

    The recommended way to start. Industrial gateways, vision nodes, DIN-rail compute and vehicle units from our hardware partner's catalogue — certified off-the-shelf hardware, already validated against the OS. It covers most commercial requirements.

    Industrial PCs and edge gateways from our hardware partner

  2. 02 · Your own

    Bring the hardware you already ship

    64-bit Intel or AMD with UEFI, or a supported ARM board (for example NVIDIA Jetson), in each case with a TPM 2.0 that meets the requirements. The TPM is a requirement, not a preference. We certify it and maintain it from there.

    Intel · AMD · ARM (e.g. NVIDIA Jetson) · TPM 2.0 required

  3. 03 · In-house

    Bespoke builds for special, demanding projects

    For a few genuinely punishing projects — salt spray, sustained vibration, shock and thermal extremes — we design and build the hardware ourselves, because nothing off the shelf survives it. These are MVP-stage, special-project builds, specified per project, not a certified catalogue product. Physical tamper-response options can be specified per project on these builds — scoped to your security requirements, not a catalogue option.

    Sealed aluminium enclosure · designed for shock and vibration · tamper-evident · special projects only

GSE-3 enclosure, connector side: M12 and FAKRA connectors on an anodised panel
03 · In-house · bespoke
Route 03 · GSE-3, a bespoke build for special projects — MVP-stage, not a certified catalogue product.

Requirements and onboarding

Requirements
64-bit x86-64 or a supported ARM board; UEFI boot (ARM boards boot through their vendor firmware); TPM 2.0; about 16 GB or more of eMMC or NVMe/SSD; 2 GB RAM or more; internet access at first boot.
How it starts
You tell us your CPU architecture and boot storage; we build and supply the image for that hardware; your devices are pre-registered with us; each device then provisions itself on first power-on.

Initial bring-up is a deliberate, human-gated project — updates after that are zero-touch.

07 / Alternatives

How we differ from the platforms you're also evaluating

The capable edge-Linux platforms are all good at this. We are not going to pretend otherwise, or claim security features every one of them has. Here is where the choice actually turns.

Scroll the table sideways to see every column

HurricaneOSSnap-based OSContainer-fleet platformModule-vendor OS
Immutable system volume yes: Read-only by design yes: Snap-based yes: Read-only yes: OSTree-based
Automatic rollback on a failed update yes: Bootloader-level, no operator no: Per-snap revert, not whole-image yes: Host OS updates yes: OSTree rollback
Runs on hardware you already ship yes: x86-64 or supported ARM boards with TPM 2.0 — image built and certified per board yes: Certified boards; enablement fee otherwise yes: Supported device-type list no: Built around the vendor's own modules
Who operates the fleet day to day yes: We do — patching, rollouts, monitoring, response no: You do, in your own store and tooling no: You do, in their dashboard no: You do, in their cloud
Vendor jurisdiction yes: Poland — EU no: Non-EU no: Non-EU no: Non-EU

Compiled from each platform's published documentation as of October 2026. All are capable; every one does immutability properly — that is table stakes, not a differentiator; some can be cheaper per device at volume. The distinctions that survive scrutiny are hardware independence and where the vendor sits.

Get started

See HurricaneOS in action

Book a 30-minute demo, or ask about a trial on a board we certify or a leased unit. No commitment to talk.

Book a Demo View Pricing