Built for Linux. On purpose. From the first commit.

Whatever brought you here, welcome.

Some of you have run Linux on the desktop since the 1990s, compiled your first kernel before Y2K, and have opinions about init systems that would fill a small book. Some of you installed Fedora last weekend, are still figuring out which terminal you like, and want a daily driver that works without a thread on a forum. Both of you are reading the same page on purpose.

Epistles does not ask which camp you belong to. It does not assume you live in GNOME or KDE, that you prefer Wayland over X11, that you use Flatpak or distrust it, that your shell is bash or fish or something you wrote yourself. It assumes that you chose this operating system, and that you would like an email client that respects that choice instead of treating it as a porting tax. The veteran will recognise the care in the system integration. The newcomer will notice that nothing feels foreign. That is the same care, observed from two ends.

What this page is going to tell you.

Below, in order: how the Linux build is actually built, the distros it has been tested on, how it fits with self-hosted infrastructure (Nextcloud, Radicale, your own IMAP server), and how to install it. After that, an honest account of what is still missing, what is rough, and what the roadmap looks like, because a Linux audience deserves a vendor that names its gaps instead of papering over them.

The short version, for the impatient: a Tauri 2 binary, installable via APT, DNF/YUM, or Flatpak from our repo at repo.epistles.com, system WebKitGTK rather than a bundled Chromium, OAuth in your real system browser, IMAP and SMTP over a Rust TCP transport, ProtonMail without Bridge, mail and calendar and contacts in one window, every account’s mail on your own disk in a local SQLite store, zero analytics, zero crash telemetry. Free for three accounts, $35 a year for unlimited after a 15-day trial that does not ask for a card. Source migration to a public repository at github.com/epistlesapp/epistles is in progress.

How it’s built

Epistles for Linux is a Tauri 2 application. The runtime is Rust and a small Tauri shell; the rendered interface runs inside the distribution’s own WebKitGTK, the system WebView, rather than a bundled copy of Chromium. There is no Electron and no embedded browser. A typical install is a few megabytes of Rust and a few megabytes of compiled JavaScript, not a hundred and fifty megabytes of duplicated Chromium per app.

OAuth opens in your real browser. When you connect a Gmail or Microsoft 365 mailbox, the consent screen is the one Google or Microsoft serves to Firefox or Chromium directly, with your existing session, your password manager, your hardware key, your work-account policies. Epistles never sees the credential. The flow is implemented in apps/linux/src/lib/oauthBrowser.ts; the redirect is captured by a deep-link handler the Tauri side registers with xdg-mime at install time.

IMAP and SMTP run over a hand-rolled Rust TCP transport in apps/linux/src-tauri/src/tcp.rs. tokio for the socket loop, tokio-rustls for TLS (both implicit on 993 and 465 and STARTTLS upgrades on 143 and 587), and Mozilla’s root bundle via webpki-roots so the trust anchor is consistent across distros rather than whatever lives in /etc/ssl/certs. Secrets are kept by the Secret Service over D-Bus through the keyring crate, which means GNOME Keyring on most desktops and KWallet on KDE, with no plaintext on disk.

The OWA push channel for Microsoft 365 cannot be reached directly from a WebView for cross-origin reasons, so the desktop app proxies through api.epistles.net/api/owa/proxy, the same backend route the web build will use, and re-frames the SignalR stream client-side. This is the kind of detail that decides whether push works or doesn’t on day one.

Runtime.

Tauri 2 + Rust + WebKitGTK 4.1 (the system WebView). No Electron, no bundled Chromium.

OAuth.

Opens your real system browser via xdg-open. Deep-link callback handled by the Tauri shell.

IMAP / SMTP.

tokio + tokio-rustls raw TCP, written in Rust, exposed to the JS side as Tauri commands.

Secret storage.

Secret Service over D-Bus (libsecret): GNOME Keyring or KWallet, whichever your desktop supplies.

Notifications.

D-Bus to org.freedesktop.Notifications, with AppIndicator tray support where the desktop offers it.

Local cache.

SQLite on disk. Encryption at rest is your distribution’s job: luks, fscrypt, or whatever you already use.

A small example of how close to the platform we sit: WebKitGTK 2.52 has a quirk where an empty <style> tag returns a null .sheet handle, which breaks React Native’s stylesheet bridge on first paint. The fix is one pre-populated rule in apps/linux/index.html. It is not the kind of bug you notice on a Mac. We noticed.

Distribution and distros

Epistles ships in three formats, all signed, all hosted by us at repo.epistles.com. There is no Snap Store, no Flathub, no Mac App Store equivalent in the loop. The repo speaks the package manager you already use.

APT for Debian-family distros (Ubuntu 24.04 LTS or newer, Debian, Pop!_OS, Linux Mint, elementary). Add deb https://repo.epistles.com/apt stable main to your sources, install the signing key, and apt install epistles does the rest. Both amd64 and arm64 are published, so Asahi Linux on Apple Silicon, a Raspberry Pi 5, or an ARM Chromebook all run native. Auto-updates flow through apt alongside everything else on the system.

YUM / DNF for Fedora, RHEL, Rocky, AlmaLinux, openSUSE (with zypper), and the rest of the RPM-based world. Drop our .repo file in /etc/yum.repos.d/, accept the GPG key, and dnf install epistles takes it from there. Same dual-architecture story (x86_64 and aarch64).

Flatpak for everything else: Arch, EndeavourOS, Manjaro, NixOS, Void, Gentoo, Steam Deck, Bazzite, and any modern distro where you'd rather use the universal package manager. We host the OSTree repo ourselves at repo.epistles.com, GPG-signed, both architectures from the same source. Auto-updates through your normal Flatpak frontend (GNOME Software, KDE Discover, flatpak update).

Tested on Fedora 43 and Ubuntu 24.04 LTS as the floor. Reported to work on Pop!_OS, Mint, Manjaro, Nobara, EndeavourOS, openSUSE Tumbleweed, Bazzite. AppImage was on the early roadmap; we shelved it because Flatpak does the same job better (auto-updates, sandboxing, portal-aware install) without the per-distro library matrix. Snap is not on the roadmap.

For the self-hoster

If you run your own infrastructure, Epistles is built to talk to it directly. IMAP and SMTP connect to Dovecot, Postfix, Stalwart, Mailcow, Mailu, Mox, Cyrus, and any other standards-compliant server, with full STARTTLS and implicit-TLS support and certificate validation against the Mozilla root bundle. CalDAV and CardDAV connect to Nextcloud, Radicale, Baikal, Sabre, SOGo, and the calendaring side of Stalwart. JMAP works with Stalwart and any other server that implements the spec, not just Fastmail.

None of those connections route through our infrastructure. Your Nextcloud talks to your client over your network. We do not see the address, the credentials, or the traffic.

The Cloud Vault that syncs credentials between your devices is opt-in. If you would rather keep everything on the machine you installed Epistles on, leave it off, and your account credentials never leave the local Secret Service keyring. Push notifications likewise are an opt-in path; the relay receives a hint that mail arrived, never the mail itself, and it can be turned off in full if you would rather have your client poll on your schedule.

ProtonMail works without Proton Bridge. The adapter speaks Proton’s API directly and runs OpenPGP in process, so there is no second daemon to install, no localhost:1143 proxy, no separate update cycle. On a Linux desktop where Bridge is a chore to keep running, that matters.

Install

Use the package manager that your distro uses. Each path adds the Epistles repo once, imports our GPG key once, and from then on apt, dnf, or your Flatpak frontend handles updates the same way it does for everything else on your system.

APT (Debian, Ubuntu 24.04+, Pop!_OS, Mint, elementary)

$ sudo install -d -m 0755 /etc/apt/keyrings
$ curl -fsSL https://repo.epistles.com/epistles.asc \
    | sudo tee /etc/apt/keyrings/epistles.asc > /dev/null
$ echo "deb [signed-by=/etc/apt/keyrings/epistles.asc] https://repo.epistles.com/apt stable main" \
    | sudo tee /etc/apt/sources.list.d/epistles.list > /dev/null
$ sudo apt update
$ sudo apt install epistles

DNF / YUM (Fedora, RHEL, Rocky, AlmaLinux)

$ sudo dnf config-manager addrepo \
    --from-repofile=https://repo.epistles.com/yum/epistles.repo
$ sudo dnf install epistles

On older dnf versions (Fedora 40 and earlier, RHEL 9):

$ sudo curl -fsSLo /etc/yum.repos.d/epistles.repo \
    https://repo.epistles.com/yum/epistles.repo
$ sudo dnf install epistles

Flatpak (Arch, NixOS, Steam Deck, Bazzite, anywhere else)

$ flatpak install --from https://repo.epistles.com/flatpak/epistles.flatpakrepo
$ flatpak run com.epistles

The signing key

The same GPG key signs all three repos. The APT and DNF paths above install it for you; if you want to inspect it directly:

$ curl -fsSL https://repo.epistles.com/epistles.asc | gpg --show-keys

The Flatpak repo’s signature is verified automatically by the Flatpak client when you add it via the .flatpakrepo file; no extra step.

You are not in the trunk anymore.

Pick a productivity app you have wanted on Linux in the last fifteen years. The pattern is the same one almost every time. A polished Mac release. An iOS release. A Windows release a quarter later. Then, eventually, a forum post: Linux build coming soon. Sometimes it arrives, two versions behind, missing features that shipped on every other platform a year ago, packaged as a tarball with a README that apologises in the second paragraph. Sometimes it never arrives at all. Either way, the message a Linux user has been asked to internalise is the same: your desktop is the afterthought, the side project, the thing that gets the leftover budget after the “real” platforms ship.

Email has been one of the worst categories for this. The good clients skip Linux entirely. The clients that do show up are old, half-maintained, or wrappers around someone else’s engine with a Linux skin glued on at the end. Whole product categories have been built around the assumption that a Linux user will be grateful for whatever they get.

Epistles is not that, and the reason isn’t marketing. It is the architecture. There is one engine. The protocol adapters that talk to Gmail, Microsoft 365, Fastmail, ProtonMail, and any IMAP host live in a shared core that every platform imports. The keyboard model is the same model. The local SQLite store is the same store. The Cloud Vault is the same vault. Mac, iOS, and Android are not the senior siblings; they are peers. The Linux build doesn’t lag because there is no upstream to lag behind, the work that lights up a feature on Mac is the same work that lights it up here, in the same commit, on the same day. ProtonMail without a separate Bridge daemon is a Linux example that lands first on this desktop because the adapter that makes it possible runs in the client itself, and Linux gets the client itself.

Sit in the driver’s seat and the view is fine. The keyboard is where you expect it. The window obeys your tiling manager. Your mail is on your disk. The thing you chose this operating system for, the feeling of running software that respects the machine and the person using it, is the feeling we wanted this client to have.

What isn’t there yet.

A pitch that doesn’t name its gaps insults the audience. The Linux community in particular will find these on its own within an afternoon, so we’d rather list them ourselves and tell you where each one stands.

• No Flathub listing. The Flatpak distribution is self-hosted at repo.epistles.com with our own GPG-signed OSTree repo. A Flathub listing is on the list, behind the source-code migration below; until then, the one-line .flatpakrepo install is how you add us.

• No Snap, and probably not soon. Snap is divisive for reasons that don’t need rehearsing here, and the confinement model interacts poorly with the OS keychain access the vault relies on. If there is real demand we will revisit; we are not going to ship a half-broken Snap to tick a box.

• GNOME tray needs the AppIndicator extension. The tray indicator works on KDE and most other desktops out of the box. On a current GNOME session you’ll need gnome-shell-extension-appindicator installed for the tray icon to appear. The app remains fully functional through its main window without it; this is a GNOME platform decision, not a missing piece in our build.

• Cross-application drag-drop is broken from the file manager. Dragging an attachment in from Files / Nautilus / Dolphin into a compose window is currently unreliable, due to upstream issues in wry / tao (the Tauri webview crates). HTML5 in-page drag-drop still works. We track the upstream tickets and will pick up the fix when it lands.

• Ubuntu 22.04 and Debian 12 are not officially supported via .deb. The binary is built against glibc 2.39 (the Ubuntu 24.04 floor). On older Debian-family distros, install via Flatpak instead, the runtime supplies its own glibc independent of the host.

• No DBus surface for third-party scripting. We respond to the system’s DBus signals where it matters (notification clicks, session lock), but Epistles does not currently publish its own DBus interface that you can drive from a script or a hotkey daemon. We’ll publish one when we know what shape the public surface should take, rather than freezing a private one by accident.

• Wayland under WebKitGTK has rough edges. Fractional scaling at non-integer factors and IME composition for some input methods are the two we’ve seen most. The build runs on both Wayland and X11, and on a current GNOME or KDE Wayland session it’s smooth in the cases we test. If you hit something specific, send a diagnostic bundle and we’ll look.

• System theme tracking is partial. Light and dark follow the desktop preference. The accent colour from your GTK theme, and the full set of KDE colour-scheme tokens, are not plumbed through yet. We use a single typographic palette across platforms by design, so this won’t become a recolour-everything feature, but the dark/light mismatch on first launch is on the fix list.

• The source repository isn’t public yet. It will live at github.com/epistlesapp/epistles; the project was built from the first commit with that move in mind, and the migration from the private working tree is in progress. We will publish a note here when it’s done so you can read the parts that back the claims on this page.

• Snooze, send-later, and the combined-list unified inbox ship later in 2026. Multi-account works today, one client, one keyboard, one set of shortcuts across every account. The single chronological combined view, and the relay-backed deferred-action features, are the next milestone.

• This is a paid product with a free tier, and we’re not going to dance around it. Free covers up to three connected accounts. Pro is $35 a year, with a 15-day trial that doesn’t ask for a card. We know some of you would rather run something fully free as in beer and as in freedom; we respect that. The subscription is what funds the work, the zero-telemetry posture, and the open-source migration. When the repo lands you’ll be able to read every line of it, build it yourself, and decide what that’s worth to you.

That is the full list of the gaps we know about. The sections above are what is already in the build today, and what works the way the page describes.

Where to start.

Two paths from here. Install today: the APT, DNF, and Flatpak instructions are above, and on a recent Debian, Ubuntu, Fedora, Arch, or openSUSE box you should be reading mail in a couple of minutes. Or read first: the security page walks the encryption and storage claims with code references, and the developers page covers the multi-account day in more detail.

Whatever you choose, the same person reads [email protected] that writes the code. We’d rather hear from you than not.