Velo: a local-first desktop mail client where the AI features are optional

Mail in a local SQLite database, not on a vendor's server

The positioning is stated as a contrast with other clients. Most email clients are slow, bloated, or send your data to someone else's server, and Velo's answer is a local-first design where your emails live in a local SQLite database with no middleman servers, so you can read your mail offline. The tech stack table makes the shape concrete: Tauri v2 with Rust for the backend, React 19 with TypeScript for the interface, Tailwind CSS v4 for styling, Zustand 5 with eight stores for state, and SQLite with FTS5 across 33 tables for the database. The full-text search index is the reason for the table count, and it is also what makes the Gmail-style search operators possible, including from:, to:, subject:, has:attachment and label:. The email side uses the Gmail API for Google accounts and IMAP and SMTP handled in Rust through async-imap and lettre. So there is no web tier and no account with the vendor. The trade is that a desktop client cannot have the shared-state properties of a hosted service, and the README does not describe shared mailboxes, delegation or server-side retention.

Getting it installed and connecting a first account

There is no build step for ordinary users. The README says to download the latest release for your platform, with Windows .msi and .exe, macOS .dmg and Linux .deb and .AppImage, and that no build tools or programming knowledge are required. The account setup splits by provider. For Gmail you create OAuth credentials in the Google Cloud Console, enabling the Gmail API and the Calendar API, then enter the client ID in Velo's settings, with no client secret needed because it uses PKCE. For IMAP and SMTP you click Add IMAP Account in the account switcher, enter the email and password, and Velo auto-discovers server settings for popular providers such as Outlook, Yahoo, iCloud and Fastmail, while other providers need the server details typed in manually and need no Google Cloud project at all. AI is optional and handled the same way, with an API key for Anthropic, OpenAI or Google Gemini added in Settings, followed by a choice of which model each provider should use. The ordering matters if you are auditing your own setup: the account comes first, and the AI key is something you can leave unset.

Reading and composing are the parts with the most surface area

The feature list is long, and the parts that shape daily use are specific rather than generic. Multi-account support covers Gmail and IMAP with instant switching, conversations are threaded with collapsible messages, and the split inbox uses category tabs for Primary, Updates, Promotions, Social and Newsletters. There is a command palette opened with / or Ctrl+K, drag-and-drop labels, multi-select, pinned and muted threads, inline reply and a contact sidebar with Gravatar. The composer uses TipTap v3 for rich text with bold, italic, lists, code, links and images, and adds undo send, schedule send, auto-saved drafts, multiple signatures, reusable templates with variables, send-as aliases with a from-address selector, drag-and-drop attachments with inline preview and frequency-ranked contact autocomplete. The Smart Inbox layer adds snoozing, filters that auto-label or archive, rule-based and AI categorization, one-click unsubscribe over RFC 8058, a subscription manager, newsletter bundling with delivery schedules, smart folders built on dynamic query tokens, quick steps for batch actions and follow-up reminders when a reply does not arrive. The scale of that is the honest point: this is a client with a large surface, and every element is a behaviour you will either rely on or ignore.

Three AI providers, cached locally

The AI section is the one that needs a careful reading. Three providers with selectable models are offered, and you can choose one or mix and match them. Anthropic Claude lists Haiku 4.5, Sonnet 4 and Opus 4, OpenAI lists GPT-4o Mini, GPT-4o, GPT-4.1 Nano, GPT-4.1 Mini and GPT-4.1, and Google Gemini lists 2.5 Flash and 2.5 Pro. The features built on top are thread summaries, smart reply suggestions, AI compose and reply, text transform for improving, shortening or formalising a draft, and Ask My Inbox for natural language search. Which model each provider uses is picked in Settings, and all results are cached locally. The design point is that the AI is a client-side feature that talks to a provider you chose, not a feature of a Velo-operated service, which is consistent with the local-first framing and also means the data leaves your machine when you use it. The README does not describe a proxy or a bring-your-own-endpoint option, so if you intend to route model traffic through your own infrastructure, that is a question for the project rather than a documented setting.

The privacy story depends on the rendering pipeline

The privacy and security section lists what the client does, and the detail is worth reading rather than the headline. Remote images are blocked with a per-sender allowlist, HTML is sanitized, and emails are rendered in sandboxed iframes, with DOMPurify named in the dependency list. Phishing link detection uses ten heuristic scoring rules, and SPF, DKIM and DMARC results are shown with badges and warnings, which is genuinely useful because it lets you see why a message was flagged before you click. Credentials are handled differently by account type: Gmail uses OAuth PKCE with no client secret and no backend servers, IMAP account passwords and app passwords are stored encrypted with AES-256-GCM, and tokens are stored with the same cipher. The nuance is that remote image blocking is a default with an allowlist rather than an absolute, and sanitized HTML in a sandboxed iframe is a mitigation, not a guarantee. Treating rendered email as hostile input is the right model for a client that renders arbitrary HTML from strangers.

Building from source and what the repository holds

Contributors clone, install and run the dev server with Tauri:

git clone https://github.com/avihaymenahem/velo.git
cd velo
npm install
npm run tauri dev

The prerequisites are Node.js v18 or later, Rust, and the Tauri v2 dependencies, and the Development Guide in docs/ covers the rest of the commands, testing and builds. A release build is a single script, npm run tauri build, producing the same per-platform artifacts as the downloads. The repository layout shows the split between src for the React and TypeScript front end and src-tauri for the Rust side, alongside a landing directory for the marketing site, and the project also ships Flatpak packaging through com.velomail.app.yml with a flatpak-builder script in package.json. The desktop entry point is com.velomail.app.desktop with a metainfo file for the software catalogue. Tests are Vitest with Testing Library, and the manifest carries a test script that runs vitest run. There is also a CLAUDE.md and a .claude directory at the root, so the project has taken to keeping machine-readable contributor instructions alongside the human-facing CONTRIBUTING.md.

Where the project stands and what it costs to follow

The release history is dense and recent. The three newest tags are velo-v0.4.21 on 2026-02-27, velo-v0.4.20 on 2026-02-26 and velo-v0.4.19 on 2026-02-25, three releases in three days, and the last push to the repository was on 2026-06-02. The version in the package manifest matches the newest tag, 0.4.21, and the release workflow appears to be release-please driven, with .release-please-manifest.json and release-please-config.json at the root alongside a CHANGELOG.md. That combination suggests a project with a working automated release process and a long tail of patch releases rather than major versions, which is healthy for a desktop app but means the version number carries little API promise. The licence is Apache-2.0, which is permissive for a client you install on your own machine and also permissive for anyone who wants to read the code and build a variant. The product is young, the release cadence is high, and the maintenance state is best read from the last push on 2026-06-02 rather than from the tag names.

Editorial conclusion

Velo suits someone who wants a fast keyboard-driven mail client, wants their messages in a local database they can query offline, and would rather choose an AI provider than be handed one. It is the wrong tool for a team that requires a managed mail server with shared mailboxes, retention policy and audit trails, since Velo is a single-user desktop application with no mention of shared accounts, and it is the wrong tool if you need a rich HTML message editor comparable to a browser-based mail client. Verify first that your provider is reachable through the route Velo supports, since Gmail needs a Google Cloud OAuth client ID and everything else goes over IMAP and SMTP, and confirm that the AI features are off if you want the privacy claim to be about the network rather than about the rendering pipeline.

Frequently asked questions

Official sources

1. avihaymenahem/velo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases