What RelayQ Is
RelayQ is a deterministic edge runtime designed to isolate failure and maintain system stability under unpredictable conditions.
It runs as a single binary, connects directly to field devices, and processes, persists, and delivers data without external dependencies or cross-component failure modes.
System Guarantees
RelayQ is engineered to enforce predictable behavior under failure:
Device isolation
A failing or slow device cannot impact other devices.
Subscriber isolation
A slow or disconnected subscriber cannot stall the system.
Crash consistency
Message state remains consistent across crashes and restarts.
No external instability
No external dependency can introduce runtime instability.
These guarantees are enforced by architecture, not configuration.
These guarantees are enforced through how ingestion, processing, and delivery are designed.
How It Works
Ingestion
- • Connects directly to Modbus RTU/TCP, DNP3, OPC UA and BACnet/IP devices, plus an HTTP ingestion API for non-MQTT sources
- • Raw register and point data transformed into structured MQTT/Sparkplug B topics
- • No separate protocol gateway or middleware needed
- • Each device is handled in isolation, failures from one device do not propagate through the system
Processing
- • Local rules engine evaluates and routes data
- • Built-in historian buffers locally
- • Device shadow tracks last-known state
- • All processing on-device, independent of cloud connectivity
- • Occurs entirely within the same execution boundary, no external service can introduce additional failure modes
Delivery
- • MQTT 3.1.1 and MQTT 5.0 (QoS 0/1/2) to local or remote subscribers
- • Write-ahead log persists every QoS 1/2 message before acknowledgement
- • No message loss on restart or power failure
- • Slow or disconnected subscribers cannot stall the system or affect other clients
Security
- • TLS 1.2/1.3 with optional mTLS
- • Topic-level ACL, default-deny
- • SHA-256 credentials, rate limiting, brute-force protection
- • No OpenSSL, no auth framework, no external dependencies
- • All security mechanisms operate within the same execution boundary
System Architecture
RelayQ operates as a single execution boundary. All components share memory and communicate internally without network or process boundaries.
This eliminates cross-component failure modes, reduces latency, and ensures consistent state across ingestion, processing, and delivery.
Sparkplug B
RelayQ rejects malformed Sparkplug B topics and out-of-sequence node/device lifecycle messages at ingress today, proven in binary-level testing against the signed release tarball. The full per-requirement breakdown against the Sparkplug 3.0.0 specification, including what’s reviewed-but-not-yet-enforced, is in the conformance report.
Topic shape validation
Malformed Sparkplug topics rejected at ingress.
Birth/death sequencing
bdSeq stale-session detection and DBIRTH-requires-NBIRTH order enforcement, rejected at ingress.
Security
All security mechanisms operate within the same execution boundary, no auth frameworks, no OpenSSL; TLS is optional and feature-gated (rustls).
TLS 1.2/1.3 + mTLS
Optional, feature-gated. Certificate revocation and pinning.
One Principal per connection
TCP, TLS, mTLS and WebSocket connections all resolve to the same identity model before any packet is processed.
One Authoriser
Every publish, subscribe and admin action passes one decision point. Default deny; read-only admin mode.
Hash-chained audit file
Every security decision is a SHA-256 chained event with periodic anchors; relayqdev audit verify proves the chain offline.
Hardened profile
A shipped deployment profile: TLS only, credentials required, default-deny ACL, audit on, lockout and allowlist, held to the code by a contract test.
Topic-level ACL
Default-deny. Per-topic read/write permissions.
SHA-256 credentials
FIPS 180-4 password hashing. No external crypto library.
Brute-force protection
Per-IP failure tracking with automatic lockout.
IP allowlist/blocklist
Exact IP and CIDR range filtering.
Ed25519 binary signing
Every release cryptographically verified from build to deployment.
Per-device fleet credentials
Devices enrol with the Command Center over TLS and hold a revocable bearer credential; no shared secrets in the fleet.
Constraints and Boundaries
Active/standby (2-node)
Automatic failover between two nodes. No multi-node clustering (3+ nodes).
MQTT 3.1.1 and 5.0
Implements the OASIS MQTT 3.1.1 and MQTT 5.0 standards on one listener. No proprietary extensions.
Three placements, one runtime
Linux for ARM on resource-constrained hardware in the cabinet; the Windows machine or VM a site already has in its OT zone beside SCADA, DCS, OPC Classic and historians; Windows or Linux in the data centre. Windows is x86_64 only, and not offered for constrained hardware. No macOS support.
Not a SCADA system
RelayQ delivers data to SCADA systems, it does not replace them.
Not a cloud platform
Operates entirely on local infrastructure. No cloud dependency for any runtime function.
Verification
RelayQ’s behavior is validated under adversarial conditions, ensuring guarantees hold under malformed input, concurrency stress, and long-running operation.
4,902 automated tests
With specification traceability.
Fuzz testing
Millions of inputs across protocol codecs, zero crashes.
Model checking
Concurrency validation, zero data races.
Soak testing
Long-duration sustained load, zero message loss.
Runtime Characteristics
Designed for high-throughput, low-latency operation on commodity hardware, while maintaining bounded resource usage and predictable behavior.
Lab measurements on the stated hardware and build. Throughput, latency and footprint depend on hardware, network, configuration and workload; results in your environment will differ. Method and hardware are on the benchmarks page.
Performance characteristics are achieved without sacrificing bounded resource usage or predictable behavior.
Observability
Prometheus metrics
Native endpoint for scraping.
Grafana dashboard
Pre-built, ready to import.
Terminal UI + Command Center
relayqdev dashboard on the node (Full variant); fleet-wide management, OTA and enrolment in RelayQ Command Center.
Health endpoints
Readiness and liveness probes.
Structured logging
JSON output for aggregation.
Deployment
RelayQ is delivered as a compiled, Ed25519-signed binary. Every release is cryptographically verified to ensure integrity from build to deployment.
Runs anywhere
Deploy on bare metal, inside Docker containers, or as a systemd service. The same binary runs identically across all environments.
Minimal deployment
Delivered as a single archive containing the binary, configuration template, and install script. No runtime dependencies, no external services, no package manager required.
Single config file
One TOML file controls all runtime settings.
Hot reload
Send SIGHUP to reload configuration without restarting the process. Active connections remain uninterrupted during reload.
Licensing
- Evaluation: full features, 24-hour runtime per start, no license file needed
- Production: unlimited runtime, hardware-bound license file
Both editions are the same binary. The presence of a valid license file determines runtime behaviour.
OEM Integration
RelayQ can be embedded into third-party products as a runtime component.
Per-device licensing
Licensed per device or per deployment.
Redistribution
Under OEM agreement.
Source access
Under separate written agreement.
Supported Industries
Energy & Smart Grid
Substations, DER, smart metering.
Water & Wastewater
Pump stations, treatment plants.
Industrial Automation
Factory floor, SCADA integration.
Automotive & EV
Charging infrastructure, fleet telemetry.
Medical Devices
Clinical gateways, patient monitoring.
Railway
Trackside, rolling stock, operations.
Evaluate the system under real failure conditions, not just ideal scenarios.
Ready to evaluate RelayQ?
Full-featured runtime. No credit card. Direct support.
Request Evaluation AccessNot ready to talk? Start with the evidence: conformance report · benchmarks