Actualización automática de aplicaciones de Electron: Una guía práctica de 2026

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

Esa es la realidad incómoda de Actualización automática de la aplicación Electron. El actualizador API es solo un componente. Una versión 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 la implementación y un camino de devolución.

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 la aplicación Electron
• Implementar el flujo de actualización automática en el proceso principal
  • Configura el objetivo de publicación primero
  • Programa las comprobaciones y expone los eventos de ciclo de vida
  • Mantén informado al renderizador sin bloquear el trabajo
• Conecta CI/CD para versiones firmadas y manifiestos
  • Haz explícita la firma en CI
• Implementaciones, canales y estrategia de devolución
  • Use cohorts antes de la exposición amplia
• Tratar la actualización automática como un control de seguridad
  • Proteger el metadato con la misma cuidado que el binario
• El Libro de Procedimiento y Lista de Verificación de Actualización de Producción
  • Las barreras de pre-lanzamiento
  • Canario y lanzamiento completo
  • Respuesta a incidentes

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

La liberació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 liberació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.

A las 2:08 a.m., PagerDuty alertó al ingeniero de turno. Un nuevo flujo de autenticación falló para parte de la flota, y los usuarios que recibieron la actualización no pudieron completar la inscripció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 los metadatos esperados no establecían claramente a 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. Los 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 confiable.
4. Revisar los controles de la actualización. No había un canal interno o una cohorte de etapa. Cada cliente elegible utilizaba 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 republishar la versión anterior o dirigir a los clientes hacia la liberación rota.

La documentación oficial de Electron hace claras las limitaciones de la plataforma. Linux no tiene soporte integrado para actualizaciones automáticas.y las solicitudes de actualización de macOS deben satisfacer Requisitos de seguridad de transporte de aplicacionesLa documentación también identifica la firma como un requisito previo para actualizaciones de macOS confiables y verificación de lanzamiento. La Documentación de actualización de Electron define las restricciones API, mientras que el sistema de liberación debe imponer el control operativo circundante.

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

El costo se extendió más allá del tiempo de ingeniería. Los clientes perdieron confianza en el cliente de escritorio, el soporte tuvo que explicar el comportamiento inconsistente y el equipo pasó el próximo día laborable reconstruyendo un proceso de liberación que debería haber existido antes del incidente.

Trate la actualización automática como un sistema operativo. La firma es una puerta de liberación, 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 la actualización de Electron

En la 2 a.m., la elección incorrecta del actualizador se convierte en un problema operativo. Una actualización binaria nativa 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 alojamiento también importan: un pequeño proyecto GitHub-albergado no necesita los mismos controles de liberación que un servicio de distribución empresarial.

Para proyectos que utilizan electron-builder con publicación de artefactos firmados, electron-updater electron-updater Electron updater integration for Capgo La integración del actualizador de Electron para __CAPGO_KEEP_0__

update-electron-app suits teams that want a small integration around GitHub Releases. It checks at startup and then on a recurring interval, which keeps the setup simple but leaves less room for advanced channel selection, staged traffic, and custom rollback rules. The package is reasonable for a small release process, provided GitHub Releases and its availability match your operational requirements.

A un servicio personalizado como Hazel, Nuts o una alimentación interna se ajusta cuando la autorización de lanzamiento, la dirección de inquilino, los registros de auditoría o las reglas de despliegue regulado justifican el costo de implementación. El intercambio es la propiedad en curso. 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 del renderizador sin reconstruir la caja nativa. No reemplazan las actualizaciones binarias cuando cambian Electron, módulos nativos, permisos o comportamiento del instalador. Utilice electron-updater a menos que necesite lógica de lanzamiento personalizada. Si se requiere lógica personalizada, construya alrededor de las convenciones establecidas de manifiesto y artefactos 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 alimentaciones 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

Invocar checkForUpdates() un error común en producción es solo durante el arranque. 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 respeta 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 según la plataforma y la 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 la plataforma que necesita.

Mantenga informado al renderizador sin bloquear el 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');
  }
});

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

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

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

Configuración de CI/CD para versiones firmadas y manifestos

La línea de producción es la fuente de verdad de lo que los usuarios instalan. 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 describen la misma versión.

El modelo de publicación de Electron-builder 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 específicos de plataforma y archivos de bloqueo. Un manifiesto faltante puede hacer que un binario perfectamente válido sea invisible para los clientes.

Hacer explícita la firma 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

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

La configuración de publicación debe 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, filtre el trabajo por la versión del paquete, la etiqueta, el SHA del commit y el resultado de la prueba de humo. Después de la publicación, verifique que el feed contenga 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 estás formalizando esas comprobaciones, y los equipos que comparan la orquestación de pipeline también pueden beneficiarse de entender cuándo 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

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

Despliegues, Canales y Estrategia de Rebobinado

La fuente de liberación debe comportarse más como un objetivo de despliegue que como una carpeta de descarga. Mantener interno, beta, y últimos canales separados, con cada canal respaldado por su propio manifiesto y conjunto de artefactos firmados. La promoción debe mover una liberació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 debe saber si un cliente pertenece a un conjunto de cohortes internas, un público de beta o la población estable antes de evaluar la fuente.

Usar cohortes antes de la exposición amplia

Un campo de manifiesto personalizado puede expresar la entrega estadiada:

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

Expandir la cohorte solo después de que la versió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, el estado de arranque, los errores de lanzamiento, las excepciones del renderizador y el éxito de la autenticación.

No confunda 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 de lanzamiento firmada anterior, un cambio en la fuente, 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 libro de instrucciones 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 de concha nativa, un rollback de capa web dirigido puede ser más rápido. Una plataforma como code rollouts de fase puede ser relevante para ese nivel de entrega separado, pero no debe ocultar la frontera entre un rollback de binario nativo y un rollback de paquete web. Capgo phased rollouts Un actualizador de Electron descarga ejecutables __CAPGO_KEEP_0__ y puede instalarlos con poca interacción del usuario. Eso hace que el camino de actualización sea un

__CAPGO_KEEP_0__ rollouts de fase

An Electron updater downloads executable code and can install it with little user interaction. That makes the update path a límite de seguridadno es solo una característica de conveniencia. La documentación oficial de Electron describe las 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 podrían servir paquetes maliciosos que aún pasaban los code-verificaciones de firma, como se discutió en el documentación de seguridad de 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 cuidado que el binario

Un binario firmado todavía puede estar asociado con la liberación incorrecta si el canal de metadata está comprometido o mal configurado. Considera agregar una firma de manifesto verificada contra una clave pública incorporada en la aplicación, imponga una versión mínima permitida y rechace los descensos inesperados a menos que un camino de recuperación autorizado los permita explicitamente.

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

• Restringe el acceso a la publicación: Dé a CI solo los permisos necesarios para publicar activos de liberación.
• Protege los secretos de firma: Mantén los certificados y las claves privadas en almacenamiento de secretos gestionados, no en archivos de repositorio.
• Dependencias a fijar: Bloquear Electron, electron-builder y dependencias transitivas en CI.
• Revisar artefactos: Escanear los paquetes generados y compararlos con el commit y versión previstos.
• Requerir transporte seguro: Seguir los requisitos de ATS y HTTPS estricto para solicitudes de actualización.
• Monitorear fallas de verificación: Tratar las fallas de firma o manifiesto repetidas como eventos de seguridad, no como ruido de red ordinario.

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

El Libro de Actualizaciones y Lista de Verificación de Producción

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

Vigilancias previas a la liberación

• Identidad de la versión: Confirmar la versión del paquete, etiqueta de liberación, SHA de commit y changelog coinciden.
• Autenticación: Verificar que cada artefacto de plataforma esté firmado y que la notarización o la validación equivalente haya completado.
• Contrato de manifiesto: Confirmar latest.yml, latest-mac.yml, hashes, rutas y blockmaps coinciden con los artefactos cargados.
• Seguridad del canal: Pública en la alimentación interna o beta antes de promover el canal de liberación.
• Telemetría: Los confirmados de actualizaciones, el progreso de descarga, la finalización de la instalación, la salud de inicio y los errores están llegando.

Canario y lanzamiento completo

• Control de cohorte: Comienza con un público interno o beta deliberadamente pequeño.
• Presupuesto de salud: Mantén la promoción si las fallas de lanzamiento, las fallas de descarga de actualizaciones, las excepciones del renderizador o las fallas de autenticación superan los límites aprobados por el equipo.
• Aprobación de promoción: Requiere una decisión explicita de ir o no antes de mover la versión a la alimentación estable.
• Impacto del cliente: Prepara el mensaje de soporte antes de la distribución amplia, no después del primer incidente.

Respuesta a incidentes

If el nuevo binario falla al iniciar, la creación de procesos se rompe o las descargas de actualizaciones dejan de completarse, detenga la promoción inmediatamente. Restaure el manifiesto firmado anterior, invalide el marcador 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.

La secuencia exacta de comandos de rollback depende de su proveedor, pero la secuencia siempre debe estar documentada: 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 vivo.. Un rollback que no se ha probado es solo una esperanza.

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