Two fictional mailboxes make the first run useful
The first local start creates 2 fictional mailboxes through the same Inbox SDK used by real providers. You can read conversations, switch inboxes, compose messages, test keyboard shortcuts, and inspect the unified view without handing over a Gmail account. That is a good demo boundary for email software. It lets a developer see the storage and provider model before OAuth, webhook, or DNS work enters the room.
SuperLocal keeps each account's identity and capabilities separate even when messages appear in one view. Replies retain the right sender, while Done and snooze are local workflows rather than fake upstream labels. Received HTML goes into a script-disabled iframe, remote images pass through authenticated routes, and tracker blocking stays under the SDK's policy. Those choices fit a local client that must treat every message as hostile input.
What happened when we ran it
Our sandbox installed commit d3725bc in 47 seconds with 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. Bun added 200 packages, and the environment occupied 189 MB. The build succeeded in 11 seconds. The repository itself contained 466 files, roughly 71,809 lines of source, and 66.6 MB before dependencies. It is a workspace monorepo with one CI workflow, a Dockerfile, and Compose configuration.
The test command failed after 37 seconds. Bun reported 338 passed and 337 failed across 675 tests, after 222,760 expectation calls. The final log lines named three AI triage service failures involving retained SDK messages, archive inventory accounting, and a paused 10,000-thread history. They do not explain why those tests failed, and the other 334 failures are not identified in the supplied tail. A single root cause would be guesswork.
A nearly even pass-fail split changes the recommendation. The 11-second build proves that the TypeScript output can be produced in our container. It does not show that mailbox state, recovery, or AI triage behavior is dependable. There is also no top-level tests directory, although the command found 675 tests across 2 files. Teams should reproduce the failures before connecting accounts that can send or modify mail.
Gmail and Inbound.new are the implemented providers
The README lists 2 real connectors as implemented: Gmail and Inbound.new. Gmail needs a Google OAuth web client, an exact callback URL, and explicit client credentials. Inbound.new uses an API key and then exposes discovered addresses. Mock and real data live separately, which lowers the chance that a developer action quietly crosses into a real mailbox.
IMAP and iCloud are marked in progress. Resend and Cloudflare Email Service are planned, and the document is careful to say that receiving APIs do not automatically provide IMAP folders or native read flags. Take those labels literally. If your account is outside Gmail or Inbound.new, SuperLocal is source material for a connector today, not an inbox you can finish configuring before lunch.
Real connections permit provider writes by default. An operator can disable them and authorize Gmail with its read-only scope, but existing grants must be reauthorized before sending or modifying messages later. Open issue 26 asks for Gmail alias support in recipient display and replies. That is a narrow issue with broad consequences for people who rely on several sending identities from one account.
Docker state has to survive as one unit
The Docker path publishes one browser port and stores state in the superlocal-state volume under /persist. Configuration, SQLite databases, generated keys, runtime secrets, and journals live together. The README warns against docker compose down -v, replacing the instance ID, sharing one volume between 2 instances, or backing up while the app is running. A database copied without its matching keys can fail closed.
Published images target Linux AMD64 and ARM64, with commit-specific tags and recorded digests. That is better than relying only on latest, though GitHub Container Registry packages may begin private until the owner changes visibility. Database migrations can also limit downgrades. Before an update, stop the app and copy the entire retained state, then pin the image digest you tested.
Remote access gives each person a private inbox
Google login can restrict a remote installation to an exact email allowlist. Each approved person receives private connections, messages, drafts, settings, and browser recovery data. Shared mailboxes and team roles are absent. That makes the current design suitable for several independent users on one installation, not a support desk where agents work the same queue.
Remote operation needs more than the 20-login-per-minute application limit. SuperLocal does not install TLS or configure the reverse proxy, and it does not trust forwarded client IP headers for its own limiter. The README tells operators to add per-client limits at the trusted proxy. Removing an email blocks access, but adding it back can restore an unexpired session, so offboarding should include sign-out or session-expiry checks.
No license and no release tag stop casual adoption
GitHub showed 225 stars and 7 combined open issues and pull requests on September 29, 2026. Search results split that into 1 issue and 6 pull requests. The main branch was last pushed on September 8, while newer pull requests covered Gmail reconnects, signatures, reply defaults, and AI request fixes. There was no GitHub release, so deployment has to pin a commit.
More seriously, GitHub detected no license and the root listing contains no license file. Public source code is readable, but that does not grant the permissions an open-source license normally provides. Ask the maintainer to add terms before copying the SDK into a product or running a long-lived fork. Combined with 337 failed tests and unfinished general mail support, that missing file makes SuperLocal an interesting engineering reference rather than a defensible production dependency.