2026

Hive — a hosted, multi-account Gmail manager

Built to clean up my own Gmail account, then to actually manage the 80+ separate Gmail accounts my company, Rajmandir Hypermarket, runs — several holding 50,000+ messages each. Search across every connected account at once, see who is filling them up, and clean up the clutter with rules that only ever move mail to Trash. Self-hostable, MIT-licensed.

Live site Source

Hive connects several Gmail accounts and treats them as one mailbox: unified search across every connected account, a local index that makes cross-account sender analysis fast, cleanup rules that trash on a schedule, a Trash view with restore and permanent delete, and sending from any connected identity. Deployed at hive.harshitsaini.in, running unverified with a 100-user Google cap by deliberate choice (see the ADR in the repo). Self-hostable under the MIT licence: docs/SELF-HOSTING.md covers Google Cloud, Turso, Resend, Vercel and Render, all on free tiers.

The problem

Started as a personal problem: years of clutter in my own Gmail with no good way to see what was filling it up or clean it out safely. It became a real one at work — Rajmandir Hypermarket runs 80+ separate Gmail accounts, several holding 50,000 or more messages each, with no way to search, analyse or clean any of them except one at a time, by hand, inside Gmail's own UI.

What I built

A single web app that connects several Gmail accounts by OAuth and treats them as one mailbox for the purposes that matter: search, cleanup and sending. A local metadata index (sender, subject, date, labels — never the body) makes cross-account search and sender analysis fast, because the Gmail API makes learning anything about a message expensive (one request per message against a ~3,000/min quota) while listing ids is nearly free — a real requirement once the mailboxes involved run into the tens of thousands of messages each. Cleanup rules are saved searches that run on a schedule and always move mail to Trash, never delete outright; permanent deletion lives behind one explicit, type-to-confirm action in the Trash view and is never reachable from a schedule. Every account-scoped route is deny-by-default, tokens are encrypted at rest, and message bodies are fetched live and never stored.

Built with

React
Vite
TypeScript
node-cron
Express
Zod
WebSocket
Playwright
SQLite

What I learned

The Gmail API cost asymmetry drove almost every architectural decision: messages.list returns up to 500 ids per call cheaply, but learning who sent a message costs one metadata request each against a roughly 3,000-request-per-minute quota — so a naive per-account sender report on a 100k-message mailbox would take about half an hour, every time it was asked. That is what forced a local index rather than querying Gmail live. A second, costlier lesson: Express matches routes in declaration order, and a fixed path (GET /messages/senders) declared after a wildcard (GET /messages/:id) is silently unreachable — every request for it was swallowed by the single-message handler as a request for a message literally named "senders", which then failed against Gmail and surfaced in the UI as an unrelated, confusing error. The fix was one line; finding it cost a release. Also learned the hard way that requesting Gmail's restricted mail.google.com scope and then seeking Google verification triggers a CASA security assessment that can cost real money, which is why the deployed app deliberately stays in unverified/testing mode with a 100-user cap.

Gallery

Unified Inbox
Mailbox Analysis
Cleanup Rules
Dark Theme