Electron App Auto-Update: Ein praktischer Guide für 2026

Du hast den Electron-Build veröffentlicht, die Release-Seite ist online, und das erste Support-Ticket kommt, bevor die Kaffeemaschine fertig ist. Ein Nutzer sagt, die App hat das Update nie gefunden. Ein anderer hat es heruntergeladen, kann es aber nicht installieren. Ein dritter läuft noch mit einem alten Binary und einem kaputten Authentifizierungs-Flow, während deine Logs fast nichts Nützliches zeigen.

Das ist die unbequeme Realität von Electron App Auto Update. Der Updater API ist nur ein Baustein. Ein Produktiv-Release hängt auch von Plattform-Signierung, Transport-Policy, Manifests, Hosting, Lifecycle-Events, Observability, Rollout-Steuerung und einem Rollback-Pfad ab. Behandelst du eines davon als optional, kann ein Routine-Patch zu einem nächtlichen Incident werden.

Inhaltsverzeichnis

• Der 2-Uhr-Update-Vorfall, der diese Anleitung auslöste
• Den richtigen Weg für Electron Updater wählen
• Auto-Update-Flow im Main Process implementieren
  • Zuerst das Publish-Target konfigurieren
  • Checks planen und Lifecycle-Events bereitstellen
  • Renderer informieren, ohne den Workflow zu blockieren
• CI/CD für signierte Releases und Manifests aufsetzen
  • Signing in der CI explizit machen
• Rollouts, Channels und Rollback-Strategie
  • Cohorts vor breitem Rollout nutzen
• Auto-Update als Security Control behandeln
  • Die Metadaten genauso sorgfältig schützen wie die Binary
• Production-Update-Runbook und Checkliste
  • Pre-Release-Gates
  • Canary und vollständiger Rollout
  • Incident Response

Der Update-Vorfall um 2 Uhr nachts, der diese Anleitung inspirierte

Der Release bestand die CI und sah unauffällig aus. Spät am Freitag pushte ein Entwickler einen signaturlosen Electron-Build, und der Publish-Job lud genug Assets hoch, damit der Release vollständig wirkte. Die App startete im Test, aber niemand hatte den Update-Pfad von einem installierten Produktions-Build aus getestet.

Um 2:08 Uhr meldete PagerDuty den On-Call-Engineer. Ein neuer Authentifizierungsflow schlug bei einem Teil der Flotte fehl, und Nutzer, die das Update erhalten hatten, konnten sich nicht anmelden. Andere Nutzer blieben auf der vorherigen Version, da der Updater das Artefakt nicht verifizieren oder installieren konnte. Einige Kunden hatten eine defekte Release, während der Rest der Flotte eine andere Version ohne klare Erklärung ausführte.

Die Untersuchung folgte fünf Prüfungen:

1. Release-Feed prüfen. Die Binary existierte, aber die erwarteten Metadaten stellten nicht klar fest, welche Clients sie erhalten sollten. Ein Manifest ist ein Vertrag zwischen der Release-Pipeline und den installierten Clients, kein optionales Upload-Detail.
2. Signierung inspizieren. Die Release-Signatur war fehlerhaft, daher schlug die Verifizierung auf den betroffenen Plattformen fehl. Fehlt die Signatur oder ist sie ungültig, muss die Veröffentlichung blockiert werden.
3. Client-Logs vergleichen. Update-Fehler erreichten nie die zentrale Telemetrie. Die Anwendung schluckte das Event und fuhr fort, wodurch das Team ohne zuverlässige Beweise dastand.
4. Rollout-Steuerungen prüfen. Es gab keinen internen Channel oder gestaffelte Kohorte. Jeder berechtigte Client nutzte denselben Feed, daher verbreitete sich der Fehler ohne einen Containment-Punkt.
5. Nach einem Rollback suchen. Das Team hatte kein getestetes Verfahren, die vorherige Version neu zu veröffentlichen oder Clients von der defekten Release wegzuleiten.

Die offizielle Dokumentation von Electron macht die Plattformlimits deutlich. Linux bietet keine eingebaute Auto-Update-Unterstützung, und macOS-Update-Anfragen müssen die App Transport Security-Anforderungen erfüllen. Die Dokumentation bezeichnet das Signieren zudem als Voraussetzung für zuverlässige macOS-Updates und die Verifikation von Releases. Die Electron-autoUpdater-Dokumentation definiert die API-Einschränkungen, während das Release-System die umgebenden operativen Kontrollen durchsetzen muss.

Lehre aus dem Postmortem: Ein Updater, der nicht erklären kann, was passiert ist, ist ein Remote-Installationsversuch ohne Telemetrie.

Die Kosten gingen über die reine Engineering-Zeit hinaus. Kunden verloren das Vertrauen in den Desktop-Client, der Support musste inkonsistentes Verhalten erklären, und das Team verbrachte den nächsten Arbeitstag damit, einen Release-Prozess aufzubauen, der vor dem Vorfall hätte existieren müssen.

Behandeln Sie Auto-Update als operatives System. Signieren ist ein Release-Gate, Manifeste definieren den Client-Vertrag, Rollout-Kanäle begrenzen die Reichweite, und Rollback bleibt ein getesteter Pfad statt einer Notlösung.

Den richtigen Weg für Electron Updater wählen

Um 2 Uhr nachts wird die falsche Updater-Wahl zum operativen Problem. Ein natives Binary-Update muss Signierung, Manifeste, Installer und Rollback abdecken. Eine JavaScript- oder CSS-Änderung, die nur den Renderer betrifft, nimmt einen anderen Weg. Auch die Hosting-Einschränkungen zählen: Ein kleines, auf GitHub gehostetes Projekt braucht nicht dieselben Release-Kontrollen wie ein Enterprise-Distributionsservice.

Für Projekte, die electron-builder mit signierter Artefakt-Veröffentlichung nutzen, electron-updater ist in der Regel der praktische Standard. Das Ökosystem deckt Publish-Ziele, Release-Manifests, Artifact-Downloads und die Installation beim nächsten Start ab. Es unterstützt mehrere Hosting-Modelle, aber dein Team ist weiterhin für Signing, Feed-Verfügbarkeit, Channel-Policy, Rollout-Steuerung und Monitoring verantwortlich. Die Electron-Updater-Integration für Capgo ist relevant, wenn ein hybrides Delivery-Modell für Web-Layer-Bundles neben nativen Releases evaluiert wird.

update-electron-app eignet sich für Teams, die eine kleine Integration um GitHub Releases herum möchten. Es prüft beim Start und dann in regelmäßigen Intervallen, was die Einrichtung einfach hält, aber weniger Spielraum für fortgeschrittene Channel-Auswahl, gestaffelten Traffic und benutzerdefinierte Rollback-Regeln lässt. Das Paket ist für einen kleinen Release-Prozess angemessen, vorausgesetzt, GitHub Releases und deren Verfügbarkeit entsprechen deinen operativen Anforderungen.

Ein Custom Service wie Hazel, Nuts oder ein interner Feed ist sinnvoll, wenn Release-Autorisierung, Tenant-Targeting, Audit-Aufzeichnungen oder regulierte Deployment-Regeln die Implementierungskosten rechtfertigen. Der Trade-off ist die laufende Verantwortung. Ihr Team muss die Manifest-Semantik definieren, Signing-Keys schützen, Client-Kompatibilität wahren sowie fehlgeschlagene Downloads, abgelehnte Releases und Rollback-Verhalten testen.

Live-Updates können Renderer-only-Änderungen ausliefern, ohne die native Shell neu zu bauen. Sie ersetzen keine Binary-Updates, wenn sich Electron, native Module, Berechtigungen oder das Installer-Verhalten ändern. Nutzen Sie electron-updater, sofern Sie keine eigene Rollout-Logik benötigen. Falls eine eigene Logik erforderlich ist, bauen Sie auf etablierten Manifest- und Artefakt-Konventionen auf, anstatt Download- und Differential-Update-Verhalten neu zu erfinden. Ein verlässlicher Weg ist der, den Ihr Team unter Druck beobachten, stagen und rückgängig machen kann.

Auto-Update-Flow im Main Process implementieren

Der Main-Prozess sollte die Update-Prüfung und -Installation übernehmen. Der Renderer kann den Status anzeigen, sollte aber nicht entscheiden, ob ein ausführbares Update vertrauenswürdig ist oder wann die Anwendung beendet wird.

Zuerst das Publish-Target konfigurieren

Eine minimale electron-builder-Konfiguration könnte so aussehen:

{
  "build": {
    "appId": "com.example.desktop",
    "publish": [
      {
        "provider": "s3",
        "bucket": "example-electron-releases",
        "channel": "stable"
      }
    ],
    "nsis": {
      "oneClick": false,
      "allowToChangeInstallationDirectory": true
    }
  }
}

Halte Beta- und Stable-Feeds getrennt. Ein Channel ist eine Release-Policy, kein UI-Label. Jeder Channel muss auf das korrekte signierte Artefakt und Manifest auflösen.

Checks planen und Lifecycle-Events bereitstellen

Aufruf checkForUpdates() Nur beim Startup zu prüfen, ist ein häufiger Produktionsfehler. Nutzer lassen die App oft tagelang offen, daher braucht der Main Process ein kontrolliertes Intervall und eine Retry-Strategie, die Offline-Betrieb respektiert.

const { app, BrowserWindow, ipcMain } = require('electron');
const { autoUpdater } = require('electron-updater');

let mainWindow;
let isQuitting = false;
let retryDelay = 60 * 1000;

function sendUpdateStatus(status, payload = {}) {
  if (mainWindow && !mainWindow.isDestroyed()) {
    mainWindow.webContents.send('update-status', { status, ...payload });
  }
}

function scheduleUpdateCheck() {
  setTimeout(async () => {
    try {
      await autoUpdater.checkForUpdates();
      retryDelay = 60 * 1000;
    } catch (error) {
      sendUpdateStatus('error', { message: error.message });
      retryDelay = Math.min(retryDelay * 2, 30 * 60 * 1000);
    }
    scheduleUpdateCheck();
  }, retryDelay);
}

app.whenReady().then(() => {
  mainWindow = new BrowserWindow({
    webPreferences: {
      preload: require('path').join(__dirname, 'preload.js')
    }
  });

  autoUpdater.autoDownload = true;
  autoUpdater.autoInstallOnAppQuit = false;

  autoUpdater.on('checking-for-update', () => {
    sendUpdateStatus('checking');
  });

  autoUpdater.on('update-available', info => {
    sendUpdateStatus('available', { version: info.version });
  });

  autoUpdater.on('download-progress', progress => {
    sendUpdateStatus('progress', { percent: progress.percent });
  });

  autoUpdater.on('update-downloaded', info => {
    sendUpdateStatus('downloaded', { version: info.version });
  });

  autoUpdater.on('error', error => {
    sendUpdateStatus('error', { message: error.message });
  });

  autoUpdater.checkForUpdates().catch(error => {
    sendUpdateStatus('error', { message: error.message });
  });

  scheduleUpdateCheck();
});

ipcMain.handle('install-update', () => {
  isQuitting = true;
  autoUpdater.quitAndInstall(false, true);
});

app.on('before-quit', event => {
  if (!isQuitting) {
    return;
  }
});

Das genaue Verhalten von Update-Events variiert je nach Plattform und Packaging-Setup. Teste daher aus installierten Artefakten, nicht im Dev-Mode. Die Electron-Doku weist ebenfalls auf Timing-Probleme beim Startup auf Windows hin, einschließlich des Squirrel-First-Run-Falls. Löst keine Update-Prüfung aus, bevor die plattformspezifische Initialisierung abgeschlossen ist.

Renderer informieren, ohne den Workflow zu blockieren

Die Preload-Bridge sollte eine schmale API exponieren:

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('updates', {
  onStatus(callback) {
    ipcRenderer.on('update-status', (_event, status) => callback(status));
  },
  install() {
    return ipcRenderer.invoke('install-update');
  }
});

Eine Fortschrittsleiste auf der Renderer-Seite kann bewusst einfach gehalten werden:

window.updates.onStatus(status => {
  const progress = document.querySelector('#update-progress');
  const message = document.querySelector('#update-message');

  if (status.status === 'progress') {
    progress.hidden = false;
    progress.value = status.percent;
    message.textContent = `Downloading update, ${Math.round(status.percent)}%`;
  }

  if (status.status === 'downloaded') {
    message.textContent = `Version ${status.version} is ready to install`;
  }

  if (status.status === 'error') {
    message.textContent = 'The update could not be downloaded. We will retry later.';
  }
});

In der Produktion sollte die Installation nur nach Zustimmung des Nutzers erfolgen, es sei denn, Ihre Anwendung muss zwingend sofort neu starten. Legen Sie einen isQuitting vorher ein Flag quitAndInstall(), da sonst normale Window-Close-Handler verhindern können, dass der Installer übernimmt.

Zwei Fehlerfälle verdienen explizite Tests. Erstens muss ein bereits laufender Client checkForUpdates() regelmäßig aufrufen, nicht nur beim Start. Zweitens muss das error Event in Logs und Telemetrie ankommen. Wenn die App es ohne Meldung verschluckt, beginnt Ihr App-Troubleshooting-Workflow mit Vermutungen statt mit Belegen.

CI/CD für signierte Releases und Manifests aufsetzen

Die Release-Pipeline ist die Source of Truth dafür, was Nutzer installieren. Ein lokaler Build, der auf der Maschine eines Entwicklers funktioniert, beweist nicht, dass die veröffentlichte Binary, das Manifest, die Signatur und der Channel zum selben Release gehören.

Das Publish-Modell von electron-builder erwartet, dass Release-Metadaten und Update-Target zusammen ausgeliefert werden. Bei vielen Konfigurationen bedeutet das ein Artefakt wie latest.yml für Windows und latest-mac.yml für macOS, zusammen mit plattformspezifischen Paketen und Blockmap-Dateien. Ein fehlendes Manifest kann eine völlig gültige Binärdatei für Clients unsichtbar machen.

Signing in der CI explizit machen

Ein vereinfachtes GitHub Actions-Muster sieht so aus:

name: release

on:
  push:
    tags:
      - "v*"

jobs:
  build:
    strategy:
      matrix:
        os: [macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run test
      - run: npm run build

      - name: Build and publish
        shell: bash
        env:
          CSC_LINK: ${{ secrets.CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.CSC_KEY_PASSWORD }}
          WIN_CSC_LINK: ${{ secrets.WIN_CSC_LINK }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: npx electron-builder --publish always

Nutzt plattformspezifische Secrets und haltet das Signing-Material außerhalb des Repositories. Ein Signing-Fehler sollte den Job stoppen, nicht zu einem unsignierten Fallback führen, den jemand manuell hochlädt.

Die Publish-Konfiguration sollte den Provider und den Channel konsistent identifizieren:

{
  "build": {
    "publish": {
      "provider": "s3",
      "bucket": "example-electron-releases",
      "channel": "stable",
      "publishAutoUpdate": true,
      "updaterCacheDirName": "example-desktop-updater"
    }
  }
}

Vor der Veröffentlichung solltet ihr den Job an der Paketversion, dem Tag, der Commit-SHA und dem Smoke-Test-Ergebnis festlegen. Nach der Veröffentlichung prüft, ob der Feed das erwartete Manifest enthält und ob das Manifest auf das exakte Artefakt verweist, das von diesem Job generiert wurde. Die Continuous-Integration-Einrichtungsanleitung ist nützlich, wenn ihr diese Checks formalisiert, und Teams, die Pipeline-Orchestrierung vergleichen, profitieren ebenfalls davon, dies zu verstehen. Wann man Jenkins und Ansible zusammen einsetzt.

Die Befehle, die typischerweise eine unvollständige Release-Veröffentlichung aufdecken, sind absichtlich unspektakulär:

npx electron-builder --publish never
test -f dist/latest.yml
test -f dist/latest-mac.yml
find dist -name "*.blockmap" -print

Diese Checks ersetzen keinen signierten Installationstest. Sie fangen aber den operativen Fehler ab, eine Binary ohne die Metadaten hochzuladen, die Clients zum Auffinden benötigen.

Rollouts, Channels und Rollback-Strategie

Ein Release-Feed sollte eher wie ein Deployment-Target als wie ein Download-Ordner funktionieren. Behalte intern, Beta, und Neueste Kanäle getrennt halten, wobei jeder Kanal sein eigenes Manifest und ein eigenes signiertes Artefakt-Set hat. Eine Promotion sollte ein getestetes Release zwischen Policies verschieben, statt eine Datei zu überschreiben, während Clients sie gerade herunterladen.

Die Trennung der Kanäle schützt die Production auch vor versehentlichen Test-Builds. Der Updater sollte wissen, ob ein Client zu einer internen Cohort, einer Beta-Zielgruppe oder der stabilen Population gehört, bevor er den Feed auswertet.

Cohorts vor breitem Rollout nutzen

Ein eigenes Manifest-Feld kann gestaffelte Auslieferung ausdrücken:

version: 4.8.0
path: Example-Setup-4.8.0.exe
sha512: signed-artifact-hash
rolloutPercentage: 10

Der Main-Prozess kann jedem User einen stabilen Bucket zuweisen und diesen dann mit rolloutPercentage. Stabile Zuweisung ist entscheidend. Ein User, der bei jedem Check zwischen berechtigtem und nicht berechtigtem Status wechselt, bekommt unvorhersehbares Verhalten und macht Support-Reports schwer interpretierbar.

Erweitere die Cohort erst, nachdem das Release sein Beobachtungsfenster überstanden hat. Das genaue Fenster sollte dein Nutzungsverhalten widerspiegeln, aber die Entscheidung sollte auf Signalen basieren, nicht nur auf dem Kalender. Tracke Ergebnisse der Update-Checks, abgeschlossene Downloads, Launch-Health, Crashes, Renderer-Exceptions und erfolgreiche Authentifizierung.

Verwechse Rollback nicht mit dem Löschen eines Artefakts. Bestehende Clients haben möglicherweise Metadaten gecacht, und einige laufen bereits mit der fehlerhaften Version. Ein Rollback-Plan erfordert eine vorherige signierte Release, eine Feed-Änderung und ein Client-Verhalten, das sich erholen kann.

Operative Regel: Ein Rollback muss vom On-Call-Engineer ausführbar sein, ohne die App während des Incidents neu bauen zu müssen.

In der Praxis sollte das Runbook das vorherige Release-Manifest wieder auf den betroffenen Channel promoten, den Staging-Marker invalidieren und bestätigen, dass neue Checks auf die sichere Version auflösen. Liegt das Problem im Renderer code statt in der Native Shell, kann ein gezielter Rollback der Web-Layer schneller sein. Eine Plattform wie Capgo Phased Rollouts kann für diese separate Delivery-Layer relevant sein, sollte aber die Grenze zwischen einem Rollback eines Native Build und einem Rollback eines Web-Bundles nicht verschleiern.

Auto-Update als Security Control behandeln

Ein Electron-Updater lädt die ausführbare code herunter und kann sie mit minimaler Nutzerinteraktion installieren. Das macht den Update-Pfad zu einer Sicherheitsgrenze, nicht bloß zu einem Convenience-Feature. Die offizielle Electron-Dokumentation beschreibt Plattform-Einschränkungen wie macOS ATS, und die Security-Berichterstattung hat ein Szenario aus dem Jahr 2022 dokumentiert, bei dem Angreifer mit Kontrolle über die Update-Infrastruktur bösartige Pakete ausliefern konnten, die die code-Signing-Checks dennoch bestanden, wie in der Electron-Builder-Dokumentation zur Auto-Update-Sicherheit.

Code-Signierung bleibt grundlegend, ist aber nicht das gesamte Vertrauensmodell. Signiere jede Release, verifiziere Zertifikat und Identität während der CI und halte ein dokumentiertes Key-Rotation-Verfahren aufrecht. Auf macOS kombinierst du Signierung mit Notarization und dem für deine Anwendung geeigneten Hardened Runtime. Auf Windows sollten Zertifikatsbesitz, Verlängerung und Build-Zugriff auditierbar sein. Linux benötigt eine distributionsspezifische Strategie, da Electron dort keinen integrierten universellen Updater bereitstellt.

Die Metadaten genauso sorgfältig schützen wie die Binary

Eine signierte Binärdatei kann immer noch mit der falschen Release-Version verknüpft werden, wenn der Metadatenkanal kompromittiert oder falsch konfiguriert ist. Erwäge, eine Manifest-Signatur hinzuzufügen, die gegen einen öffentlichen Schlüssel im Anwendungsbinary verifiziert wird, eine Mindestversion durchzusetzen und unerwartete Downgrades abzulehnen, es sei denn, ein autorisierter Wiederherstellungspfad erlaubt sie ausdrücklich.

Der Feed verdient ebenfalls Produktionskontrollen:

• Veröffentliche Zugriffe einschränken: Gewähre CI nur die Berechtigungen, die zum Veröffentlichen von Release-Assets erforderlich sind.
• Schütze Signing-Secrets: Bewahre Zertifikate und private Schlüssel in einem verwalteten Secret-Storage auf, nicht in Repository-Dateien.
• Dependencies pinnen: Electron, electron-builder und transitive Abhängigkeiten in CI fixieren.
• Artefakte prüfen: Die generierten Pakete scannen und mit dem vorgesehenen Commit und der Version abgleichen.
• Sicheren Transport erzwingen: ATS- und strikte HTTPS-Anforderungen für Update-Requests einhalten.
• Verifizierungsfehler überwachen: Wiederholte Fehler bei Signaturen oder Manifesten als Security-Events behandeln, nicht als bloßes Netzwerkrauschen.

Das gepflegte Tooling-Ökosystem von Electron erweitert laufend die Abdeckung von Packaging und Updater, aber Wartung ersetzt kein Threat Modeling. Das praktische Ziel ist sicherzustellen, dass ein Angreifer, der einen Bucket, ein CDN oder einen Build-Schritt kompromittiert, den Client trotzdem nicht dazu bringen kann, ein unautorisiertes Release zu akzeptieren. Die Anleitung zur Signaturprüfung liefert hilfreichen Kontext für das Design dieser zusätzlichen Verifizierungsebene.

Production-Update-Runbook und Checkliste

Ein Release ist erst bereit, wenn ein anderer Entwickler es unter Druck betreiben kann. Halte die Checkliste nah am Deployment-Job und am Incident-Channel.

Pre-Release-Gates

• Versionsidentität: Stelle sicher, dass Paketversion, Release-Tag, Commit-SHA und Changelog übereinstimmen.
• Signierung: Prüfe, ob alle Plattform-Artefakte signiert sind und die Notarisierung oder eine gleichwertige Validierung abgeschlossen wurde.
• Manifest-Vertrag: Bestätigen latest.yml, latest-mac.yml, Hashes, Pfade und Blockmaps stimmen mit den hochgeladenen Artefakten überein.
• Channel-Sicherheit: Veröffentliche im internen oder Beta-Feed, bevor du den Release-Channel promotest.
• Telemetrie: Stellen Sie sicher, dass Update-Checks, Download-Fortschritt, Installationsabschluss, Start-Status und Fehlermeldungen eintreffen.

Canary und vollständiger Rollout

• Cohort-Steuerung: Beginnen Sie mit einer bewusst kleinen internen oder Beta-Zielgruppe.
• Health-Budget: Halten Sie die Promotion an, wenn Launch-Fehler, fehlgeschlagene Update-Downloads, Renderer-Exceptions oder Authentifizierungsfehler die genehmigten Limits des Teams überschreiten.
• Promotion-Freigabe: Fordern Sie eine explizite Go/No-Go-Entscheidung, bevor Sie das Release in den Stable-Feed verschieben.
• Auswirkung auf Kunden: Bereite Support-Mitteilungen vor der breiten Verteilung vor, nicht erst nach dem ersten Vorfall.

Incident Response

Falls die neue Binary nicht startet, das Spawnen von Prozessen fehlschlägt oder Update-Downloads nicht mehr abgeschlossen werden, stoppen Sie die Promotion sofort. Stellen Sie das vorherige signierte Manifest wieder her, invalidieren Sie den Staging-Marker und prüfen Sie, ob neue Clients auf die vorherige Version zeigen. Bestätigen Sie erst über die Telemetrie, dass sich die Flotte erholt, bevor Sie den Abschluss kommunizieren.

Die genauen Rollback-Befehle hängen von Ihrem Provider ab, aber die Reihenfolge sollte immer dokumentiert sein: Channel-Manifest auf die vorherige Version umstellen, Staging-Tag invalidieren, bei Bedarf einen Forced-Update-Marker pushen und den Downgrade-Pfad mit Live-Telemetrie verifizieren. Ein Rollback, der nicht getestet wurde, ist nur Hoffnung.

Capgo bietet einen Electron-Updater für die Bereitstellung signierter Web-Layer-Änderungen, gezielter Kanäle, Rollout-Steuerungen und Update-Observability, ohne die native Shell für jede Renderer-Änderung neu zu bauen. Wenn Sie native Binary-Releases von der kontrollierten Bereitstellung von JavaScript und CSS trennen möchten, besuchen Sie Capgo und bewerten Sie es neben Ihrer bestehenden Electron-Release-Pipeline.