📡 Mender OTA Update Flow – Explained with Architecture Diagram

Over-the-Air (OTA) updates are critical for managing distributed systems — whether they are Azure VMs, IoT devices, edge gateways, or embedded Linux systems.

The image above illustrates the complete Mender OTA update workflow, showing how updates move from the developer to devices securely and reliably.

Let’s break down the flow step by step.

🔷 1️⃣ Developer – Creating & Uploading the Update

In the top-right section of the diagram, we see the Developer.

This represents:

• DevOps Engineer

• Firmware Engineer

• Platform Engineer

• Release Manager

What happens here?

The developer:

1. Creates an update artifact

   
   

   • Full root filesystem image (A/B update)

   • Application update

   • Script-based update (like apt upgrade)

2. 
   

3. Uses the mender-artifact tool to package the update

4. Uploads the artifact to the Mender Server

5. Creates a deployment targeting specific device groups

Code : to create artifact

mender-artifact write module-image \

-T script \

-n ubuntu-apt-upgrade-v2 \

-t azure_vm \

-f upgrade_os.sh \

-o ubuntu-apt-upgrade-v2.mender

This artifact is then uploaded to the Mender UI.

🔷 2️⃣ Mender Server – Central Control Plane

In the top-left section, we see the Mender Server (cloud icon).

This is the control center of the entire OTA ecosystem.

It handles:

• Artifact storage

• Deployment management

• Device authentication

• Inventory management

• Rollback control

• Status monitoring

The Mender Server can be:

• Hosted (Mender Cloud)

• Self-hosted (Docker-based setup like you are running on Azure VM)

What Happens When Deployment is Created?

When the developer clicks Create Deployment, the server:

1. Matches devices based on device type (e.g., azure_vm)

2. Makes the artifact available

3. Waits for clients to poll

4. Tracks progress

5. Handles rollback if needed

🔷 3️⃣ Devices with Mender Client – Execution Layer

The bottom section shows:

• Edge devices

• Laptops

• Raspberry Pi

• Azure VMs

• Embedded hardware

Each device runs the Mender Client Agent.

How the Client Works

The Mender Client:

1. Periodically polls the server

2. Checks for available updates

3. Downloads the artifact

4. Installs it

5. Verifies the update

6. Reports status back

This is shown in the flow diagram as:

Download Update

Install & Verify

Report Status

🔄 The Complete OTA Flow (Step-by-Step)

Let’s map this clearly to the image arrows:

Step 1 – Upload Update Artifact

Developer → Mender Server

The artifact is uploaded and stored.

⸻

Step 2 – Deploy Update

Mender Server → Devices

The server makes the deployment active.

Devices discover the update during polling.

⸻

Step 3 – Update & Report Status

Devices → Mender Server

The client:

• Downloads the update

• Installs it

• Reboots if needed

• Confirms success

If confirmation fails → Automatic rollback (A/B partition model).

⸻

🔐 Why This Architecture Is Powerful

✅ Secure

• TLS communication

• Device authentication

• Signed artifacts

✅ Scalable

• Works for 10 devices or 1 million

• Deployment groups

✅ Reliable

• A/B partition rollback

• Script-based atomic updates

• Deployment monitoring

✅ Cloud-Native

• Runs in Docker

• Works behind reverse proxy (Nginx / Kong)

• Can be integrated with CI/CD pipelines

⸻

🧠 Real-World Example (Azure VM Scenario)

Since you’re building Mender in Azure VM labs:

• vm02 → Mender Server

• vm01 / vm03 → Mender Clients

• Artifact created in vm02

• Deployment pushed to azure_vm device type

• Clients poll every 30 seconds

• Status visible in UI

You can test connectivity:

sudo systemctl status mender-client

journalctl -u mender-client -f

📊 What the Diagram Really Teaches

The image explains one key principle:

👉 Mender is pull-based, not push-based.

Devices initiate the update process.

This makes it:

• Firewall-friendly

• NAT-friendly

• Secure by design

⸻

🏁 Final Thoughts

This diagram beautifully summarizes the Mender OTA lifecycle:

Developer → Server → Devices → Server

It represents:

• Control Plane (Server)

• Execution Plane (Client)

• Delivery Artifact (.mender file)

• Feedback Loop (Status reporting)

For DevOps engineers managing fleets of edge devices or Azure VMs, this architecture provides:

• Centralized update control

• Safe OS upgrades

• Automated rollback

• Full deployment visibility