Build web admin UI: login, view mailbox, manage mailboxes

Goal

Ship a proper web admin UI for the mail server so non-Stacks users (and Stacks users who prefer it) can log in, read their mailbox, and manage mailboxes from a browser — without needing the Stacks dashboard or a third-party mail client.

Today, mailboxes are auto-created from ./config/mail.ts and managed via the mail user / mail user:local CLI. There's a devtools surface but no shippable end-user web UI.

Scope

• Auth / login — users log in with their mailbox credentials (same accounts in /opt/mail/smtp.db).
• Read mailbox — list folders + messages, view a message (the SMTP API already queries S3 for message bodies, so this is a read layer over the existing API).
• Manage mailboxes — create new mailboxes from the UI (today that's CLI-only via mail user create / auto-provisioned from config/mail.ts).

Deployment

• Reuse the existing mail-server EC2 instance (i-0e365c6bd31da4678, mail.stacksjs.com) — no new infra. We already pay for that box for SMTP/IMAP.
• Run a bun webserver there serving an stx webapp alongside the mail daemon.

Priority / context

• Lower priority for Stacks users — the Stacks dashboard already handles mailbox management.
• Matters for non-Stacks adopters who want a self-hosted mail product with a usable web front-end out of the box.

Notes

• Per repo conventions: stx for templating, crosswind for styling.
• Mailbox storage is Maildir on disk + S3 for message bodies; the API layer to read messages already exists, so the UI is primarily a front-end + thin auth/session layer.

Revisiting this — most of the scope has landed since it was filed in May, so the issue text no longer describes the repo.

Scope vs. what's on main

Beyond the original scope there's also compose/reply/forward (webmail_compose.zig) and a mobile admin surface (mobile_admin.zig). main.zig now imports api/webmail_http.zig and starts it behind enable_webmail/enable_auth, so the "no HTTP surface to build a UI on" blocker this issue was written around is gone.

Per WEBMAIL.md, Phases 1, 2, 3, 5 and 6 are done and Phase 9 is built and verified locally over HTTPS. The one thing outstanding is the production deploy, with a runbook in Phase 9.

Three corrections to the issue body

1. Deployment target is wrong. It says to reuse "the existing mail-server EC2 instance (i-0e365c6bd31da4678, mail.stacksjs.com)". That instance no longer exists — production is a Hetzner box running Ubuntu 24.04, reached over SSH, with no SSM agent. Anyone picking this up gets pointed at dead infrastructure. #11 removes the same stale facts from CLAUDE.md.
2. The premise line is outdated. "There's a devtools surface but no shippable end-user web UI" was true in May; it isn't now.
3. crosswind still isn't installed — packages/webmail/package.json carries only bun-plugin-stx. Of everything this issue asked for, the styling convention in Notes is the part genuinely unmet.

Suggestion

Close this as largely delivered and track the remaining production deploy on its own, or narrow this issue down to just that deploy plus the crosswind adoption.

One caveat for anyone reading WEBMAIL.md on main right now: its status header and its intro contradict each other — the header describes a working read+write client while the intro three paragraphs below still says "none of it is live and none of it serves real mail", a leftover from the 2026-05-29 inventory. A commit reconciling that is staged but not yet pushed, so until it lands, trust the per-phase markers over the intro.