Product comparison - reviewed 22 September 2026

Meshanics vs RAUC

RAUC is an excellent signed A/B system-image installer for embedded Linux. Meshanics uses RAUC as its qualified whole-system path and adds authorization, fleet rollout, application artifacts, device results, vulnerability exposure, and evidence above it.

Evaluate Meshanics Discuss your architecture

When RAUC fits

Choose RAUC directly when you need a device-local signed system-image installer and will build or integrate the fleet service around it.

When Meshanics fits

Choose Meshanics when RAUC system images must participate in the same fleet, release, policy, and evidence workflow as containers, models, configs, services, and firmware.

Capability matrix

Compare the complete product boundary

Built inConditionalIntegrationOutside core

Capability	Meshanics	RAUC
Trust and identity
TUF metadata with a root pinned on the device	Included Tenant-isolated TUF roles, version and expiry checks, and a root pinned during enrollment	Conditional Signed X.509 bundles with a device keyring, using a different trust model from TUF
Managed or customer-controlled signing custody	Included Non-exportable Cloud KMS keys for managed trust, or customer-controlled offline root and targets keys	Built in The product builder controls bundle signing keys and certificate policy
Per-device cryptographic identity	Included A device-generated private key, certificate enrollment, and mutual TLS for control-plane access	Outside core RAUC verifies bundles locally and does not provide fleet device identity
Immutable artifact identity	Included Registry tags resolve to digests before signing; files and firmware are fixed by signed hash and length	Built in Signed bundles bind the manifest and contained images
Rollout and recovery
Canary waves and approval gates	Included Percentage waves, scheduled windows, and optional approval before the next cohort	Outside core RAUC is a device installer, not a fleet rollout controller
Automatic fleet halt	Included The rollout pauses when the configured device-failure threshold is crossed	Outside core Requires an external fleet service
Health-driven recovery	Included Typed container, model, config, service, firmware, and qualified RAUC recovery contracts	Built in A/B slot installation and bootloader integration are core strengths
Transactional multi-component releases	Included One signed manifest fixes the ordered component set and one device transaction records the outcome	Conditional A bundle can update several slots, but general application-component transactions require product-specific handlers
Installed-state integrity attention	Included The agent remeasures supported active files and container images and reports digest drift	Conditional Bundle verification occurs before installation; continuous active-state remeasurement is outside the core
Artifact coverage
OCI containers on existing Linux hosts	Included Digest-pinned container delivery without replacing the customer's base operating system	Integration Requires a surrounding container delivery and activation system
ML models as first-class artifacts	Included ONNX, TensorRT, and TFLite metadata, compatibility constraints, model slots, and local evaluation	Integration Requires a surrounding model delivery and activation system
Placed configs and systemd services	Included Allowlisted paths, retained prior state, activation checks, and explicit service reload behavior	Integration Hooks and handlers can be product-specific, but this is not a fleet-managed typed artifact workflow
Zephyr and FreeRTOS firmware	Included Signed ESP32-S3 firmware delivery with device-side verification and boot confirmation	Outside core RAUC targets embedded Linux system images, not Zephyr or FreeRTOS firmware
Qualified A/B Linux system images	Included RAUC is the whole-system path when the product image, keyring, slots, and boot policy are qualified	Built in This is RAUC's native boundary
Evidence and operations
SBOM generation and vulnerability matching	Included SBOMs are attached to signed artifacts and matched against release-specific vulnerability ecosystems	Outside core Requires a surrounding supply-chain and vulnerability service
Affected-device correlation	Included Artifact findings are connected to devices reporting the affected installed version	Outside core Requires external fleet inventory and vulnerability correlation
Device-signed release receipts	Included Devices sign release results so the customer can verify what each device reported	Outside core Local install status is available, but fleet device-signed receipts are outside the core
Signed CRA evidence packages	Included Issued dossiers contain byte manifests, signatures, verification keys, and optional retention-locked copies	Outside core Requires a surrounding evidence system
CRA Article 14 incident workflow	Included Revisioned awareness, notification, remediation, and closure records with deadline tracking	Outside core Requires a surrounding product-security workflow
Cloud, on-premise, and air-gap operation	Included Hosted control plane, customer infrastructure, or a site gateway while devices retain end-to-end verification	Integration RAUC runs on the device; hosting, assignment, and disconnected fleet delivery come from another system
Signed webhooks and structured log export	Included Scoped event delivery plus ECS-compatible exports for Datadog, Loki, OpenObserve, and HTTP receivers	Conditional D-Bus, command-line, hooks, and handlers support product integration
Bounded device operational snapshots	Included Recent CPU, memory, network, storage, and agent facts without becoming a full monitoring collector	Outside core Operational fleet snapshots require another agent or monitoring system

Trust and identity

TUF metadata with a root pinned on the device

MeshanicsIncluded

Tenant-isolated TUF roles, version and expiry checks, and a root pinned during enrollment

RAUCConditional

Signed X.509 bundles with a device keyring, using a different trust model from TUF

Managed or customer-controlled signing custody

MeshanicsIncluded

Non-exportable Cloud KMS keys for managed trust, or customer-controlled offline root and targets keys

RAUCBuilt in

The product builder controls bundle signing keys and certificate policy

Per-device cryptographic identity

MeshanicsIncluded

A device-generated private key, certificate enrollment, and mutual TLS for control-plane access

RAUCOutside core

RAUC verifies bundles locally and does not provide fleet device identity

Immutable artifact identity

MeshanicsIncluded

Registry tags resolve to digests before signing; files and firmware are fixed by signed hash and length

RAUCBuilt in

Signed bundles bind the manifest and contained images

Rollout and recovery

Canary waves and approval gates

MeshanicsIncluded

Percentage waves, scheduled windows, and optional approval before the next cohort

RAUCOutside core

RAUC is a device installer, not a fleet rollout controller

Automatic fleet halt

MeshanicsIncluded

The rollout pauses when the configured device-failure threshold is crossed

RAUCOutside core

Requires an external fleet service

Health-driven recovery

MeshanicsIncluded

Typed container, model, config, service, firmware, and qualified RAUC recovery contracts

RAUCBuilt in

A/B slot installation and bootloader integration are core strengths

Transactional multi-component releases

MeshanicsIncluded

One signed manifest fixes the ordered component set and one device transaction records the outcome

RAUCConditional

A bundle can update several slots, but general application-component transactions require product-specific handlers

Installed-state integrity attention

MeshanicsIncluded

The agent remeasures supported active files and container images and reports digest drift

RAUCConditional

Bundle verification occurs before installation; continuous active-state remeasurement is outside the core

Artifact coverage

OCI containers on existing Linux hosts

MeshanicsIncluded

Digest-pinned container delivery without replacing the customer's base operating system

RAUCIntegration

Requires a surrounding container delivery and activation system

ML models as first-class artifacts

MeshanicsIncluded

ONNX, TensorRT, and TFLite metadata, compatibility constraints, model slots, and local evaluation

RAUCIntegration

Requires a surrounding model delivery and activation system

Placed configs and systemd services

MeshanicsIncluded

Allowlisted paths, retained prior state, activation checks, and explicit service reload behavior

RAUCIntegration

Hooks and handlers can be product-specific, but this is not a fleet-managed typed artifact workflow

Zephyr and FreeRTOS firmware

MeshanicsIncluded

Signed ESP32-S3 firmware delivery with device-side verification and boot confirmation

RAUCOutside core

RAUC targets embedded Linux system images, not Zephyr or FreeRTOS firmware

Qualified A/B Linux system images

MeshanicsIncluded

RAUC is the whole-system path when the product image, keyring, slots, and boot policy are qualified

RAUCBuilt in

This is RAUC's native boundary

Evidence and operations

SBOM generation and vulnerability matching

MeshanicsIncluded

SBOMs are attached to signed artifacts and matched against release-specific vulnerability ecosystems

RAUCOutside core

Requires a surrounding supply-chain and vulnerability service

Affected-device correlation

MeshanicsIncluded

Artifact findings are connected to devices reporting the affected installed version

RAUCOutside core

Requires external fleet inventory and vulnerability correlation

Device-signed release receipts

MeshanicsIncluded

Devices sign release results so the customer can verify what each device reported

RAUCOutside core

Local install status is available, but fleet device-signed receipts are outside the core

Signed CRA evidence packages

MeshanicsIncluded

Issued dossiers contain byte manifests, signatures, verification keys, and optional retention-locked copies

RAUCOutside core

Requires a surrounding evidence system

CRA Article 14 incident workflow

MeshanicsIncluded

Revisioned awareness, notification, remediation, and closure records with deadline tracking

RAUCOutside core

Requires a surrounding product-security workflow

Cloud, on-premise, and air-gap operation

MeshanicsIncluded

Hosted control plane, customer infrastructure, or a site gateway while devices retain end-to-end verification

RAUCIntegration

RAUC runs on the device; hosting, assignment, and disconnected fleet delivery come from another system

Signed webhooks and structured log export

MeshanicsIncluded

Scoped event delivery plus ECS-compatible exports for Datadog, Loki, OpenObserve, and HTTP receivers

RAUCConditional

D-Bus, command-line, hooks, and handlers support product integration

Bounded device operational snapshots

MeshanicsIncluded

Recent CPU, memory, network, storage, and agent facts without becoming a full monitoring collector

RAUCOutside core

Operational fleet snapshots require another agent or monitoring system

This is a first-party evaluation guide, not an independent benchmark. "Outside core" means the capability is not part of the product boundary described by the cited sources, not that it is impossible to build around the product. Editions and behavior change, so validate the exact scope with each vendor.

Primary sources

Read the product boundary yourself

The competitor assessment uses public first-party documentation reviewed on 22 September 2026.

01RAUC basic conceptsOfficial documentation ↗02RAUC integrationOfficial documentation ↗03RAUC advanced topicsOfficial documentation ↗04RAUC bundle signingOfficial documentation ↗

Test before choosing

Use your own artifact, device, and failure case

A feature list cannot prove recovery. Run a canary, break its health check, interrupt power during activation, inspect the resulting device record, and verify the exported evidence without relying on the vendor account.

Start with a device Compare all OTA boundaries