Architecture

Where your data lives

Fluxmail keeps its SQLite database on the machine where it runs. OAuth tokens are encrypted at rest with AES-256-GCM. Your agent talks to Gmail through your self-hosted Fluxmail process; your emails are never stored on a Fluxmail server or transmitted outside your network, and the code is source-available if you want to audit it.

How Fluxmail is built

Fluxmail is a small monorepo:

packages/
  core/             # unified types, the EmailQuery language, the EmailProvider interface
  provider-gmail/   # Gmail adapter (googleapis): query translation, MIME, threading, labels
  server/           # EmailService, SQLite storage, OAuth, MCP tools, HTTP + stdio transports, CLI

MCP tools are thin wrappers over EmailService, which owns account routing, reply and forward computation, and plan limits. Each provider implements one EmailProvider interface and declares a capabilities object, so the tools degrade cleanly where providers differ (IMAP has no labels, for example). Outlook (Microsoft Graph) and IMAP adapters are in progress, and because everything above the provider layer is provider-agnostic, your agent keeps calling the same tools as they land.