CI/CD for Electron Desktop Apps Auto-Update, CDN, Azure Blob, Matrix Build & OS-Level Security

Most CI/CD blogs talk about deploying web apps — and those are relatively simple.
You push code, run tests, build, deploy to cloud, done.

But Electron desktop apps are a different world.
You’re dealing with:

• Windows, macOS, and Linux
• OS-level permissions
• Signing certificates
• Private storage
• Installers
• Auto-update logic

Six months ago, I built a complete secure update pipeline for a multi-OS Electron app, and I recently remembered the journey. So I decided to write it down properly in case someone else goes through the same struggle.

🧩 The Problem

Shipping a desktop app is not like shipping a website.

Web → backend downtime = API solves
Desktop → user already downloaded the binary

Every version matters. Every URL matters. And security matters even more.

So the goal was:

Build once → package for all OS → upload securely → users get auto-update reliably → without exposing storage URLs.

🔁 The CI/CD Flow (High-Level)

PR → Validation (ENV + Tests) → Merge to Main
   → Matrix Build (Windows + macOS + Linux)
   → Upload to Azure Blob (Versioned)
   → Update Metadata
   → CDN sync
   → Auto-Update Notifies Users

⚙️ Step 1 PR Validation

When a PR was raised, the pipeline first ensured:

• All required .env variables exist
• All tests pass
• Nothing breaks before hitting main

Only after that merging was allowed.

🧰 Step 2 Parallel Matrix Build (Not Sequential)

Sequential builds were slow and OS dependencies broke each other.

So I switched to a matrix build strategy each OS built in parallel:

Because some OS requirements were heavy (signing certificates, Linux package dependencies, Windows secrets), parallel execution reduced overall build time massively.

📦 Step 3 Dual Blob Storage Strategy

Inside Azure I maintained two storage accounts:

Folder structure example

/recent/windows/app.latest.exe
/recent/mac-linux/app.latest.AppImage
/archive/1.11/windows/app-1.11.exe
/archive/1.11/mac-linux/app-1.11.AppImage

So:

• CDN always pointed to /recent/…/app.latest.exe
• But rollback was still possible via /archive/<version>/

Users always saw:

Installing app.latest.exe
instead of app-1.11.exe — but latest still internally had version info.

🌍 Step 4 Secure CDN instead of Direct Blob Links

We never exposed Azure Blob URLs (security risk).

So CDN was placed in front of the Blob and configured with:

• CORS restricted to metadata URL only
• No public blob token exposure
• Cache invalidation triggered on every deployment

When a new version deployed:

• Only /recent/…/app.latest.exe got replaced
• Metadata file got updated
• CDN refreshed

Users never had to think about version numbers.

🔒 Step 5 Auto-Update Validation with Hash Logic

This was one of the most important security parts.

The Electron app did not blindly download the file.
Instead:

1. App sends request to CDN (after 10s)
2. Metadata returns latest version + hash
3. App converts its own version → hash
4. If both hashes match → allow update
5. If mismatch → reject (prevents malicious uploads)

Even if someone somehow replaced the installer,
no existing user could be affected because they don’t know the hashing logic.

🎯 Final Result

Users open the app → 10 seconds later → “A new version is available” → download starts → install done.

No version numbers, no confusion — just app.latest.exe.

🥲 Closing Thoughts

This wasn’t like CI/CD for a web API.
It took debugging OS permissions, signing certificates, platform secrets, and update logic.
Electron CI/CD looks simple in documentation until you actually do it.

But once it’s set up, the delivery becomes:

• Scalable
• Secure
• Fully automated

If you're building a production grade Electron app, you need to think like a software distributor, not just a developer.

I hope this write-up helps someone facing the same headaches I had six months ago. 😄