26 May 2017

Electron AutoUpdater - 101

Setting up a AutoUpdater for your electron app is actually a simple process with some time on terminal and editor. But, scattered notes and guides may it hard. Ths post will guide you through the entire steps to setup a Electron AutoUpdater!

Yes, It’s 2017… You can build native desktop apps with the very superior language of the web, Javascript. Thanks to the entire team of contributors of Electron, the job got a lot more easier. You can now develop a web app without any special attention to be paid to electron and wrap the same with a container that helps to run the app in various native platforms.

I don’t need to talk much about the web app development as you might be well experienced than me 😉 Post development process needs attention here. That being said, major attention must be given to building & packaging process and again thanks to the team for the electron-packager which helps in packaging out-of-the-box. Now let us talk about distribution…

Now comes the core of the story. Yeah, you are right, distribution may happen seriously in hell a lot of ways.

You may

  • Pack up the app and mail it to your peer dev to test.
  • Want to distribute it internally to all your team.
  • Need to distribute it to your customers via Mac App Store or Windows store or something similar

In this part of the my electron-series ( yeah, planning for a series ), I’m going to explain about the second one in the list as the first one will be straight forward. Distributing a native app with your team is as easy as sending the packed app to your team mail. It’s that’s simple! Hope this helps you. Meet you in the next series…

**Just Kidding…**😉😛

Actually I’m not kidding entirely. Distributing a native app built with electron, without any honey mix, is just a mail away. But, adding honey drops such as autoUpdater will be somewhat tricky especially for non-native guys like me.

autoUpdater is nothing but a built-in tool in electron to enable the app to be auto-updated automatically when a new version of the app gets released.

This is something significant in my case. I was building a QA app for internal usage for my team. The issue with the native app is that, the updates should be patched up and released with a considerable amount of changes and users have to re-install it every time. In my case, I can’t expect that my fellow devs to check for updates to download and re-install the app every time I release an update. So, I decided to go with the auto update feature of electron. I will be explaining the whole process with respect to Mac OS. I Will be covering about Windows and may be Linux in my future posts.

The three major glitches I faced were…

  • Code-signing the packaged app (mandatory, in case of OS X).
  • Setting up an electron update server.
  • Configuring the app for aut0-update.

Code-signing is one of the mandatory steps for enabling autoUpdater for Mac app. Code-signing the mac app is actually a very easy process with 3 terminal commands if you do it manually. But, lack of documentation and scattered notes made it a hell. With respect to electron, you don’t even dive into terminal for this. Its handled for you internally!

Let’s get started with the code-signing process and make your hands dirty with few lines of code 😊 The first thing you need to know is that, you need a Developer ID Application certificate to distribute a mac app outside Mac AppStore. Ordinary Mac Developer certificate for development cannot be used to code-sign the mac app. Certificate will be something similar to Developer ID application (), as in the snap (highlighted one).

This certificate can be generated by the member with Team-Agent role. If your role is not Team-Agent, then find someone with this role and ask them to generate this certificate from apple developer console. Mostly, your mobile team-lead will have one.

Once you get your Developer ID Application certificate, just install (double-click open) it in your Keychain Access.

You are now half way 🔥. Now lets dive into the actual signing setup. This is super simple. Just add the appropriate certificate in your forge-config file (if you have one) or in your package.json under electronPackagerConfig.

packager config

HoHooo…! You signed the app that needs to be distributed. If anything goes wrong. Try to sign your .app file manually using the certificate by following the instructions mentioned here. If you use any invalid certificate, then in the last step, the app will get a rejected message i.e, the terminal will spit out <appName>.app: rejected. So, be sure to have a valid certificate 👾.

Next up, the setup process of the update server.

Backend support for auto-update can be achieved via three major packages as mentioned in the official docs (strongly recommend you to skim through it). I assume that in most of the scenarios, github cannot be used for backing up the release as our apps would not be opensource. So, I prefer electron-release-server to serve the updates which involves self hosting using postgres DB. Again, the official docs itself is a self explanatory one for someone who already has some knowledge on backend techs and databases. But as a front end guy, it took me a while to get this setup done as the setup instructions were scattered on 3 to 4 github documentation pages. Luckily, I got help from one of my peer dev who has knowledge on postgres. I’ll compile those steps here.

Step 1:

Install postgres using a brew command - brew install postgres . This command needs brew preinstalled in your machine. That’s only a command away. After a successful installation, running postgres --version should output a version of postgres (not to worry, unless the message is something like postgres: command not found 😉 )

After installing the postgres DB, make sure you start the server with the command.

pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start

The path usr/local/var/postgres is hardcoded, as generally postgres will be installed in this location. After starting the server, create a DB and port into in it using

createdb <db name - of your choice>
psql <db name>

After starting the server, we have to create a postgres role.


replace <PASSWORD> with your original password. You can replace electron_release_server_user with the name of your choice (you may need to follow this name in the following configurations too) . I would advise you to leave it undisturbed and go with the default one.

Now, we have to create databases for the role and session.

CREATE DATABASE electron_release_server OWNER "electron_release_server_user";
CREATE DATABASE electron_release_server_sessions OWNER "electron_release_server_user";

That’s it! You have created a dedicated DB and role for our release process.

Step 2:

Now it’s time to setup deployment. The default adapter is sail deployment adapter. Clone the sails-pg-session adapter and copy the sql dump into your postgres DB using the following commands.

cd sails-pg-session

psql electron_release_server_sessions < ./sql/sails-pg-session-support.sql

Kindly, ensure that you name the session as electron_release_server_sessions. If you have any custom names, kindly replace it with the same.

Step 3:

Next, follow the below commands to install electron-release-server and its dependencies.

cd electron-release-server
npm install

Now, we need to create a config.js file. electron-release-server has a built-in config template. Let’s copy that for simplicity using cp config/local.template config/local.js

Open the file config/local.js and replace the connection and session object with the following snippet. As long as you follow the default naming convention, your session and connection object will be like

connections: {
  postgresql: {
  adapter: 'sails-postgresql',
  host: 'localhost',
  user: 'electron_release_server_user',
  password: '<PASSWORD>', // replace with your password 
  database: 'electron_release_server'
session: {
  secret: '<your secret>', // Generate using: https://www.grc.com/passwords.htm
  database: 'electron_release_server',
  host: 'localhost',
  user: 'electron_release_server_user',
  password: '<PASSWORD>', // replace with your password
  port: 5432

And then, add the appUrl (where the electron-release-server is running, as of now, its http://localhost) and authentication variable (for admin access) in the local.js file. So that, your config/local.js file should look something like this. As a last note, make sure you are in latest Node version (LTS). You can download the LTS release here

Hi-fi… 🖐️ You are almost done. Let’s drive the server with the command npm run start from the root of the project. If it fails, use with sudosudo npm run start

Keep calm and wait for the server to deploy successfully and check http://localhost to see your beautiful release console.

Electron release server — Home screen

Configuring your electron project for auto-update is fairly simple and you can follow the doc. All the events have been explained well in the doc. As a debugger hand, you can use winston logger to debug the event hooks. Following is the main.js snippet with the debug code. Actually, thanks to lazlojuly for introducing winston to me 😉

Hey dude… Do you know something… You are done 💪 Build your app with a valid certificate (saying it many times as it needs to be) and upload the zipped asset to the electron-release-server! electron-release-server has a small video on uploading the assets into server and you can find it here. Before uploading it into the server, run it once in you machine to check for the certificate validations. For accessing the admin panel, use the username and password you configured in electron-release-server’s local.js file.

Wrap UP ⬆️

autoUpdater is an awesome feature in electron and worth exploring it. I have narrated the entire flow with respect to my own use case. If you have any specific stuffs that need to be clarified, you can comment out here and reach me out via twitter. I’ll try to help you out. You should join electron’s Slack channel as well as electron-release-server Gitter channel to get more info. Dudes out there were awesome 🏅Thanks for your time for this post.