ElectronMail is an unofficial ProtonMail desktop client with an offline store

A desktop client ProtonMail does not ship

ElectronMail is an unofficial desktop client for ProtonMail. The stated aim is to provide an enhanced desktop experience and to enable features that the official in-browser web clients do not support. That framing matters, because the project is not trying to replace ProtonMail with a different mail service, and it is not a mail server either. It is a desktop shell around the same account.

The audience is a ProtonMail user on a desktop who wants more than a tab in a browser: a native window, keyboard-first navigation, a local copy of the mailbox, and search that reaches into message bodies. The stack is stated plainly in the project description: Electron for the shell, TypeScript for the code, and Angular for the interface.

The licensing is GPL-3.0, and the repository is not archived. The last push was on 2026-09-29, the same day as the v5.3.10 release, with v5.3.9 on 2026-09-21 and v5.3.8 on 2026-07-01. Version numbering in the five range with releases a few weeks apart indicates a project that ships continuously rather than one that announces a major rewrite every year.

Three build targets under one Electron shell

The build scripts show how the app is put together, and the answer is that it is three compilations rather than one. The build script runs build:electron-main, build:electron-preload and build:web in sequence, so the main process, the preload bridge and the Angular front end are built separately. The main process entry point is declared in the package manifest as ./app/electron-main/index.cjs, and the webpack-configs directory holds the separate webpack configurations, one for the main bundle and at least one more for the others.

The type layer is patched rather than worked around. The prepare script installs husky, then runs ts-patch install -s and a ts-patch check, so the project modifies the TypeScript compiler itself to get the behaviour it needs. The source is split into scripts, patches and src at the top of the tree, and the presence of a code-generation script under scripts/code-generation that is invoked as part of build:electron-main suggests parts of the Electron layer are generated rather than hand-written.

The toolchain is modern and opinionated. The manifest requires node >= 24, the package is an ES module with type set to module, pnpm-lock.yaml and pnpm-workspace.yaml put the project in a pnpm workspace, and formatting is handled by dprint.json while linting uses eslint with an eslint.config.js flat configuration. zizmor.yml configures zizmor, the tool that audits GitHub Actions workflows for security problems, which is a sensible thing to find in a repository that ships signed binaries.

Reproducible builds and the package channels

The feature list leads with reproducible builds, and the project points at issue 183 for the details and for the way of verifying that the installation packages attached to the releases were assembled from the source code. For an unofficial client that handles mailbox credentials, that is the part of the design that deserves the most attention, because a user has to trust a binary that no upstream vendor signed.

Distribution runs through both the releases page and the Linux package repositories. The releases page is where the Linux, macOS and Windows installation packages live, and the project also lists the repository routes with their maintainers. The identifiers are electronmail-bin for the Arch User Repository, electron-mail for Snapcraft, com.github.vladimiry.ElectronMail for Flathub, electron-mail for Chocolatey, electronmail for Scoop and VladimirYakovlev/ElectronMail for Winget. The manifest that describes the application itself is short and explicit:

{
  "name": "electron-mail",
  "version": "5.3.10",
  "engines": {
    "node": ">=24"
  }
}

The maintainer column is more informative than the identifiers. The Arch User Repository, Snapcraft and Flathub entries have been maintained by the project author since v5.1.8, with an earlier maintainer before that, while the Scoop and Winget entries have no specific maintainer and are described as community. The Chocolatey entry is marked obsolete since mid 2026, previously maintained by the same author. So on Linux the choice between channels is mostly a choice about who is watching the updates, and on Windows the two package routes are community-run.

For anyone who wants to build from source instead, the manifest scripts cover the sequence. Installing the dependencies with pnpm is the first step, then the prepare script installs the git hooks and patches the compiler, and the build script compiles the three targets:

{
  "build": "npm-run-all build:electron-main build:electron-preload build:web",
  "prepare:husky": "husky install"
}

A GitHub Actions CI workflow is configured in the repository, and the packaging configuration lives in electron-builder.yml, which is where the per-platform artefacts are defined.

The local store keeps a decrypted copy of the mailbox

The feature that distinguishes ElectronMail from a browser tab is the local store, enabled since v2.0.0. It stores your messages in an encrypted database.bin file, and the project links to the FAQ for the purpose of that file. The consequence of enabling it is that the app can show your messages with no network connection, can run full-text search against them, and can export them to EML or JSON files. Attachments are the exception: their content is not stored locally, only the body content is.

Full-text search arrived separately, in v2.2.0, and it scans body content as well as the usual metadata. Message filtering came later still, in v4.11.0, and is described as JavaScript-based with unlimited rules, which turns the filter from a fixed list of conditions into something programmable. Filtering requires the local store to be enabled, because the filter runs against the stored messages.

Multi-account support is the other half of the feature set, and it includes per-account API entry points. The example given is the Tor version 3 address entry point, which you select from a dropdown to force a specific account to reach the provider through the Tor network, combined with a proxy configured as the linked discussion describes.

The design has a security dimension worth stating plainly. An encrypted local store is still a local store, and it holds a copy of every message body outside the provider's servers. The project does not describe in the documentation how the key for database.bin is managed, where it comes from, or how a user recovers or discards that store, so treat the file as sensitive material and delete it deliberately when you decommission a machine.

Unofficial status cuts both ways

The obvious limitation is the word unofficial in the project description. ProtonMail does not ship this client, does not support it, and does not guarantee that an account will keep working in it. A change to the ProtonMail API, to the login flow, or to the way the web clients obtain their credentials can break a third-party client without notice, and the failure will look like a login problem rather than a compatibility notice. The multi-account API entry point feature makes that risk more visible, because choosing a specific entry point ties the client to a particular server path.

The second limitation is the maintenance shape. Two of the six package channels have no specific maintainer, one is obsolete, and the ones with a named maintainer are the author's own. A community package that stops receiving updates is a normal outcome rather than a failure, and the practical fix is to move to the releases page or to a channel the author still maintains.

The third limitation is that the local store, search and filtering all depend on features that landed in different major versions, v2.0.0, v2.2.0 and v4.11.0, and the current line is 5.x. Upgrading across those jumps means the behaviour of search results and filters can differ from the version you used before. The project does not document a rollback procedure for a bad upgrade, so keeping the previous installer at hand is the practical precaution.

For a licence reading: GPL-3.0 covers the source of this application. It says nothing about ProtonMail's own terms of service, and the two are separate questions that an organisation using the client in a work context should answer for themselves.

Where the official web clients fit better

The real alternative is the official in-browser client, and the difference in approach is exactly what the project description claims. The web client is the reference implementation. It is written by the same organisation that operates the service, it is updated when the service changes, and it holds no persistent copy of your mailbox on the machine beyond what the browser caches. Where ElectronMail wins is offline access, body-level search, scriptable filters and a native window.

The cost of those additions is the thing to weigh. Running an Electron app means a Chromium process on the desktop holding a session with an encrypted mailbox, and a database.bin file on disk if the local store is on. The web client keeps the trust boundary inside the browser session that the service already designs for. For a personal mailbox that is usually a fair trade. For a company account on a managed laptop, the difference between an official client and an unofficial one with a local message archive is the kind of difference a security review will ask about.

A third option is a generic IMAP or SMTP desktop client, if the account allows it. That path is not covered by anything in this project's documentation, so the point is only that it exists as a category: a protocol-based client holds no decrypted archive and no special Proton API entry points, but it also does not give you the offline store and the JavaScript filters that are the reason to install this one.

Editorial conclusion

ElectronMail suits ProtonMail users who want a native window, an encrypted offline copy of their mail and full-text search across message bodies, and who are willing to run an unofficial client. It does not suit anyone who needs ProtonMail to stand behind the software, or who cannot accept that the local database.bin holds a decrypted copy of every message. Verify first which release your distribution ships, since the package maintainers differ and the Chocolatey route has been obsolete since mid 2026, and confirm your account's login still works in the client before you move your workflow across.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. vladimiry/ElectronMail on GitHub