A pool of services running on your Linux devices that takes care of everything involved in exchanging data between the field and the cloud.
Built into the agent
Connhex Edge is the single agent that ships with every device and handles connectivity, storage, intelligence, updates, observability and remote operations out of the box.
Multi-protocol cloud connection with automatic fallback from MQTT to WebSocket to HTTPS.
Local durable buffer captures every message when offline and replays them in order on reconnect.
A built-in JSON mapper reshapes messages on their way out. Rename fields, drop noise, or convert to SenML.
Staged firmware updates with integrity checks and automatic rollback. Zero-touch fleet-wide rollouts.
Built-in CPU, memory, disk and network metrics, plus custom probes against your own sensors, files or scripts.
Remote terminal, service-level health, and one-click diagnostics. Field devices stop being black boxes.
Connhex Edge handles cloud connectivity, provisioning, updates and data pipelines so your firmware can focus on what makes your product unique.
Split your device firmware into separate services and never look back. This allows you to integrate Connhex Edge as much as you need - from only using its communication capabilities to leveraging its most advanced functionalities through addons.
Create a complete application by coding only your custom services: Connhex Edge takes care of everything else.
Looking for a lighter package, that can run on microcontrollers? We are creating Connhex Micro!
Discover Connhex MicroConnhex Edge is perfectly integrated with Connhex. Start the agent on your device and it'll begin exchanging data with the cloud without missing a beat - or a bit, that is.
This also means you can seamlessly manage configurations, certificates, monitoring and updates from Connhex Control.
And yes, the connection is automatically encrypted and secured through certificates using MQTTs and HTTPs.
Drastically reduce time to market for your new products by developing functionalities on top of an industrial-grade backbone.
We already took care of all the common features an IoT product should have - you can concentrate on what makes your application unique.
A few examples? Your devices will automatically download their configuration files remotely: no need to flash those while manufacturing the device. Every message sent from your devices will be automatically compressed to reduce data transfer rates. And so on.
Running onFlaky cellular. Hostile firewalls. Week-long outages. Connhex Edge is built to keep producing and delivering data through all of it.
Intelligent transport routing
The agent starts with high-throughput MQTT over TLS. If a firewall blocks port 8883, it reconnects over a WebSocket tunnel. If even that is restricted, it falls back to HTTPS REST. All automatic, all encrypted, no messages lost during the switch.
mTLS by default
Every device gets a unique X.509 certificate at provisioning. Connections are mutually authenticated end-to-end.
Firewall-friendly
When MQTT is blocked, the agent tunnels through WebSocket Secure. When even that fails, it falls back to plain HTTPS. Zero configuration.
Zero-touch provisioning
Devices self-register at first boot using their hardware identity. Certificates, channels and configuration arrive automatically.
Offline-first by design
Every event produced on the device is persisted locally first, then forwarded to the cloud. When the link is down, the buffer grows. When the link comes back, it drains, strictly in order and with no duplicates. Your cloud analytics stay correct even after a multi-day outage.
Durable local queue
Messages are persisted to disk as they arrive, not just held in RAM. A power cycle does not cost you data.
In-order, de-duplicated replay
When the link is restored, every buffered event is replayed in the exact order it was produced. No duplicates in your cloud.
Bounded and configurable
Set a retention window and a disk budget per stream. The agent enforces both so you stay in control of storage.
A built-in JSON mapper rewrites every outgoing payload on its way to the cloud, per bridge route. Keep your native format, reshape to what your cloud expects, or adopt SenML for a standard, compact shape Connhex handles natively.
A mapping route
# Rewrite the device payload as SenML on the way out [[bridge.routes]] bus_topic = "sensor.raw" mqtt_topic = "measurements" mapper_query = '[{"n":!"temp","u":!"Cel","v":readings.temperature},{"n":!"pressure","u":!"bar","v":readings.pressure}]'
Rewritten in microseconds, per message.
Device payload in
{ "readings": { "temperature": 23.5, "pressure": 4.3 } }
SenML out
[ {"n":"temp", "u":"Cel", "v":23.5}, {"n":"pressure", "u":"bar", "v":4.3} ]
What you can build
Rename fields, rearrange structures, coerce types. Ship the payload the way your cloud wants it, no firmware changes required.
Already using SenML? Great. Not yet? Map your device-native payload into SenML with a few lines of config: a compact, standard shape Connhex handles natively.
Extract the fields that matter and drop the rest. Less bandwidth, cleaner ingest, nothing pointless leaves the device.
Add constants, metadata and fixed tags to the outgoing payload, with no device code involved.
Run SQL-like queries over live telemetry. Windowed aggregates, joins and complex event processing, all executed on-device in milliseconds.
An example rule
-- Fire an alert when any sensor exceeds 80°C for 3 seconds SELECT device_id, AVG(value) AS avg_temp FROM temperature_stream GROUP BY device_id, TUMBLINGWINDOW(ss, 3) HAVING avg_temp > 80;
Rules live in the device config and hot-reload without a restart. They run entirely on-device, no cloud needed to fire an alert.
Many raw events in, one derived alert out.
What you can build
Trigger a buzzer, shut down a pump, switch a relay, all before the data ever reaches the cloud.
Ship minute-level aggregates instead of raw second-level telemetry. Cut bandwidth by 60× without losing signal.
Combine multiple sensors into new streams: efficiency ratios, energy deltas, anomaly flags. All at the source.
Forward only what matters: events above a threshold, state changes, sessions that last more than N seconds.
Update firmware, watch device health, trace incidents. Connhex Edge ships with the primitives you would otherwise build and maintain yourself.
Over-the-air updates
Publish a new firmware to Connhex Control and the agent handles the rest: detect, download, stage, install, verify. If a step fails, it restores the previous image and reports the reason.
Safe by default
Every update is checked, staged and verified before it goes live. If something fails, the agent rolls back automatically.
Auto or on approval
Choose the mode that fits your risk profile: silent background updates, or wait for a human to greenlight.
Update the agent itself
The agent can update its own binary the same way it updates your firmware. No remote site visit, ever.
System monitor
Connhex Edge continuously streams device health alongside your application data. That gives you one timeline for both: a CPU spike next to the event that caused it.
Built-in, out of the box
CPU, memory, disk, network, running processes and sensor temperatures, collected cross-platform on Linux.
Your own probes
Read a sysfs file. Poll an HTTP endpoint. Run a shell command. Parse the result with regex or JSONPath. Declare it in the config and you are done.
SenML over the wire
Metrics are published in the Sensor Measurement Lists format. Standard, compact, and instantly consumable by the Connhex dashboards.

Remote terminal
Open a remote Linux shell on any Edge through Connhex Control. The tunnel rides MQTT, so you do not need to open a port, set up a VPN, or ship an SSH daemon.
Over MQTT, not SSH
The shell rides the same encrypted channel the agent already uses. No open port on the device, no VPN, no jump host.
Independent of your firmware
The tunnel lives in the agent, so it keeps working even if your application crashes. Perfect for recovering devices when something goes wrong.
Reachable anywhere it boots
If the device is powered and online, you can open a shell on it. No truck roll, no matter where the device lives.
One small step for your firmware, one giant leap towards Connhex.
With Sidecar mode activated, Connhex Edge mirrors every message exchanged by your device with a third cloud instance.
This allows you to keep devices connected both to an existing infrastructure and Connhex at the same time, without changing your firmware.
A typical use case is migrating a fleet of devices already on the field to Connhex. Instead of just updating the firmware and hoping for the best, Sidecar allows you to keep two separate connections active and permanently swap only after the new one has proven to be reliable.
Connect devices with the snap of a finger.
The standard way of installing Connhex Edge involves flashing a unique file for every device, alongside the binary itself. This is then used to establish a secure connection with Connhex Cloud, download additional configurations and automatically register the device.
But what if you don't want to copy a unique file to each device at manufacturing time? Here's where SnapLink comes into play.
Just install Connhex Edge specifying your Connhex's custom SnapLink - yes, it's always the same. Devices will announce themselves to Connhex Cloud and you'll be able to approve their initialization requests from Connhex Control!
Deployment
From a Raspberry Pi to an industrial edge server. A single static binary for any Linux target Go can build, zero external dependencies.
No runtime dependencies to install. Drop it in and launch it.
A Debian package registers the service, enables restart-on-failure, and wires up logs, all in one command.
Runs comfortably alongside your application. Wakes only when something happens.
A readable config file you can ship with the image. The cloud can patch it at bootstrap, so the same image works across sites.
Pair it with the rest of the Connhex platform and get from prototype to production in weeks, not quarters.