Bichon: a self-hosted Rust mail archiver with an embedded search stack

The gap Bichon fills: IMAP mail that outlives the mailbox

Mailbox quotas expire, providers shut down, and accounts get deprovisioned. Bichon exists to pull messages out of IMAP accounts and keep them locally where they can still be searched years later. The README is explicit that this is an archiver, not a client: it does not send, compose, forward, or reply, and the optional SMTP server is for receiving only. That single sentence removes a whole category of expectations. If you want a mail client, this is the wrong project. If you want a searchable, deduplicated store of everything your accounts ever received, the scope is right. The intended user is someone running their own infrastructure: a homelab operator with several personal accounts, or a small team that wants a shared archive without handing the data to a third party. The multi-account model, account-level isolation, and five built-in RBAC roles all point at the small-team case rather than a single-user toy.

Ingestion: concurrent IMAP download, UID deltas, and UIDVALIDITY recovery

The download path is the part of Bichon worth understanding before you trust it with years of mail. Accounts are downloaded concurrently. Authentication covers password schemes (PLAIN and LOGIN) and OAuth 2.0 via SASL XOAUTH2, with automatic token refresh and PKCE, over SSL/TLS, STARTTLS, or plain connections, and self-signed certificates can be accepted. After the first full pull, the archiver switches to UID-based delta fetching, so subsequent runs only request messages with UIDs above the last seen value. The README states that UIDVALIDITY changes are detected and trigger automatic cache rebuilds. That is the correct behaviour, and it is also the cost: when a server renumbers a mailbox, you pay for a rebuild. Fetch scoping lets you bound the damage, by date range, by a mailbox folder limit, or by naming specific folders, and each account can be routed through its own SOCKS5 proxy. Scheduled downloads use cron expressions per account, so nightly-only or business-hours-only archiving is a configuration choice rather than a script you maintain.

Storage: Tantivy, bichon-blob, and memdb in one process

Bichon calls its storage model three-layer, and the layers are all embedded, which the README frames as zero external dependencies. Tantivy holds the full-text index and applies Zstd compression. A component named bichon-blob stores compressed blobs, also with Zstd. A component named memdb holds relational metadata. Nothing here needs Postgres, Elasticsearch, or an object store, which is the main reason a single container can run the whole thing. Deduplication sits on top: identical bodies and attachments are stored once, keyed by BLAKE3 content hashing, and moving a message between folders updates metadata only rather than rewriting the blob. Search covers subject, body, sender, recipients, and attachment properties, with filters for date range, size range, attachment presence, file type, content category, and tag combinations. The README states the full-text search is optimized for European languages, which is a scoping admission worth reading literally if your archive is mostly CJK. Thread grouping reconstructs conversations across folders, and the contacts view deduplicates sender and recipient addresses across all authorized accounts.

Getting it running: Docker first, then the config keys that matter

The README recommends Docker and lists Docker Compose, a binary installation, and a build from source as the other routes. The image is published at rustmailer/bichon on Docker Hub, so the pull is docker pull rustmailer/bichon. Configuration is documented as a reference with named groups: required settings, server and networking, logging, CORS, TLS and HTTPS, SMTP server, storage paths, and performance tuning. The storage paths group is the one to read before your first sync, because that is where the blob directory and the Tantivy index live and where you decide whether they sit on a volume with room to grow. TLS and HTTPS are configured separately from the SMTP server's own STARTTLS or TLS settings, so an HTTPS deployment and an SMTP receiver are two distinct configuration tasks. CORS is its own group, which matters if you plan to call the REST API from a browser application on another origin. The README also documents CLI tools, and the import paths are concrete: EML directories, MBOX files including Gmail variants, Thunderbird profiles, and Outlook PST files through the CLI, with EML import also available from the WebUI. Export is MBOX via bichon-cli. Admin password reset is listed as a tool for locked-out admins, and migration from v0.3.7 and v1.x to v2.x is described as non-destructive. The API is documented as OpenAPI 3.0 with interactive docs at /api-docs, rendered through Swagger UI, ReDoc, and Scalar.

Where Bichon stops: no sending, single-node storage, European-language search

Three limits are visible in the material and each rules out a real deployment. First, no outbound mail. The README says it plainly, so any workflow that expects to reply from the archive is out. Second, the storage stack is embedded and local. Tantivy, bichon-blob, and memdb run inside the process, which is what makes installation simple and also what makes horizontal scaling a question the README does not answer. If your archive will not fit on one machine's disk, or if you need the index replicated across nodes, this architecture has no documented answer. Third, full-text search is described as optimized for European languages. An archive dominated by other scripts should be tested before you rely on it. There is also a rebuild cost hiding in the incremental design: UIDVALIDITY changes trigger automatic cache rebuilds, and on a large mailbox that is a real event, not a background detail. And the SMTP server, while useful for receiving at the gateway, is authenticated with API tokens over AUTH PLAIN or LOGIN, so it belongs behind TLS and a network boundary you control.

How it differs from running Dovecot plus a search engine

The obvious alternative for a self-hoster is a conventional stack: Dovecot or another IMAP server holding mail on disk, plus a separate indexer such as Notmuch or a search engine pointed at the maildir. That approach keeps your messages in a standard on-disk format that any IMAP client can read, which is a genuine advantage for portability. Bichon inverts the arrangement. It is not an IMAP server you point clients at; it is an archiver that consumes IMAP and exposes the result over HTTP. The metadata lives in memdb, the blobs in bichon-blob, and the index in Tantivy, so the archive is queried through the REST API, the WebUI, or the bichon-cli export to MBOX rather than through a mail client. You gain cross-account search, faceted tags, thread reconstruction, attachment filtering, and dashboard analytics in one process with no external services. You give up the ability to mount the archive as a mailbox. The deduplication behaviour is the clearest expression of the trade: storing identical bodies and attachments once is only possible because Bichon owns the storage format, and that same ownership is why MBOX export exists as an escape hatch.

Maintenance, migration, and the AGPL question

Bichon is licensed AGPL-3.0. If you run it for yourself or inside your own organization, the practical effect is that you can use it and modify it, and if you distribute modified versions or offer it to users over a network, the licence's source-availability obligations come into play. That last clause is the one to think about before embedding Bichon in a product you host for customers. This is not legal advice; read the licence text and get your own counsel if the network clause affects your business model. On maintenance, the release cadence visible in the material is steady: 2.0.1 on 2026-08-09, 2.0.2 on 2026-08-19, and 2.0.3 on 2026-09-05, with the repository's last push on 2026-09-10. Frequent patch releases during a major version mean you should plan to track them rather than pin and forget. The migration notes cover v0.3.7 and v1.x to v2.x and describe the process as non-destructive, but the README also carries a separate data migration section for v0.x to v1.0, which tells you that jumping across major versions has historically required attention. Upgrading inside 2.x looks routine; crossing a major boundary deserves a backup of the storage paths first.

Editorial conclusion

Adopt Bichon if you want a single self-hosted box that ingests IMAP accounts, deduplicates bodies and attachments by BLAKE3 hash, and answers cross-account queries through the REST API or WebUI. Do not adopt it if you need to send mail, if your archive must span multiple machines, or if AGPL-3.0 obligations conflict with how you redistribute your own product. Before committing, verify one thing on your own mail: run a first sync against a small account, confirm the UID delta works, then check the storage paths section of the README against the actual size of the blob and Tantivy index directories on disk.

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. rustmailer/bichon on GitHub