DEV Community

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

Posted on

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

#devops #azure #cicd #github

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
Enter fullscreen mode Exit fullscreen mode

⚙️ 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:

OS Output
Windows .exe + latest.yml
macOS .dmg / .zip
Linux .AppImage / .deb

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:

Storage Purpose
Recent Always contains the latest build
Archive Contains version history forever

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
Enter fullscreen mode Exit fullscreen mode

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

Requirement Achieved
Multi-OS build ✔️
Fast builds ✔️ (matrix strategy)
Secure storage ✔️
Easy rollback ✔️
Auto-update without exposing URLs ✔️
Hash-based integrity ✔️
Smooth user experience ✔️

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. 😄

Top comments (0)