Built for Linux from the first commit

Two audiences, one page

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 doesn’t 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 you chose this operating system and 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. Same care, observed from two ends.

What this page covers

In order: how the Linux build is built, the distros it’s 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’s still missing, what’s rough, and what the roadmap looks like.

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, 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 two accounts, $35 a year for unlimited after a 15-day trial that doesn’t ask for a card. Epistles is proprietary closed-source software; the security page documents the subprocessors we use and the trust-by-construction posture.

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 rather than a bundled copy of Chromium. No Electron, 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 can’t 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 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 Linux formats today, all signed and hosted by us at repo.epistles.com. APT, DNF/YUM, and Flatpak installs all update through 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.

iCloud Mail, Calendar, and Contacts work on Linux for the same reason every other provider does: a single app-specific-password wizard collects your Apple ID and an ASP from appleid.apple.com, then provisions IMAP for Mail and CalDAV/CardDAV for iCloud Calendar and Contacts in one step. Apple has no public OAuth program for iCloud data, and Sign in with Apple is identity-only; the ASP path is the only one third-party clients can use, and it works exactly the same on a Fedora box as on a Mac.

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’ve wanted on Linux in the last fifteen years. The pattern repeats: 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 elsewhere a year ago, packaged as a tarball with a README that apologises in the second paragraph. Sometimes it never arrives. Either way, the message a Linux user is 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 on the assumption that a Linux user will be grateful for whatever they get.

Epistles is not that, and the reason isn’t marketing, it’s architecture. There is one engine. The protocol adapters that talk to Gmail, Microsoft 365, Fastmail, iCloud, 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 aren’t the senior siblings; they’re peers. The Linux build doesn’t lag because there isn’t an upstream to lag behind: the work that lights up a feature on Mac is the work that lights it up here, in the same commit, on the same day. ProtonMail without a separate Bridge daemon lands first on this desktop because the adapter that makes it possible runs inside the client, and Linux gets the client.

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 will find these within an afternoon, so we’d rather list them ourselves and tell you where each one stands.

• Flathub is still pending. The Flatpak distribution is available today through our own GPG-signed OSTree repo at repo.epistles.com. We do want Epistles on Flathub; until that listing is ready, 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.

• 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 two 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, and Thunderbird is a genuinely good open-source Linux email client we recommend. Epistles is proprietary closed-source software; the subscription is what funds the work and the zero-telemetry posture.

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.

The same person who writes the code reads hello@epistles.com. We’d rather hear from you than not.