Choosing an update path

Three ways an update can reach a device:

	Agent package	System image	Custom firmware
What gets updated	Applications, services, the agent itself	The whole root filesystem	Whatever your firmware does with the file
On the device	Connhex Edge, plus an update.sh you write	SWUpdate or RAUC, no Connhex software	Any HTTPS client
Guide	Agent package updates	System image updates	The update protocol

Agent package

If your devices already run Connhex Edge, this is the shortest way to update them. You upload a zip holding a script, and the agent takes care of polling, resumable download, integrity checks, extraction, execution and rollback. Nothing has to be built into your image.

What it will not do is replace the operating system. The agent runs inside the system it would be flashing, so there is no bootloader arbitration, no A/B slot, and no way to distinguish a system that boots but is broken from one that works. Use it for what runs on top of the OS.

System image

If you build your Linux image with Yocto, you can include SWUpdate, the standard open-source updater for embedded Linux. Connhex speaks the hawkBit DDI protocol that SWUpdate's Suricatta module talks natively, so a device connects with a URL and either its enrolled certificate or its per-device OTA token.

This is the path that gives you atomic whole-image updates.

In exchange, your image provides the A/B layout, the bootloader fallback logic, your signing keys and a boot-success check. That is standard SWUpdate integration, the same work a self-hosted hawkBit would ask of you. rauc-hawkbit-updater is also supported.

Custom firmware

Microcontrollers and anything with its own stack use the plain HTTP poll: one request to check, one to download, with Range support so a device can resume across power cuts. Connhex serves the file you uploaded and what happens next is your firmware's business.

Running both

Gateway products often want the OS updated safely and their applications updated quickly. Run both: SWUpdate owns the root filesystem, Connhex Edge owns everything above it, and each gets its own firmware and its own campaigns.

The device enrolls once and both use that identity. On the device the two updaters never touch each other, and Connhex keeps them apart on the server side: an image campaign and a package campaign on the same device queue instead of overlapping, so a reboot can never land in the middle of an update.sh.

Which one fits

• Linux gateway already running Connhex Edge, updating your own services: agent package.
• Product where the OS itself has to be updated safely: system image, with the agent inside it if you also want remote access and telemetry.
• Microcontroller, or a stack that is neither of those: custom firmware.
• Already running SWUpdate against a hawkBit server: system image. Your partitions, boot logic, signing keys and .swu pipeline stay exactly as they are.