Auto Update Aplikasi Electron: Panduan Praktis 2026

Anda sudah merilis build Electron, halaman rilis sudah live, dan tiket support pertama masuk bahkan sebelum kopi Anda selesai diseduh. Satu user bilang aplikasinya tidak menemukan update. User lain sudah download tapi tidak bisa install. User ketiga masih menjalankan binary lama dengan alur autentikasi yang rusak, sementara logs Anda hampir tidak menunjukkan apa pun yang berguna.

Itulah kenyataan yang tidak nyaman dari auto update aplikasi Electron. Updater API hanyalah satu komponen. Rilis produksi juga bergantung pada platform signing, transport policy, manifest, hosting, lifecycle events, observability, kontrol rollout, dan jalur rollback. Kalau salah satu saja dianggap opsional, patch rutin bisa berubah jadi insiden sepanjang malam.

Table of Contents

• Insiden Update Jam 2 Pagi yang Jadi Awal Panduan Ini
• Memilih Jalur Electron Updater yang Tepat
• Implementasi Alur Auto-Update di Main Process
  • Konfigurasi target publish terlebih dahulu
  • Jadwalkan pengecekan dan expose lifecycle events
  • Beri tahu renderer tanpa menghambat pekerjaan
• Merangkai CI/CD untuk Rilis Bertanda Tangan dan Manifest
  • Jadikan signing eksplisit di CI
• Rollout, Channels, dan Strategi Rollback
  • Gunakan cohort sebelum peluncuran luas
• Menjadikan Auto-Update sebagai Kontrol Keamanan
  • Lindungi metadata sama hati-hatinya dengan binary
• Runbook dan Checklist Update Produksi
  • Gerbang pre-release
  • Canary dan rollout penuh
  • Respons insiden

Insiden Update Jam 2 Pagi yang Jadi Awal Panduan Ini

Release lolos CI dan terlihat biasa saja. Di akhir Jumat, seorang developer mendorong build Electron tanpa tanda tangan, dan job publish mengunggah cukup banyak aset sehingga release tampak lengkap. Aplikasi berhasil dijalankan di lingkungan testing, tetapi tidak ada yang menguji jalur update dari build produksi yang sudah terpasang.

Pukul 02.08, PagerDuty memberi tahu engineer on-call. Alur autentikasi baru gagal untuk sebagian fleet, dan pengguna yang menerima update tidak dapat menyelesaikan sign-in. Pengguna lain tetap di versi sebelumnya karena updater tidak dapat memverifikasi atau menginstal artifact. Beberapa pelanggan mengalami rilis yang rusak, sementara sisanya menjalankan versi berbeda tanpa penjelasan yang jelas.

Investigasi mengikuti lima pemeriksaan:

1. Periksa release feed. Binary ada, tetapi metadata yang diharapkan tidak secara jelas menetapkan klien mana yang harus menerimanya. Manifest adalah kontrak antara release pipeline dan klien yang terinstal, bukan detail upload opsional.
2. Periksa signing. Rilis tidak ditandatangani dengan benar, sehingga verifikasi gagal di platform yang terdampak. Signing harus memblokir publikasi jika hilang atau tidak valid.
3. Bandingkan logs klien. Error update tidak pernah sampai ke telemetri pusat. Aplikasi menelan event itu dan terus berjalan, sehingga tim tidak punya bukti yang bisa diandalkan.
4. Cek kontrol rollout. Tidak ada channel internal atau cohort bertahap. Semua klien yang memenuhi syarat memakai feed yang sama, jadi kegagalan menyebar tanpa titik pembatasan.
5. Search for a rollback. Tim tidak memiliki prosedur teruji untuk mempublikasikan ulang versi sebelumnya atau mengalihkan klien dari rilis yang rusak.

Dokumentasi resmi Electron memperjelas batasan platform. Linux tidak memiliki dukungan auto-updater bawaan, dan permintaan update macOS harus memenuhi persyaratan App Transport Security. Dokumentasi juga menyebutkan signing sebagai prasyarat untuk update macOS yang andal dan verifikasi rilis. The Dokumentasi Electron autoUpdater mendefinisikan batasan API, sementara sistem rilis harus menegakkan kontrol operasional di sekitarnya.

Pelajaran dari postmortem: Updater yang tidak bisa menjelaskan apa yang terjadi adalah upaya instalasi jarak jauh dengan telemetri yang hilang.

Biayanya melampaui waktu engineering. Pelanggan kehilangan kepercayaan pada klien desktop, tim support harus menjelaskan perilaku yang tidak konsisten, dan tim menghabiskan hari kerja berikutnya untuk membangun ulang proses rilis yang seharusnya sudah ada sebelum insiden.

Perlakukan auto-update sebagai sistem operasional. Signing adalah gerbang rilis, manifest mendefinisikan kontrak klien, kanal rollout membatasi paparan, dan rollback tetap menjadi jalur yang sudah diuji, bukan improvisasi darurat.

Memilih Jalur Electron Updater yang Tepat

Pukul 2 pagi, pilihan updater yang salah menjadi masalah operasional. Pembaruan biner native harus menangani signing, manifest, installer, dan rollback. Perubahan JavaScript atau CSS yang hanya di renderer mengikuti jalur berbeda. Kendala hosting juga penting: proyek kecil yang di-hosting di GitHub tidak membutuhkan kontrol rilis yang sama dengan layanan distribusi enterprise.

Untuk proyek yang menggunakan electron-builder dengan publikasi artefak yang ditandatangani, electron-updater biasanya menjadi default yang praktis. Ekosistemnya mencakup target publikasi, manifest rilis, unduhan artefak, dan instalasi pada peluncuran berikutnya. Mendukung beberapa model hosting, tetapi tim Anda tetap bertanggung jawab atas signing, ketersediaan feed, kebijakan kanal, kontrol rollout, dan monitoring. Integrasi updater Electron untuk Capgo relevan saat mengevaluasi model pengiriman hybrid untuk bundle lapisan web di samping rilis native.

update-electron-app cocok untuk tim yang ingin integrasi kecil di sekitar GitHub Releases. Memeriksa saat startup dan kemudian pada interval berulang, yang membuat setup sederhana tetapi menyisakan sedikit ruang untuk pemilihan kanal lanjutan, lalu lintas bertahap, dan aturan rollback kustom. Paket ini wajar untuk proses rilis kecil, asalkan GitHub Releases dan ketersediaannya sesuai dengan persyaratan operasional Anda.

Layanan kustom seperti Hazel, Nuts, atau feed internal cocok ketika otorisasi rilis, targeting tenant, catatan audit, atau aturan deployment yang diatur membenarkan biaya implementasi. Trade-off-nya adalah kepemilikan berkelanjutan. Tim Anda harus mendefinisikan semantik manifest, melindungi kunci penandatanganan, menjaga kompatibilitas klien, dan menguji unduhan yang gagal, rilis yang ditolak, serta perilaku rollback.

Live Update dapat mengirim perubahan renderer-only tanpa membangun ulang shell native. Ini tidak menggantikan pembaruan biner ketika Electron, modul native, izin, atau perilaku installer berubah. Gunakan electron-updater kecuali Anda membutuhkan logika rollout kustom. Jika logika kustom diperlukan, bangun di sekitar konvensi manifest dan artifact yang mapan, bukan membuat ulang perilaku unduhan dan pembaruan diferensial. Jalur yang andal adalah yang tim Anda bisa amati, stage, dan balikkan di bawah tekanan.

Implementasi Alur Auto-Update di Main Process

Proses utama harus memiliki pemeriksaan dan instalasi pembaruan. Renderer dapat menampilkan status, tetapi tidak boleh memutuskan apakah pembaruan executable dapat dipercaya atau kapan aplikasi keluar.

Konfigurasi target publish terlebih dahulu

Konfigurasi electron-builder minimal mungkin terlihat seperti ini:

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

Pisahkan feed beta dan stabil. Channel adalah kebijakan rilis, bukan sekadar label di UI. Setiap channel harus merujuk ke artifact dan manifest yang ditandatangani dengan benar.

Jadwalkan pengecekan dan expose lifecycle events

Memanggil checkForUpdates() Hanya melakukan pengecekan saat startup adalah kesalahan umum di produksi. Pengguna bisa meninggalkan aplikasi terbuka selama berhari-hari, sehingga proses utama membutuhkan interval yang terkontrol dan strategi retry yang menghormati operasi offline.

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

Perilaku event update yang tepat bervariasi tergantung platform dan setup packaging, jadi uji dari artifact yang terinstal, bukan mode development. Dokumentasi Electron juga menyoroti masalah timing startup di Windows, termasuk kasus first-run Squirrel. Jangan memicu pengecekan update sebelum aplikasi menyelesaikan inisialisasi spesifik platform yang dibutuhkan.

Beri tahu renderer tanpa menghambat pekerjaan

Preload bridge sebaiknya mengekspos API yang sempit:

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

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

Progress bar di sisi renderer bisa tetap dibuat sederhana secara sengaja:

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

Letakkan instalasi di balik persetujuan pengguna di produksi, kecuali aplikasi Anda punya alasan kuat untuk langsung restart. Atur isQuitting flag sebelum quitAndInstall(), karena handler penutupan jendela biasa bisa menghalangi installer untuk mengambil alih.

Dua kegagalan perlu pengujian eksplisit. Pertama, client yang sudah berjalan harus memanggil checkForUpdates() secara terjadwal, bukan hanya saat startup. Kedua, error event harus sampai ke logs dan telemetry. Jika aplikasi menelannya tanpa melapor, alur troubleshooting aplikasi Anda dimulai dari tebakan, bukan bukti.

Merangkai CI/CD untuk Rilis Bertanda Tangan dan Manifest

Release pipeline adalah sumber kebenaran untuk apa yang diinstal pengguna. Build lokal yang jalan di mesin satu developer tidak membuktikan bahwa binary, manifest, signature, dan channel yang dipublikasikan semuanya menggambarkan rilis yang sama.

Model publish electron-builder mengharapkan metadata rilis dan target update bergerak bersama. Untuk banyak konfigurasi, itu berarti artifact seperti latest.yml untuk Windows dan latest-mac.yml untuk macOS, bersama paket khusus platform dan file blockmap. Manifest yang hilang bisa membuat binary yang valid tidak terlihat oleh client.

Jadikan signing eksplisit di CI

Pola GitHub Actions yang disederhanakan seperti ini:

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

Gunakan secret khusus platform dan simpan material signing di luar repositori. Kegagalan signing harus menghentikan job, bukan menghasilkan fallback unsigned yang di-upload manual.

Konfigurasi publish harus mengidentifikasi provider dan channel secara konsisten:

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

Sebelum publikasi, gerbangkan job berdasarkan versi package, tag, commit SHA, dan hasil smoke-test. Setelah publikasi, verifikasi bahwa feed berisi manifest yang diharapkan dan manifest tersebut menunjuk ke artifact persis yang dihasilkan oleh job tersebut. The setup continuous integration berguna saat Anda memformalkan pemeriksaan tersebut, dan tim yang membandingkan orkestrasi pipeline juga mungkin diuntungkan dengan pemahaman tentang kapan menggunakan Jenkins dan Ansible bersama.

Perintah yang biasanya mengungkap rilis tidak lengkap sengaja dibuat sederhana:

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

Pemeriksaan tersebut tidak menggantikan uji instalasi yang ditandatangani. Namun, mereka dapat menangkap kesalahan operasional berupa upload binary tanpa metadata yang dibutuhkan klien untuk menemukannya.

Rollout, Channels, dan Strategi Rollback

Feed rilis sebaiknya berperilaku lebih seperti target deployment daripada folder unduhan. Jaga internal, beta, dan terbaru channel tetap terpisah, dengan setiap channel didukung oleh manifest dan set artefak bertanda tangan sendiri. Promosi harus memindahkan rilis yang sudah diuji antarkebijakan, bukan menimpa file saat klien sedang mengunduhnya.

Pemisahan channel juga melindungi produksi dari build pengujian yang tidak sengaja. Updater harus mengetahui apakah klien termasuk kohort internal, audiens beta, atau populasi stabil sebelum mengevaluasi feed.

Gunakan cohort sebelum peluncuran luas

Field manifest kustom dapat menyatakan pengiriman bertahap:

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

Proses utama dapat menetapkan bucket per pengguna yang stabil, lalu membandingkan bucket tersebut dengan rolloutPercentage. Penugasan yang stabil itu penting. Pengguna yang berpindah antara status memenuhi syarat dan tidak memenuhi syarat pada setiap pemeriksaan akan mendapat perilaku tak terduga, sehingga laporan dukungan sulit ditafsirkan.

Perluas kohort hanya setelah rilis melewati jendela observasinya. Jendela yang tepat harus mencerminkan pola penggunaan Anda, tetapi keputusannya harus didasarkan pada sinyal, bukan hanya pada kalender. Lacak hasil pemeriksaan pembaruan, penyelesaian unduhan, kesehatan peluncuran, crash, exception renderer, dan keberhasilan autentikasi.

Jangan samakan rollback dengan menghapus artifact. Client yang sudah ada mungkin telah meng-cache metadata, dan sebagian mungkin sudah menjalankan versi yang bermasalah. Rencana rollback membutuhkan rilis yang ditandatangani sebelumnya, perubahan feed, dan perilaku client yang bisa melakukan recovery.

Aturan operasional: Rollback harus dapat dieksekusi oleh engineer on-call tanpa perlu rebuild aplikasi selama insiden.

Dalam praktiknya, runbook harus mempromosikan kembali manifest rilis sebelumnya ke channel yang terdampak, membatalkan marker staging, dan memastikan bahwa pemeriksaan baru mengarah ke versi yang aman. Jika masalah ada di renderer code dan bukan di native shell, rollback lapisan web yang ditargetkan mungkin lebih cepat. Platform seperti phased rollouts Capgo bisa relevan untuk lapisan delivery terpisah itu, tapi jangan samarkan batas antara rollback binary native dan rollback web-bundle.

Menjadikan Auto-Update sebagai Kontrol Keamanan

Updater Electron mengunduh file code yang dapat dieksekusi dan menginstalnya dengan interaksi pengguna minimal. Hal ini menjadikan jalur update sebagai batas keamanan, bukan sekadar fitur kenyamanan. Dokumentasi resmi Electron menjelaskan batasan platform seperti ATS macOS, dan cakupan keamanan telah mendokumentasikan skenario tahun 2022 di mana penyerang yang mengendalikan infrastruktur update dapat menyajikan paket berbahaya yang tetap lolos pemeriksaan penandatanganan code, seperti yang dibahas dalam dokumentasi keamanan auto-update Electron Builder.

Signing Code tetap menjadi fondasi, tetapi bukan keseluruhan model kepercayaan. Sign setiap rilis, verifikasi sertifikat dan identitas selama CI, dan pelihara prosedur rotasi key yang terdokumentasi. Di macOS, kombinasikan signing dengan notarization dan hardened runtime yang sesuai dengan aplikasi Anda. Di Windows, pastikan kepemilikan sertifikat, perpanjangan, dan akses build dapat diaudit. Linux butuh strategi spesifik distribusi karena Electron tidak menyediakan updater universal bawaan di sana.

Lindungi metadata sama hati-hatinya dengan binary

Binary yang sudah di-sign tetap bisa dikaitkan ke rilis yang salah jika channel metadata disusupi atau salah konfigurasi. Pertimbangkan menambahkan manifest signature yang diverifikasi terhadap public key yang tertanam di aplikasi, terapkan batas versi minimum, dan tolak downgrade tak terduga kecuali jalur recovery yang diotorisasi secara eksplisit mengizinkannya.

Feed juga perlu kontrol produksi:

• Batasi akses publish: Berikan CI hanya izin yang dibutuhkan untuk publish release assets.
• Lindungi signing secrets: Simpan sertifikat dan private key di managed secret storage, bukan di file repository.
• Pin dependensi: Lock Electron, electron-builder, dan transitive dependencies di CI.
• Tinjau artefak: Scan package yang dihasilkan dan bandingkan dengan commit serta versi yang dimaksud.
• Wajibkan transport aman: Ikuti persyaratan ATS dan HTTPS ketat untuk permintaan update.
• Pantau kegagalan verifikasi: Anggap kegagalan signature atau manifest yang berulang sebagai insiden keamanan, bukan sekadar gangguan jaringan biasa.

Ekosistem tooling Electron yang terawat terus menambahkan cakupan packaging dan updater, tetapi pemeliharaan tidak menghilangkan kebutuhan threat modeling. Tujuan praktisnya adalah memastikan bahwa penyerang yang berhasil mengompromi bucket, CDN, atau langkah build tetap tidak bisa membuat klien menerima rilis yang tidak sah. panduan verifikasi signature memberikan konteks yang berguna untuk merancang lapisan verifikasi tambahan tersebut.

Runbook dan Checklist Update Produksi

Sebuah rilis dianggap siap hanya jika engineer lain dapat mengoperasikannya di bawah tekanan. Simpan checklist dekat dengan job deployment dan channel insiden.

Gerbang pra-rilis

• Identitas versi: Pastikan versi package, tag rilis, commit SHA, dan changelog saling sesuai.
• Penandatanganan: Verifikasi bahwa setiap artifact platform telah ditandatangani dan proses notarization atau validasi setara telah selesai.
• Kontrak manifest: Konfirmasi latest.yml, latest-mac.yml, hashes, paths, dan blockmaps sesuai dengan artifact yang diunggah.
• Keamanan channel: Publikasikan ke feed internal atau beta sebelum mempromosikan channel rilis.
• Telemetri: Pastikan update checks, progres download, penyelesaian instalasi, kesehatan launch, dan error diterima dengan benar.

Canary dan rollout penuh

• Kontrol kohort: Mulai dengan audiens internal atau beta yang sengaja dibuat kecil.
• Anggaran kesehatan: Tahan promosi jika kegagalan peluncuran, kegagalan unduhan pembaruan, pengecualian renderer, atau kegagalan autentikasi melampaui batas yang disetujui tim.
• Persetujuan promosi: Wajibkan keputusan go atau no-go yang eksplisit sebelum memindahkan rilis ke feed stabil.
• Dampak pada pelanggan: Siapkan pesan dukungan sebelum distribusi luas, bukan setelah insiden pertama.

Respons insiden

Jika binary baru gagal diluncurkan, proses spawning rusak, atau unduhan pembaruan berhenti selesai, hentikan promosi segera. Pulihkan manifest bertanda tangan sebelumnya, invalidasi penanda staging, dan verifikasi bahwa klien baru mengarah ke versi sebelumnya. Kemudian, konfirmasi melalui telemetri bahwa armada pulih sebelum mengomunikasikan penutupan.

Perintah rollback yang tepat bergantung pada provider Anda, tetapi urutannya harus selalu didokumentasikan: ubah manifest channel ke versi sebelumnya, invalidasi tag staging, dorong penanda pembaruan paksa jika pemulihan membutuhkannya, dan verifikasi jalur downgrade dengan telemetri langsung. Rollback yang belum diuji hanyalah harapan.

Capgo menawarkan updater Electron untuk delivering perubahan lapisan web bertanda tangan, channel tertarget, kontrol rollout, dan observabilitas pembaruan tanpa membangun ulang shell native untuk setiap perubahan renderer. Jika Anda ingin memisahkan rilis binary native dari pengiriman JavaScript dan CSS yang terkontrol, kunjungi Capgo dan mengevaluasinya bersama pipeline rilis Electron yang sudah ada.