Electron App Auto Update: A Practical 2026 Guide

Ha enviado la compilación de Electron, la página de lanzamiento está activa, y la primera solicitud de soporte llega antes de que la máquina de café termine. Un usuario dice que la aplicación nunca encontró la actualización. Otro la descargó pero no puede instalarla. Un tercero sigue ejecutando una versión antigua con un flujo de autenticación roto, mientras que sus registros muestran casi nada útil.

Es la realidad incómoda de actualización de aplicaciones de Electron. El actualizador API es solo una parte. Un lanzamiento de producción también depende de la firma de plataforma, la política de transporte, los manifiestos, el alojamiento, los eventos de ciclo de vida, la observabilidad, el control de lanzamiento y un camino de rollback. Trate a cualquiera de esos como opcional y una parche rutinario puede convertirse en un incidente nocturno.

Contenido de la Tabla

• El Incidente de Actualización a las 2 A.M. Que Inició Esta Guía
• Elige el camino correcto para la actualización de Electron
• Implementa el flujo de actualización automática en el proceso principal
  • Configura el objetivo de publicación primero
  • Programar controles y exponer eventos de ciclo de vida
  • Mantén informado al renderizador sin bloquear el trabajo
• Wirar CI/CD para versiones firmadas y manifestos
  • Hacer explícita la firma en CI
• Despliegues, canales y estrategia de rollback
  • Usar cohortes antes de la exposición amplia
• Tratar la actualización automática como un control de seguridad
  • Proteger el metadato con la misma atención que el binario
• Guía de Actualización y Lista de Verificación de Producción
  • Vigilias de pre-lanzamiento
  • Canario y despliegue completo
  • Respuesta a incidentes

El Incidente de Actualización a las 2 A.M. que Inició esta Guía

La versión pasó por CI y parecía ordinaria. A última hora del viernes, un desarrollador empujó un build de Electron sin firmar, y el trabajo de publicación subió suficientes activos para hacer que la versión pareciera completa. La aplicación se lanzó en pruebas, pero nadie había ejercitado el camino de actualización desde un build de producción instalado.

Al 2:08 a.m., PagerDuty alertó al ingeniero de llamada. Una nueva flujo de autenticación falló para parte de la flota, y los usuarios que recibieron la actualización no pudieron completar el inicio de sesión. Otros usuarios se quedaron en la versión anterior porque el actualizador no pudo verificar o instalar el artefacto. Algunos clientes tenían una liberación rota, mientras que el resto de la flota corría una versión diferente sin explicación clara.

La investigación siguió cinco verificaciones:

1. Verificar la fuente de liberación. El binario existía, pero el metadato esperado no establecía claramente qué clientes debían recibirlo. Un manifiesto es un contrato entre la línea de liberación y los clientes instalados, no un detalle de carga opcional.
2. Inspeccionar la firma. La liberación no se firmó correctamente, por lo que la verificación falló en las plataformas afectadas. La firma debe bloquear la publicación cuando está ausente o inválida.
3. Comparar los registros de los clientes. Errores de actualización nunca llegaron a la telemetría central. La aplicación engulló el evento y continuó funcionando, dejando al equipo sin evidencia fiable.
4. Verificar los controles de liberación. No había un canal interno o una cohorte de etapa. Cada cliente elegible utilizó la misma fuente, por lo que el fracaso se extendió sin un punto de contención.
5. Buscar una reversión. El equipo no tenía un procedimiento probado para republicar la versión anterior o dirigir a los clientes hacia la liberación rota.

La documentación oficial de Electron muestra claramente los límites del plataforma. No hay soporte de actualización automática integrado en Linux.y los pedidos de actualización de macOS deben satisfacer App Transport Security requirementsLa documentación también identifica la firma como un requisito previo para actualizaciones de macOS confiables y la verificación de la versión de lanzamiento. Documentación de autoactualización de Electron define las API restricciones, mientras que el sistema de liberación debe aplicar el control operativo circundante.

Lección post mortem: Un actualizador que no puede explicar qué sucedió es un intento de instalación remota con telemetría faltante.

The cost extended beyond engineering time. Customers lost confidence in the desktop client, support had to explain inconsistent behavior, and the team spent the next workday rebuilding a release process that should have existed before the incident.

actualiza automáticamente sistema operativoLa firma es una puerta de control de lanzamiento, los manifiestos definen el contrato del cliente, los canales de lanzamiento limitan la exposición, y el rollback es un camino probado en lugar de una invención de emergencia.

Elige el camino correcto para actualizar Electron

Al medianoche, la elección incorrecta del actualizador se convierte en un problema operativo. Un actualizador binario nativo debe manejar la firma, los manifiestos, los instaladores y el rollback. Un cambio de JavaScript o CSS solo en el renderizador sigue un camino diferente. Las restricciones de hosting también importan: un pequeño proyecto GitHub-hosted no necesita los mismos controles de lanzamiento que un servicio de distribución empresarial.

Para proyectos que utilizan electron-builder con publicación de artefactos firmados electron-updater es el default práctico por defecto. Su ecosistema cubre los objetivos de publicación, los manifiestos de lanzamiento, las descargas de artefactos y la instalación en el próximo arranque. Soporta varios modelos de hosting, pero su equipo todavía es responsable de la firma, la disponibilidad de la fuente, la política de canales, el control de lanzamiento y la supervisión. La integración del actualizador de Electron para Capgo es relevante al evaluar un modelo de entrega híbrido para paquetes de capas web junto a lanzamientos nativos.

update-electron-app se adapta a equipos que quieren una pequeña integración alrededor de GitHub Releases. Verifica al arrancar y luego en intervalos recurrentes, lo que mantiene el setup simple pero deja menos espacio para la selección avanzada de canales, el tráfico estadiado y las reglas de rollback personalizadas. El paquete es razonable para un proceso de lanzamiento pequeño, siempre y cuando GitHub Releases y su disponibilidad se ajusten a los requisitos operativos.

Un servicio personalizado como Hazel, Nuts o una alimentación interna se ajusta cuando la autorización de lanzamiento, la dirección de la tenencia, los registros de auditoría o las reglas de despliegue regulado justifican el costo de implementación. El intercambio es la propiedad continua. Su equipo debe definir semánticas de manifiesto, proteger claves de firma, preservar compatibilidad del cliente, y probar descargas fallidas, lanzamientos rechazados y comportamiento de retroceso.

Las actualizaciones en vivo pueden enviar cambios solo en el renderizador sin volver a construir la caja nativa. No reemplazan las actualizaciones de binarios cuando cambian Electron, módulos nativos, permisos o comportamiento del instalador. Utilice electron-updater a menos que necesite lógica de despliegue personalizada. Si se requiere lógica personalizada, construya alrededor de convenciones de manifiesto y artefactos establecidas en lugar de recrear el comportamiento de descarga y actualización diferencial. Un camino confiable es el que su equipo puede observar, etapa y revertir bajo presión.

Implementar el flujo de actualización automática en el proceso principal

El proceso principal debe ser dueño de las comprobaciones de actualización e instalación. El renderizador puede mostrar el estado, pero no debe decidir si una actualización ejecutable es confiable o cuando la aplicación sale.

Configure el objetivo de publicación primero

Una configuración mínima de electron-builder podría verse así:

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

Mantenga las fuentes beta y estable separadas. Un canal es una política de lanzamiento, no una etiqueta en la interfaz de usuario. Cada canal debe resolver al artefacto firmado correcto y al manifiesto.

Programar comprobaciones y exponer eventos de ciclo de vida

Llamar checkForUpdates() Solo durante el arranque es un error común en producción. Un usuario puede dejar la aplicación abierta durante días, por lo que el proceso principal necesita un intervalo controlado y una estrategia de reintento que respete la operación en línea.

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;
  }
});

El comportamiento exacto del evento de actualización varía por plataforma y configuración de empaque, por lo que pruebe desde artefactos instalados en lugar de modo de desarrollo. La documentación de Electron también destaca preocupaciones de tiempo de arranque en Windows, incluido el caso de primer arranque de Squirrel. No active una comprobación de actualización antes de que la aplicación haya completado la inicialización específica de plataforma que necesita.

Mantenga informado al renderizador sin bloquear trabajo

La puente de carga previa debería exponer un API estrecho.

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

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

Un barra de progreso en el lado del renderizador puede permanecer deliberadamente simple:

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.';
  }
});

Rechace la instalación detrás del consentimiento del usuario en producción a menos que su aplicación tenga una fuerte razón para reiniciarse inmediatamente. Establezca un isQuitting flag antes quitAndInstall()porque los manejadores de cierre de ventanas normales pueden impedir que el instalador tome el control.

Dos fallas merecen pruebas explícitas. Primero, un cliente ya ejecutándose debe llamar checkForUpdates() en un horario, no solo al arranque. Segundo, el error evento debe llegar a los registros y la telemetría. Si la aplicación lo engulle sin informar, tu flujo de trabajo de depuración de aplicaciones comienza con suposiciones en lugar de evidencia.

Wiring CI/CD para versiones firmadas y manifiestos

La canalización de liberación es la fuente de verdad de qué instalan los usuarios. Una compilación local que funciona en una máquina de un desarrollador no prueba que el binario publicado, el manifiesto, la firma y el canal describan la misma versión.

Electron-builder's modelo de publicación espera que los metadatos de la versión y el objetivo de actualización viajen juntos. Para muchas configuraciones, eso significa un artefacto como latest.yml para Windows y latest-mac.yml Para macOS, junto con paquetes y archivos blockmap específicos de la plataforma. Un manifiesto faltante puede hacer que un binario válido sea invisible para los clientes.

Hacer la firma explícita en CI

Un patrón simplificado de GitHub Actions se parece a esto:

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

Utilice secretos específicos de plataforma y mantenga el material de firma fuera del repositorio. Un error de firma debería detener el trabajo, no producir un fallback sin firma que alguien suba manualmente.

La configuración de publicación debería identificar consistentemente al proveedor y al canal:

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

Antes de la publicación, bloquee el trabajo en la versión del paquete, la etiqueta, el SHA del commit y el resultado del test de humo. Después de la publicación, verifique que el feed contiene el manifiesto esperado y que el manifiesto apunte al artefacto exacto generado por ese trabajo. El Guía de configuración de integración continua es útil cuando se formalizan esas comprobaciones, y los equipos que comparan la orquestación de pipelines también pueden beneficiarse de comprender When usar Jenkins y Ansible juntos.

Los comandos que comúnmente exponen una versión incompleta son intencionalmente aburridos:

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

Aquellos controles no sustituyen una prueba de instalación firmada. Lo que hacen es capturar el error operativo de subir un binario sin los metadatos que los clientes necesitan para descubrirlo.

Rollouts, canales y estrategia de retroceso

Un feed de versiones debería comportarse más como un destino de despliegue que como una carpeta de descargas. Mantenga internos, beta, y últimos canales separados, con cada canal respaldado por su propio manifiesto y conjunto de artefactos firmados. La promoción debería mover una versión probada entre políticas, no sobreescribir un archivo mientras los clientes lo están descargando.

La separación de canales también protege la producción de ediciones de prueba accidentales. El actualizador debería saber si un cliente pertenece a un conjunto de cohortes internos, un público de beta o la población estable antes de evaluar el feed.

Usar cohortes antes de la exposición amplia

Una campo de manifiesto personalizado puede expresar entrega en etapas:

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

El proceso principal puede asignar un contenedor estable por usuario, luego compararlo con rolloutPercentage. La asignación estable importa. Un usuario que se mueve entre estados elegibles e ineligibles en cada verificación recibirá comportamiento impredecible y hará que los informes de soporte sean difíciles de interpretar.

Ampliar solo el cohorte después de que la liberación haya sobrevivido a su ventana de observación. La ventana exacta debe reflejar el patrón de uso, pero la decisión debe basarse en señales, no en un calendario solo. Registre los resultados de la verificación de actualizaciones, la finalización del descarga, la salud de arranque, los errores de lanzamiento, las excepciones del renderizador y el éxito de la autenticación.

No confundir el rollback con la eliminación de un artefacto. Los clientes existentes pueden tener metadatos cacheados, y algunos pueden estar ejecutando ya la versión mala. Un plan de rollback necesita una versión firmada anterior, un cambio de feed y un comportamiento del cliente que pueda recuperarse.

Regla operativa: El rollback debe ser ejecutable por el ingeniero de llamada sin reconstruir la aplicación durante el incidente.

En la práctica, el runbook debe promover el manifiesto de la versión anterior de vuelta a la canal afectada, invalidar el marcador de etapa y confirmar que las nuevas comprobaciones resuelven a la versión segura. Si el problema está en el renderizador code en lugar de la caja nativa, un rollback web dirigido puede ser más rápido. Una plataforma como code rollouts de fase Capgo rollouts de fase puede ser relevante para ese capa de entrega separada, pero no debe ocultar la frontera entre un rollback binario nativo y un rollback de paquete web.

Tratando a Auto-actualización como un Control de Seguridad

Un actualizador de Electron descarga ejecutable code y puede instalarlo con poca interacción del usuario. Eso hace que el camino de actualización sea una frontera de seguridad, no meramente una característica de conveniencia. La documentación oficial de Electron describe restricciones de plataforma como ATS de macOS, y la cobertura de seguridad ha documentado un escenario de 2022 en el que los atacantes que controlaban la infraestructura de actualización podían servir paquetes maliciosos que aún pasaban por las comprobaciones de firma code. documentación de seguridad de auto-actualización de Electron Builder.

La firma Code sigue siendo fundamental, pero no es el modelo de confianza completo. Firma cada liberación, verifica el certificado e identidad durante CI, y mantén un procedimiento de rotación de claves documentado. En macOS, combina la firma con la notarización y el tiempo de ejecución endurecido adecuado a tu aplicación. En Windows, haz que la propiedad del certificado, la renovación y el acceso a la compilación sean auditables. Linux necesita una estrategia específica de distribución porque Electron no proporciona un actualizador universal integrado allí.

Protege la metadata con la misma atención que el binario

A un binario firmado todavía puede estar asociado con la versión incorrecta si el canal de metadatos está comprometido o mal configurado. Considerar agregar una firma de manifiesto verificada contra una clave pública incorporada en la aplicación, imponer una versión mínima permitida y rechazar descargas inesperadas a menos que un camino de recuperación autorizado las permita explicitamente.

El feed también merece controles de producción:

• Restringir el acceso a la publicación: Proporcionar a CI solo los permisos necesarios para publicar activos de versión.
• Proteger secretos de firma: Guardar certificados y claves privadas en almacenamiento de secretos gestionado, no en archivos de repositorio.
• Dependencias fijas: Lock Electron, electron-builder y dependencias transitivas en CI.
• Revisar artefactos: Escanear los paquetes generados y compararlos con el commit y la versión previstos.
• Requerir transporte seguro: Siguientes ATS y requisitos de HTTPS estrictos para solicitudes de actualización.
• Verificar fallas de verificación: Trate los errores de firma o manifest repetidos como eventos de seguridad, no como ruido de red ordinario.

El ecosistema de herramientas mantenidas de Electron sigue sumando cobertura de empaque y actualizaciones, pero la mantenibilidad no elimina la necesidad de modelado de amenazas. El objetivo práctico es asegurarse de que un atacante que comprometa un contenedor, CDN o paso de construcción aún no pueda hacer que el cliente acepte una liberación no autorizada. La orientación de verificación de firma proporciona un contexto útil para diseñar esa capa adicional de verificación.

El Libro de Actualización de Producción y Checklist

Una liberación está lista solo cuando otro ingeniero puede operarla bajo presión. Mantenga el checklist cerca del trabajo de despliegue y el canal de incidentes.

Controles previos a la liberación

• Identidad de versión: Confirme la versión del paquete, la etiqueta de lanzamiento, el SHA del commit y el changelog.
• Autenticación: Verificar que todos los artefactos de plataforma están firmados y que la notarización o la validación equivalente ha finalizado.
• Contrato de manifiesto: Confirmar latest.yml, latest-mac.yml, hashes, rutas y mapas de bloque coinciden con los artefactos subidos.
• Seguridad del canal: Publicar en la alimentación interna o beta antes de promover el canal de lanzamiento.
• Telemetría: Verifica la llegada de actualizaciones, progreso de descarga, completación de instalación, salud de arranque y errores.

Despliegue canario y completo

• Control de cohorte: Comience con un público interno o beta deliberadamente pequeño.
• Presupuesto de salud: Mantenga la promoción si se superan los límites aprobados por el equipo en fallas de lanzamiento, fallas de descarga de actualizaciones, excepciones del renderizador o fallas de autenticación.
• Aprobación de promoción: Requiere una decisión explícita de ir o no ir antes de mover la versión a la alimentación estable.
• Impacto del cliente: Prepárese para enviar mensajes de soporte antes de la distribución amplia, no después del primer incidente.

Respuesta a incidentes

Si el nuevo binario no se inicia, se rompe la creación de procesos o las descargas de actualizaciones dejan de completarse, detenga la promoción inmediatamente. Restaure el manifiesto firmado anterior, invalide la marca de etapa y verifique que los clientes frescos se resuelvan a la versión anterior. Luego, confirme a través de la telemetría que la flota está recuperándose antes de comunicar el cierre.

Los comandos de rollback exactos dependen de su proveedor, pero la secuencia siempre debe documentarse: Flip el manifiesto de canal a la versión anterior, invalide la etiqueta de etapa, empuje un marcador de actualización forzada si es necesario para la recuperación, y verifique el camino de descenso con la telemetría en vivoUn rollback que no se ha probado es solo una esperanza.

Capgo ofrece un actualizador de Electron para entregar cambios en la capa web firmados, canales dirigidos, controles de lanzamiento y observabilidad de actualizaciones sin volver a construir la caja nativa para cada cambio en el renderer. Si desea separar las liberaciones de binarios nativos de la entrega controlada de JavaScript y CSS, visite Capgo y evalúelo junto a su pipeline de liberación de Electron existente.