Show HN: Inbox.camp, AWS WorkMail Replacement

#1

Post by heythisischris » Wed, Apr 01, 2026, 12:50 PM UTC

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.

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

Re: Show HN: Inbox.camp, AWS WorkMail Replacement

#2

Post by Oras » Wed, Apr 01, 2026, 1:36 PM UTC

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.

Re: Show HN: Inbox.camp, AWS WorkMail Replacement

#3

Post by heythisischris » Wed, Apr 01, 2026, 1:46 PM UTC

Oras wrote: post #2

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.

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.

Re: Show HN: Inbox.camp, AWS WorkMail Replacement

#4

Post by Oras » Wed, Apr 01, 2026, 2:27 PM UTC

heythisischris wrote: post #3

Oras wrote: post #2

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.

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.

> 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.

I think you found your niche, this could be a pretty good setup for agents

Re: Show HN: Inbox.camp, AWS WorkMail Replacement

#5

Post by mike_strings872 » Mon, Apr 06, 2026, 11:32 PM UTC

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.