How the MailGen services fit together
MailGen runs several services behind HTTPS addresses. This page explains their responsibilities. For commands, use first installation or daily operations.
Browser and application services
The BFF, or backend for frontend, serves the browser workspace and handles its server requests. The Account service handles application login and the shared session. These services use different public addresses in the unified deployment.
Backend workers process mailbox commands, synchronize provider data, publish status, and handle administrative operations. The .NET onboarding service creates initial mailbox data. DataSearcher handles background search work.
Microsoft access uses tenant-wide application credentials. It is separate from browser login. See Microsoft Graph setup. Google mailbox access uses the separate OAuth or Workspace setup described in Google Cloud setup.
Persistent data and background work
| Component | Responsibility |
|---|---|
| PostgreSQL | Application records, authorization, mailbox projections, and durable processing state |
| SeaweedFS/S3 | Message bodies, attachments, and imported files |
| Kafka | Background commands and events, with mailbox partition assignments and consumer offsets |
| OpenSearch | Search indexes |
| Dragonfly | Redis-compatible cache and temporary coordination |
| Qdrant | Vectors for knowledge retrieval |
| ClamAV | File scanning |
| Tika / knowledge-extractor | Document text extraction |
| Collabora | Office attachment previews |
A projection is a local representation of provider data. Provider notifications trigger synchronization. For Microsoft, delta reads determine the synchronized state. An accepted command and a confirmed provider write are distinct states. See key concepts.
Deployment and execution are separate choices
Docker Compose isolates each clone's application networks and volumes. A shared Nginx Proxy Manager routes HTTPS requests to the appropriate instance. Shared CPU and RAM still limit how many stacks the machine can run.
fulllocal keeps selected infrastructure local. Real partialRemote moves only Kafka, ClamAV, Collabora, Tika, and Qdrant connections to prepared remote services. PostgreSQL, S3, OpenSearch, Dragonfly, application services, and keys stay local. The selector does not copy data. See partial remote deployment.
Development execution watches source files. Production execution uses compiled output. Placement does not choose execution mode. The runtime can retain different execution modes for individual services.
Documentation is a separate surface
The documentation service publishes these pages. A standalone static image needs a rebuild for content changes. The unified development documentation uses its own service lifecycle. Neither address is a mailbox login. See standalone documentation.