Transitioning FOTA updates

nRF Cloud now uses Memfault's OTA engine to deliver firmware over-the-air (FOTA) updates. For application (app) updates, your devices keep working just as they do today — no firmware or SDK changes needed. All that changes is how you prepare and deploy an update.

Enablement required

The new FOTA experience is enabled per account as part of a managed rollout — the nRF Cloud Team will let you know when it's scheduled for yours. You can set up Releases and Deployments beforehand; they start serving your devices once it's enabled.

This guide covers application FOTA. For modem firmware, jump to Modem and other firmware types.

What stays the same

For application FOTA, nothing changes on the device side:

No firmware rebuild and no SDK upgrade.
The same device protocols (CoAP, REST, and MQTT) and the same device authentication.
Your devices download and apply updates the same way they do today.

What changes for you

You now work with the following OTA model instead of legacy nRF Cloud bundles and jobs:

Legacy nRF Cloud	New nRF Cloud experience
Firmware bundle	Release (with one firmware artifact)
FOTA job	Deployment — activating a Release
Device group / tag	Cohort (each device belongs to exactly one)
Per-device job execution status	Per-cohort version matrix

See Over-the-Air Updates (OTA) for the full OTA model.

Preparing a release

When you create a Release in the new nRF Cloud experience, three fields have to match your device — otherwise it won't be offered the update:

Software Type — set it to app. Only the app software type gets application FOTA.
Hardware Version — match your device's board exactly. Use the board name your firmware is built for (CONFIG_BOARD, for example nrf9160dk_nrf9160), which is the same value the device reports as its board.
Software Version — make it SemVer-greater than the device's current version. Note the current version and ensure the new firmware's version is higher. See Versioning Schemes for recommendations on versioning.

Then upload the firmware binary (for example app_update.bin). This binary is the signed application update image your build produces.

note

The new nRF Cloud experience stores the binary directly without a manifest, unlike the legacy nRF Cloud where you previously uploaded the bundle .zip which included a manifest file.

You can do this in the web UI ("Create Release" → "Add OTA payload"), or with the Memfault CLI:

memfault --org-token YOUR_ORG_TOKEN \
  --org YOUR_ORG --project YOUR_PROJECT \
  upload-ota-payload \
  --hardware-version nrf9160dk_nrf9160 \
  --software-type app \
  --software-version 1.2.3 \
  build/zephyr/app_update.bin

Deploying the release

Your devices land in the project's default cohort automatically — there's no group-to-cohort migration step. To roll out the update, activate the Release on the default cohort ("OTA Releases" → activate, or memfault deploy-release).

For staged rollouts, additional cohorts, and approval controls, see Activating a Release.

note

Each device belongs to exactly one cohort (the default cohort unless you move it), unlike legacy nRF Cloud groups where a device could be in several.

Modem and other firmware types

Only application (app) firmware uses the path above. Modem firmware updates through a separate project in the new nRF Cloud experience using the Memfault SDK — see Modem Firmware Update (FOTA). Devices with several updatable components can also bundle them with multi-component OTA.

Getting help

If an update doesn't reach your devices, the most common cause is a hardware version mismatch (step 2 above). Need more help?

Contact the nRF Cloud Team or ask on the DevZone community forum.

What stays the same​

What changes for you​

Preparing a release​

Deploying the release​

Modem and other firmware types​

Getting help​