Bichon: a self-hosted IMAP email archiver in Rust with full-text search and a REST API

What Bichon solves, and who it is for

Mailboxes are a poor archive. Messages live in accounts you may lose access to, search is limited to whatever the provider indexes, and moving a folder between accounts rewrites data rather than metadata. Bichon is built for the other side of that problem: pulling mail out of IMAP accounts into storage you control, indexing it, and exposing it to programs.

The README is explicit about the boundary. Bichon is an archiver, not an email client: it does not send, compose, forward or reply. The optional SMTP server exists to receive mail only. That single sentence rules out a large class of users. If you are looking for a webmail replacement, this is the wrong project. If you are looking for a long-term store of several accounts with cross-account search and an HTTP interface, the feature list lines up: multi-account concurrent download, incremental UID-based fetching, thread grouping, attachment search, faceted tags and a contacts view across authorized accounts.

Three-layer storage and how the data flows

The architecture is embedded. There is no Elasticsearch, no Postgres and no external object store to operate. The README describes three layers: Tantivy for full-text indexing with Zstd compression, bichon-blob with Zstd for compressed blob storage, and memdb for relational metadata. The workspace in Cargo.toml matches that description, with crates/memdb, crates/blob, crates/server, crates/cli, crates/admin and crates/smtp as members.

The flow is one-directional. Credentials and fetch scope are configured per account. Bichon connects over IMAP, downloads messages, and writes them through the storage layers. Deduplication happens at write time using BLAKE3 content hashing, so identical bodies and attachments are stored once; moving a message between folders updates metadata rather than copying the blob. Incremental download is UID-based, and the README states that UIDVALIDITY changes are detected and trigger automatic cache rebuilds. That last detail matters more than it looks: UIDVALIDITY is the IMAP signal that a mailbox's identifiers have been reset, and a wrong answer there produces either duplicates or silent gaps.

The search layer is Tantivy, and the README says it is optimized for European languages. That is a scoping statement, not a bug, but it is worth reading literally before you point Bichon at a corpus in another script.

Installing Bichon with Docker and running a first sync

Docker is the recommended path in the README. The image is published as rustmailer/bichon on Docker Hub. The repository also carries a docker/ directory and a config.toml at the top level, and the README documents a Configuration Reference with required settings, server and networking, logging, CORS, TLS, SMTP, storage paths and performance tuning.

The README gives the Docker invocation in the Quick Start section. The exact flags are not reproduced here, so read that section directly; what matters is that the configuration is supplied to the container and that storage paths are mapped to a host volume you control.

Once the server is up, the API is documented in OpenAPI 3.0 at /api-docs, with Swagger UI, ReDoc and Scalar renderers. That is the fastest way to confirm the server is healthy before touching the WebUI.

docker pull rustmailer/bichon

Pinning the tag matters. The recent releases are 2.0.1, 2.0.2 and 2.0.3, and the README documents a non-destructive migration from v0.3.7 and v1.x to v2.x. Running an unpinned tag means a future pull can move you across a release boundary without a decision.

Administrative recovery is handled by a CLI rather than by editing the database. The README lists password reset for locked-out admins among the admin tooling, and the workspace contains crates/admin and crates/cli for exactly this kind of operation.

bichon-cli

The same CLI handles export. The README states that account data can be downloaded as MBOX via bichon-cli, and that imports are supported from EML directories, MBOX files including Gmail variants, Thunderbird profiles, and Outlook PST files. EML files can also be imported from the WebUI. If you are migrating off a desktop client, that import path is the first thing to exercise, not the last.

Where Bichon stops being the right tool

The most obvious limitation is the one the README states up front. There is no send path. An SMTP server exists, but it is inbound only, with STARTTLS or TLS and AUTH PLAIN/LOGIN against API token authentication. Teams that want a shared mailbox they can reply from will need a separate client, and Bichon will not help with that workflow.

Search quality is bounded by language. The README says full-text search is optimized for European languages. For archives dominated by other scripts, the index is the part to validate before you commit storage to it, because reindexing a large archive is not free.

The licence is the second hard boundary. Bichon is AGPL-3.0. That is a deliberate choice by the maintainers and it is not a defect, but it changes the calculus for anyone embedding the server inside a product. If your plan involves exposing a modified Bichon over a network to users outside your organization, the licence obligations are the thing to examine before writing code, not after. This is not legal advice; read LICENSE and, if the answer matters commercially, ask a lawyer.

Finally, the README does not document rollback. There is a documented migration path forward from v0.3.7 and v1.x to v2.x, described as non-destructive, but the README is silent on reverting a v2.x deployment to an earlier version. Treat the storage volume as something to back up before any version change, and treat the upgrade as one-way until you have verified otherwise.

How Bichon differs from a sync tool or a mail client

The natural comparison is offlineimap or mbsync. Those tools also pull IMAP mail to local storage, and they are mature. The difference is what happens after the download. Offlineimap and mbsync produce a Maildir or similar on-disk structure and stop there; searching it means running a separate indexer such as notmuch or mu over the result, and there is no HTTP API or WebUI in the box.

Bichon folds the index and the serving layer into the same process. Tantivy is embedded, the REST API is generated from OpenAPI 3.0, and the WebUI ships with the server. Faceted tags, attachment filtering and thread reconstruction are part of the product rather than something you assemble. The trade is control: with Maildir you own a format every mail tool understands, and with Bichon you own an embedded storage stack whose backup and restore semantics are defined by the project rather than by a decades-old convention.

Against a hosted archive service, the difference is custody. Bichon runs on your host, with per-account SOCKS5 proxy routing and scheduled downloads driven by cron expressions. Nothing leaves your infrastructure. That is the whole point, and it is also the whole cost: you are the operator.

Maintenance, releases and licence cost

The last push to the repository was on 2026-09-10, and the most recent release, 2.0.3, was tagged on 2026-09-05. The repository is not archived. On that evidence the project is being worked on, and the release cadence across 2.0.1, 2.0.2 and 2.0.3 in August and September 2026 is steady.

Upgrade cost is mostly a storage question. Because the three layers are embedded and deduplicated by content hash, a version change touches the index, the blob store and the metadata database together. Back up the storage volume as a unit, and read the migration notes before crossing a major boundary. The README documents migration from v0.3.7 and v1.x to v2.x as non-destructive, which is a claim about the path it describes, not a guarantee about arbitrary versions.

Licence cost is the AGPL-3.0. For internal self-hosting the practical effect is usually small. For anyone distributing Bichon or offering it as a network service, the source-availability obligations are the part to understand. The repository also carries a CLA.md and a funding.json, which tells you contributions are governed by a contributor agreement rather than left implicit.

Operationally, the surface is small: one container, one config file, one storage volume. That is the maintenance story, and it is a short one.

Editorial conclusion

Adopt Bichon if you want a self-hosted archive of several IMAP accounts with full-text search and an API, and you accept the AGPL-3.0 obligations. Do not adopt it if you need to compose or send mail, or if you cannot run Docker or a Rust binary on your own host. Before committing, verify that the version you deploy is one of the 2.x releases, since the README documents a non-destructive migration path from v0.3.7 and v1.x to v2.x, and confirm the storage volume layout in the configuration reference so your backup covers the Tantivy index, the blob store and the metadata database together.

Frequently asked questions

Official sources

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