HN Explorer

Show HN: Inbox.camp, AWS WorkMail Replacement (inbox.camp)

4 points by heythisischris ↗ HN
I've been running client email on WorkMail for a few years. When AWS announced the sunset (March 2027), they suggested switching to Zoho, Kopano, and Zoom Mail- none of which keep your data in your own AWS account.

So I'm building a replacement. inbox.camp sits on top of your existing SES, S3, and Route 53. Mail storage stays in your S3 bucket, sending/receiving goes through your SES, DNS is auto-configured in your Route 53. We're the thin client- IMAP, SMTP, and a web interface.

Stack: Hono + HTMX on Lambda for the web UI, Stalwart Mail Server (Rust, AGPL) for IMAP/SMTP/JMAP, client's own SES/S3/Route 53 for infrastructure. Cross-account IAM role for connectivity, fully revocable. Launching this summer. Happy to talk architecture, answer questions, or hear why this is a terrible idea.

3 comments

[ 1.8 ms ] story [ 16.5 ms ] thread
Oras
Email data are not meant to be within your cloud account anyway.

I think you're also missing other offers coming with Google/Microsoft email such as office, no setup, no maintenance .. etc.

heythisischris
Totally fair, Google / Microsoft are the right call for most people. This is specifically for folks already running infrastructure on AWS who want to keep email data in the same account for compliance, data sovereignty, or just simplicity. Definitely niche, but that's who WorkMail served.

Plus, down the line, I'm sure folks want to work on their own AI agents with inbox access, and Bedrock would be a perfect fit.

mike_strings872
This is interesting timing - I just built something adjacent to this problem. If you're on the SES → S3 pipeline specifically (routing incoming mail to an S3 bucket), I made QuickMailBites (github.com/bonskari/quickmailbites) - a Flutter desktop client that reads directly from S3. It won't replace a full mail server setup like Inbox.camp, but if you just want a lightweight reader for mail that's already being stored in S3, it's pretty lean.