Delta Chat Desktop ships the same frontend to Electron, a browser and Tauri

Three editions, one frontend, different confidence levels

The README splits the project into editions and the split is about maturity as much as about technology.

Electron is the default application. The README calls it the one currently deployed in app stores and used by most users. It lives in packages/target-electron.

The browser edition lives in packages/target-browser and is described in plain terms as highly experimental, with a webserver component and a web interface in the browser, meant at the moment only for developers and automated testing. There is a blog post and a fediverse thread linked for it.

A third edition, based on Tauri rather than Electron, is described as work in progress and, critically, is not in this repository at all. It has its own repository, deltachat/deltachat-tauri, and consumes this repository's frontend through a pinned `upstream/` submodule.

That submodule pin is the structural fact to hold onto. The frontend is the shared asset and the shell is not, so a frontend change reaches the Tauri edition only when somebody moves the pin. For anyone contributing, that is a release coordination question rather than a code question.

Install paths differ by what you want to happen to your system

Binary releases for every supported platform are at get.delta.chat, and the README links a Repology badge for packaging status across distributions.

On Linux, the primary distribution independent route is the Flatpak, maintained in its own repository at flathub/chat.delta.desktop with a prebuilt binary on Flathub. Arch users install the packaged build with `pacman -S deltachat-desktop`, or build the AUR package `deltachat-desktop-git`, and the README puts a warning on that second one: it compiles from the latest master, which can be more recent than the latest release and can introduce new bugs.

The manual AUR path is given as a sequence, fetching the PKGBUILD snapshot, extracting it, then building and installing with makepkg:

cd deltachat-desktop-git
makepkg -si
sudo pacman -U deltachat-desktop-git-<version>.tar.xz

On macOS the cask is the shortest route:

brew install --cask deltachat

and there is a DMG as the fallback. On Windows the downloads are on the same get.delta.chat page, but the README recommends the Microsoft Store release instead, specifically because automatic updates arrive there.

Building from source is a development path, not an install

The README is unusually explicit that the source path is not an installation. The warning says it is mostly for development purposes and will not install or integrate delta.chat into your system, and recommends sticking to the packaged methods otherwise.

With that caveat, the sequence is short. Clone the repository, install pnpm globally, install dependencies, build the Electron target once, then start it:

git clone https://github.com/deltachat/deltachat-desktop.git
cd deltachat-desktop
npm i -g pnpm
pnpm install
pnpm -w build:electron
pnpm -w start:electron

The `-w` flag is explained in the README as meaning the workspace root package, so those scripts work regardless of your current directory inside the repo.

For development against a locally built deltachat core rather than the bundled one, there is a separate document, docs/UPDATE_CORE.md. That separation between the UI repository and the core it embeds is the same split that shows up in the Tauri edition, and it is what lets the core be updated independently of a release.

A workspace where every script names its target package

The root package is private, named deltachat-desktop, typed as an ES module, at version 2.62.0. Nearly every script filters to a specific workspace package, which makes the target structure visible from the scripts alone.

`start:electron`, `build:electron`, `pack:asar`, `dev:electron`, `debug:electron` and `watch:electron` all target `@deltachat-desktop/target-electron`. The browser equivalent targets `@deltachat-desktop/target-browser`, and there is a separate `start:webserver` for the browser edition's server component. `debug:electron` maps to a `dev-inspect` script inside the target package, which is the Electron inspector entry point.

Checks are split the same way. `check` runs type checking recursively without bailing, then eslint over the tree with a cache, then prettier in check mode across SCSS, JS, TS, TSX, JSON and Markdown, then a target version check. There is a parallel `fix` path that applies eslint fixes and writes formatting, with the lint fix deliberately tolerant of failure since a formatting pass follows.

Translations have their own three step pipeline: `tx pull` from Transifex for the source and then all languages, a conversion script in bin/translations that produces a shared format, and a shell script that finds complete translations. That last step existing as a separate command suggests localisation coverage is tracked as a build concern.

What users actually configure, and where the docs live

The user facing documentation is four documents: troubleshooting, CLI flags, keybindings and a guide to making custom themes. The CLI flags document is the one worth knowing about, because a messenger with an account database usually has command line options worth reading before you assume you need the GUI.

The developer documentation is longer and more revealing about the project's shape. There is a contribution guide, a logging document, a general development document, styling guidelines, the core update document already mentioned, a document on how to do end to end testing, and a RELEASE.md describing how to do a release.

The end to end testing document next to the release procedure tells you the team runs real end to end tests rather than only unit tests, which is the practical answer to how an Electron application with a native core stays stable across platforms.

Configuration and database locations are a README section of their own, listed in the table of contents, and the CHANGELOG is generated rather than hand written: the repository root has a cliff.toml, which is the configuration file for git-cliff, a changelog generator driven by conventional commits.

Against an Electron rebuild, and against the Tauri route

The obvious comparison is building your own Electron wrapper around the delta.chat core. That is a legitimate option for a specific reason: the core is separate from this repository, and the core update document shows the team treats the boundary as real. If your needs are narrow, a thin Electron shell gives you fewer packages to build and no store distribution to negotiate.

What this repository gives you instead is the hard part: per platform packaging, store presence, automatic updates on Windows through the Microsoft Store, Flatpak and Arch packaging, a translation pipeline, theme support and an end to end test setup. None of that is interesting code, and all of it is most of the work.

The Tauri comparison is the more interesting one for anyone who cares about the memory and packaging footprint of an Electron app. The README links a fediverse thread and an nlnet project page for it, which suggests external interest. But it is in another repository, it is work in progress, and it tracks this one by submodule pin. Judging it from here is not possible, and treating this repository as the Tauri frontend is a mistake, because changes do not flow automatically.

Licence is GPL-3.0 for both this repository and the ecosystem around it. That is a licensing observation rather than advice, and it is the licence you would be shipping under if you fork the desktop client.

Release rhythm and what the version numbers tell you

The repository is not archived and the last push was on 2026-10-16, so this is active work with a recent commit on the default branch.

The release history shows three recent releases: v2.62.0 on 2026-09-26, v2.59.1 on 2026-08-23 and v2.59.0 on 2026-08-15. The jump from 2.59.1 to 2.62.0 is three minor versions in a month, which reads as a client that ships user visible changes often, consistent with a messenger chasing protocol and core changes.

The root package version 2.62.0 matches the newest tag, and there is an `update:target-versions` script that runs a script in bin/build to update the desktop version, which suggests the version is propagated into target packages rather than being hand edited.

What is not visible from the repository is how closely the desktop client tracks the core. The release documents are separate, core updates go through a different document, and the Tauri edition pins this repository rather than tracking its default branch. So for an adopter, the practical question is not which desktop version is newest but which desktop version bundles which core, and that mapping lives in the release notes rather than in the tag names.

Editorial conclusion

Adopt the Electron desktop build if you want the default, packaged application, and treat the browser edition as a developer tool rather than an alternative client, since the README describes it as highly experimental and only meant for developers and automated testing. Do not build from source expecting a system integration, because the README warns the source path does not install or integrate delta.chat into your system. Verify first which package you are editing, since the frontend lives in this monorepo while the Tauri shell lives in deltachat/deltachat-tauri against a pinned upstream submodule, so frontend changes reach that edition only after the pin moves.

Frequently asked questions

Official sources

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