Pebble: a local-first desktop mail client in Rust and Tauri

Local first, and what that changes in practice

Pebble is described as a local-first desktop email client for people who want a calmer, more private inbox, and the design principles are listed plainly: your mailbox should stay readable, fast and quiet, email workflows should be local-first instead of cloud-dashboard-first, privacy controls should be explicit, visible and easy to override per message, and search, snooze, rules and a Kanban board should work together instead of living in separate tools.

The implementation is a desktop application built with Rust, Tauri and React, and it keeps mail data, the search index, attachments, rules and application settings on the device by default. The last point is the one that shapes everything else. Your messages are in a local database, the search index is local, and the network is used for synchronisation rather than for serving you your mail.

The account support is the practical constraint. Pebble currently supports Gmail, IMAP, POP3 and experimental Outlook accounts, so anything with a decent IMAP implementation is in scope, and the Microsoft path is explicitly labelled experimental.

The client is also honest about the mood it is going for. There is a command palette and keyboard-first navigation, a tray mode that keeps mail syncing while the window is hidden, and a Kanban board with Todo, Waiting and Done columns sitting next to the inbox, which is an unusual combination for a mail client and tells you what kind of workflow the author had in mind.

What stays on the device, and what still goes out

The local-first claims are concrete and worth checking one by one.

There is a local SQLite database for messages, folders, labels, rules and settings, and a local Tantivy full-text index for fast search, which is the search engine the Rust search crate ecosystem provides. Attachments are stored on disk under the app data directory. OAuth tokens and credentials are encrypted with a per-device key, and the Cargo manifest shows the crypto stack behind that, with aes-gcm for encryption, rand for key material, hex for encoding and the keyring crate with its apple-native, windows-native and linux-native-sync-persistent features for storing secrets in the system credential store.

There is no telemetry, and the network requests are limited to the features you configure: mail sync, translation, and optional WebDAV settings backup.

That last clause is the one to notice. The default is not zero network activity, it is bounded network activity, and the translation feature is the part most likely to surprise somebody who installed the client for its privacy. The WebDAV backup is explicitly optional.

One feature deserves a flag rather than a recommendation. There is an option to allow invalid TLS certificates for self-hosted mail servers. That is a genuinely useful switch for somebody running a private mail server with a self-signed certificate, and it is also a switch that removes the protection TLS provides against a machine in the middle. Anyone enabling it should know which of the two they are choosing.

The mail workflow features, and the productivity layer on top

The workflow list is long enough to be worth reading as a set of decisions rather than a list of checkboxes.

The core is a unified inbox across multiple accounts, threaded and message-list views, and the usual archive, delete, star, mark read, batch actions and restore flows. On top of that sit snooze, which brings a message back later, full-text search with advanced filters, and a rules engine for automatic organisation. Email CSS rendering with embedded style support is included, which matters for the newsletters and marketing mail that would otherwise arrive as a wall of text.

The productivity layer is where Pebble differs from a conventional client. There is a local address book with search, favourites, notes, multiple labelled email addresses and one-click contact actions taken from the participants of a message. Recipient autocomplete prioritises saved contacts and falls back to recent correspondents. vCard import and export move contacts between Pebble and other address books, and re-imports merge by normalised email, with existing non-empty local names and notes taking precedence over imported values, which is the behaviour you want and almost nobody gets right.

The Kanban board has Todo, Waiting and Done columns. The command palette and keyboard-first navigation are for people who never want to touch the mouse. Translation providers are built in, with bilingual reading and shortcuts, T to translate the selection and Ctrl+Shift+T to toggle the bilingual view. Dark and light themes come with wallpaper background support, and the interface is in English and Chinese.

Backup is a first class feature rather than an afterthought: local file export and import, and WebDAV backup for contacts, settings, rules, Kanban cards, Kanban notes and separately encrypted account secrets, with an automatic scheduled backup on a configurable interval.

The stack, and how it fits the desktop

The technology table is short and the choices are coherent. The desktop shell is Tauri 2, the backend is Rust, the frontend is React 19 with TypeScript, state is handled by Zustand and TanStack Query, the database is SQLite through rusqlite, search is Tantivy, styling is Tailwind CSS alongside app CSS, and localisation is i18next.

The Cargo workspace makes the backend structure explicit, with ten members. There is src-tauri for the Tauri application, and then a set of crates with clear responsibilities: pebble-core, pebble-store, pebble-privacy, pebble-mail, pebble-search, pebble-rules, pebble-translate, pebble-crypto and pebble-oauth. A mail client that splits its search, its rules, its crypto and its OAuth into separate crates is a client whose authors expect those parts to be independently testable, and it is why the repository has a tests/ directory and a vitest setup for the frontend side.

The release profile is tuned for a shipped desktop binary: opt-level set to s for size, link time optimisation on, a single codegen unit, symbols stripped and panic set to abort.

The platform integration list is short but specific. There are native macOS traffic-light window controls, registration as the default email client on Windows under Settings and General, a tray mode that keeps mail syncing while the window is hidden, an option to start hidden to the system tray, and a mailto: protocol handler so other applications can compose through it.

Installing, and the three ways to build it

There are three practical ways to get Pebble, and they suit different situations.

For most people, the prebuilt desktop packages are on the Releases page. On Arch Linux there is an AUR package, pebble-bin, installed with:

yay -S pebble-bin
# or
paru -S pebble-bin

For development, the prerequisites are Rust stable, Node.js 18 or newer, pnpm 8 or newer, and the Tauri system dependencies for your platform. The setup is:

git clone https://github.com/QingJ01/Pebble.git
cd Pebble

pnpm install
cp .env.example .env

pnpm dev

That last command starts the Vite frontend and the Tauri desktop app together, which is what you want for a project where the UI and the Rust backend talk constantly.

The build scripts are per platform:

pnpm build
pnpm build:windows
pnpm build:macos
pnpm build:linux

Desktop bundles are written under target/release/ and target/release/bundle/. On Linux the Tauri system dependencies have to be installed first, and pnpm build:linux produces AppImage, deb and rpm packages. The Windows target builds the nsis installer and the macOS target builds app and dmg bundles.

There is one macOS caveat that is worth reading twice, because it costs an afternoon if you hit it cold. macOS bundles are unsigned unless you provide your own signing setup, and after copying an unsigned macOS build to /Applications you need to clear the quarantine attribute before it will open:

sudo xattr -cr /Applications/Pebble.app

Where the profile lives, and how OAuth is configured

Two configuration questions come up before the app is useful, and the documentation answers both explicitly.

The first is where the data lives. By default Pebble stores the database, search index, attachments, logs, imported backgrounds and local interface preferences under the system app data directory. You can opt into a custom or portable profile directory before Pebble starts, in three ways. Set PEBBLE_PROFILE_DIR to an absolute path. Or put a pebble-profile.txt file next to pebble.exe, whose first line can be an absolute path or a path relative to the executable directory. Or create a pebble-profile directory next to pebble.exe to store the data beside the application.

Whichever you choose, the selected directory is used on the next app launch. That is a slightly awkward detail, since it means the location is decided at start-up and not at runtime, but it also means a portable installation on a USB drive is a supported arrangement rather than an accident.

The second is OAuth. Pebble can connect to Gmail and Outlook through OAuth, while IMAP accounts use the IMAP and SMTP credentials configured in the app. You copy .env.example to .env and fill in the provider values, and the table of variables is specific about which are optional. GOOGLE_CLIENT_ID is the Google OAuth client ID, with the advice to use a Desktop app client when possible, and GOOGLE_CLIENT_SECRET is optional for PKCE flows, to be added only if Google rejects the token exchange with client_secret is missing. MICROSOFT_CLIENT_ID is a Microsoft public or native app client ID, and MICROSOFT_CLIENT_SECRET is optional, to be left empty for public or native registrations, with Pebble using the PKCE public client flow.

That last point is worth noticing: for Microsoft, the documented default is a public client with no secret at all.

Where Pebble is the wrong tool

Four limits are clear, and the first one is the price of the local-first design.

If your mail workflow depends on server side search, on seeing the same mailbox on your phone and your laptop, or on a provider side thread that is always up to date, a local-first client gives you none of that. Pebble's search is a local Tantivy index, which is fast and private and searches what has been synchronised to the machine.

The second is account coverage. Gmail, IMAP, POP3 and experimental Outlook is a good range, but the Microsoft path is labelled experimental, and a hosted suite with a proprietary protocol rather than IMAP is out of scope.

The third is the overlap with other tools. A rules engine, a snooze feature and a Kanban board inside a mail client is a coherent product, and it is also a second task manager next to whatever you already use, with its own state that has to be backed up separately. The WebDAV backup covers Kanban cards and notes, which is a good sign, but the data still lives in one application rather than in a shared task system.

The fourth is the licence and the maturity. The project is under the AGPL-3.0, which for a desktop application is a common choice and a real consideration if you intend to modify and distribute a fork. The version is 0.1.5, with 0.1.4 and 0.1.3 before it, so the feature list is moving quickly and some of it will change.

The alternative approach is a webmail client, and the difference in approach is exactly the point: a webmail client keeps the mailbox on the provider's servers, which gives you server side search and the same inbox everywhere, and takes away the local database, the local index and the ability to keep credentials on a device you control. Pebble trades that away deliberately, and the question for a reader is which of the two you actually want.

Editorial conclusion

Adopt Pebble if you want your mail, its search index and its credentials stored on your own machine, and you want rules, snooze and a task board next to the inbox. Do not adopt it if you need server side search across devices, if you rely on an Exchange or hosted suite beyond the experimental Outlook path, or if you need a signed macOS build without doing the notarisation work yourself. Verify first that the profile directory and backup location you choose are backed up, that the OAuth client you register matches the PKCE flow Pebble expects, and that the release you install is recent enough for the account provider you use.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. QingJ01/Pebble on GitHub
4. README
5. Releases