RelayQ is a deterministic edge runtime with a fully conformant MQTT 3.1.1 broker, zero dependencies, and formal verification.

How does RelayQ compare to other MQTT brokers?

RelayQ is a deterministic edge runtime with a fully conformant MQTT 3.1.1 broker, zero dependencies, and formal verification. The <1 MB binary is the entire deployment with no shared libraries required. The container image is ~2.8 MB (scratch, no OS layer). Unlike traditional MQTT brokers, RelayQ controls failure propagation — isolating misbehaving clients so they cannot impact the rest of the system.

Does RelayQ support Sparkplug B?

Yes. RelayQ has 100% Sparkplug B Aware conformance (58 requirements verified). It validates Sparkplug payloads at ingress, catching malformed traffic before it reaches your SCADA system.

What platforms does RelayQ run on?

RelayQ runs on Linux x86_64, ARM64, and ARMv7. The minimal binary is <1 MB, making it suitable for edge devices like Raspberry Pi up to data center deployments.

Is RelayQ suitable for IEC 62443 environments?

Yes. RelayQ's zero-dependency architecture, formal verification, and memory-safe implementation align with IEC 62443 security requirements for industrial automation and control systems.

Chaos at the edge.
Certainty in the runtime.

RelayQ is a deterministic edge runtime that isolates failure and bounds system behavior.
It runs as a single zero-dependency binary with built-in protocol translation and MQTT.

One runtime: Modbus, DNP3, OPC-UA, MQTT — no gateway layer
No external dependencies to trust or patch
No slow or failing device can stall the system

Request Evaluation Access Read Architecture

nothing external to trust or patch

~2.4 MB

entire runtime, single binary

<1 ms

cold start to accepting connections

100%

Sparkplug B validation enforced at ingress

malformed inputs → no crashes

The edge stack fails in unpredictable ways

Each layer introduces independent failure modes, separate dependencies, and cascading fault risk.

Cascading failures

A slow device stalls pipelines. Backpressure spreads system-wide. Failures don't stay contained.

Unbounded dependency risk

Hundreds of transitive dependencies make SBOMs unauditable. Every dependency is a door you can't lock.

Multiple failure modes

Protocol gateway + broker + integration layer + cloud connector. Each with its own firmware, dependencies, and update cycle.

Operational overhead

Combined edge-node costs reach $1,000–$3,000 across hardware, software, and integration before a single message reaches the cloud.

RelayQ is designed to fail safely

Not faster. Not bigger. Predictably.

Slow subscriber

Messages dropped for that client only.

Malformed client

Connection terminated, system unaffected.

Broker restart

WAL replay ensures consistent recovery.

Memory pressure

Controlled shutdown before OOM.

Power loss

WAL protects state with atomic recovery.

These behaviors are architectural guarantees — not configuration choices.

Designed to isolate, not share state

Every client runs in its own isolated context. No shared queues. No global locks. No cross-client contention.

Failure never crosses client boundaries.

The system continues operating even when individual devices fail, stall, or misbehave.

In a traditional stack, every component shares an execution path. When one device stalls or misbehaves, the failure propagates — blocking pipelines, stalling subscribers, and eventually taking down the system.

Shared execution path — failure can propagate

RelayQ inverts this. Each device, each client, each subscriber operates in its own isolated execution path. A slow sensor doesn't block a fast one. A disconnected subscriber doesn't stall a publisher. The system degrades gracefully — never catastrophically.