One faulty device shouldn't take down your entire operation.

RelayQ isolates every device so failures stay local. Data keeps flowing to your business systems, through outages, restarts, and misbehaving equipment.

Every device gets its own isolated data path. A slow sensor on Line A can't stall Line B, your cloud ingestion, or anything else. Add 1 device or 1,000; behavior stays the same.

  • Single ~4.6 MB binary replaces gateway + broker + integration layer
  • Runs on hardware you already own, no overprovisioning
  • No acknowledged message lost across power failures, restarts, and network drops
RelayQ Command Center dashboard showing fleet health trend, device status counts, and a staged version rollout
RelayQ Command Center: on-premise control plane for RelayQ fleets (in development) →
Request Evaluation Access How It Works
0
mandatory runtime dependencies
~4.6 MB
entire runtime, single binary
4,902
automated tests, traced to the protocol specifications
6M
malformed inputs, no crashes
0
message loss in soak and power-cut tests
Every number links to its evidence: how we verify · benchmarks & method · conformance report

Sizes and counts are from the current release candidate build (Full ~4.6 MB · Lite ~1.0 MB · ~4.6 MB scratch container · ~4 MB idle, lab). Any throughput or footprint figure on this site is a lab measurement on the stated hardware; results in your environment will differ.

What this means for your role

CTO / VP Engineering

One binary replaces 3–4 edge components. Fewer moving parts, fewer failure modes, faster deployment cycles.

System Architect

Deterministic isolation per client. No shared queues, no global locks. Failures never cross device boundaries.

OT / Platform Engineer

Native Modbus, DNP3, OPC UA and BACnet/IP ingestion. WAL persistence. Deploy beside existing SCADA without changing control logic.

Why OT data programs stall

Fragmented edge stacks create unpredictable behavior, higher lifecycle cost, and slower delivery of trusted data.

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.

Component sprawl

Protocol gateway + broker + integration layer + cloud connector, each with its own firmware, dependencies, update cycle, and cost, 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 properties of the architecture, 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.

A typical OT stack is tightly coupled, when one link stalls, everything upstream and downstream feels it. No isolation between devices, no buffering between tiers, no graceful degradation.

Traditional OT stack, sensors, PLCs, SCADA, and historian in a rigid chain with no isolation

Rigid chain: one stall propagates everywhere

RelayQ sits between field devices and your operations layer, isolating every device into its own execution context. A slow sensor doesn't block a fast one. A disconnected historian doesn't stall field collection.

RelayQ inserted between field and operations, each device isolated, data buffered and forwarded

RelayQ inserted: every device isolated, data keeps flowing

One runtime replaces the gateway, broker, and integration layer, a single execution boundary with no cross-process failure modes.

Read full architecture →

Built into the runtime

Not bolted on.

These capabilities exist inside the same execution boundary, not as separate services.

Reliable Delivery

Messages persist, retry, and recover across failure. Full MQTT 3.1.1 and MQTT 5.0 with dead-letter queue and offline buffering.

Native Protocol Ingestion

Polls Modbus, DNP3, OPC UA and BACnet/IP devices directly, and validates Sparkplug B payloads at ingress. No external gateway hardware.

Crash-safe State

WAL-backed persistence with atomic recovery. No message loss on unclean shutdown or power failure.

Local Intelligence

Rules engine, device shadow, and local historian run at the edge, no cloud round-trip required.

Automatic Failover

Active/standby failover ensures continued operation when the primary becomes unavailable. WAL replication keeps state consistent.

HTTP Ingestion & Bridge

Accept data from non-MQTT sources via HTTP. Bidirectional bridge connects to upstream systems for hybrid architectures.

Security built into the runtime, not bolted on

Nothing external to audit

  • • No OpenSSL, TLS is optional and, when enabled, provided by rustls
  • • No async runtime, no third-party frameworks
  • • std-only core: the code that handles your data is all in one auditable tree
  • • Ed25519-signed binaries, verified from build to deployment

One authentication and authorisation pipeline

  • • Every connection, TCP, TLS, mTLS, WebSocket, resolves to one Principal
  • • One Authoriser decides every publish, subscribe and admin action; default deny
  • • Every decision is a security event in a SHA-256 hash-chained audit file, verifiable offline
  • • Hardened deployment profile, brute-force lockout, IP allowlists, per-device fleet credentials

All implemented within the runtime itself, and exercised by the acceptance suite on every signed release.

Built for systems where failure is not allowed to cascade

Intermittent connectivity · Air-gapped environments · Regulated infrastructure · Unpredictable device fleets

Industrial
Automotive
Energy
Medical
Water
Railway

Intentional boundaries

• Not multi-node clustered, 2-node active/standby maximum

• Not a cloud SaaS platform

• Not multi-tenant

• Linux first, Windows x86_64 packages available; no macOS

Prove it in your environment

Start with a focused pilot: connect real devices, test outage conditions, and validate outcomes with your team in weeks, not months.

Request Evaluation Access Review Architecture
Not ready to talk? Start with the conformance report or the benchmarks.

Developed by Precocity Research, specialists in secure industrial systems and AI data platforms.