Five Months of Building: Where inbox.camp Is Today

The last post here was in April. Since then I've mostly been heads-down, so here is what actually happened, what works today, and what's next.

The short version

inbox.camp is real. It provisions a dedicated mail server inside a customer's AWS account, imports their WorkMail organization, copies every mailbox, and switches their MX when they click a button. I'm running my own domain on it. Two features that customers asked for before I'd written a line of them, an admin console and webmail, shipped this week. I'm onboarding WorkMail teams one at a time this month, and self-serve signup opens in October.

What I built

The core is a provisioning engine: a reconciler that walks each customer through ten idempotent steps, one per minute, until their server is live. Verify the role, build a network, launch a server, attach storage, publish DNS, set up outbound mail through SES, round-trip a test message, migrate mailboxes, switch MX, activate monitoring. Every step is safe to re-run. Failures are boring; the next tick retries.

The server itself is Stalwart, an open-source mail server written in Rust that speaks IMAP, JMAP, SMTP, CalDAV and CardDAV. I decided early not to write my own mail server, and not to fork this one. The value is in operating it well inside someone else's account, not in the MTA.

Around the engine: a customer console for users, groups, passwords and domains; a webmail app that talks to the customer's server directly from the browser, so mail never passes through inbox.camp; heartbeat monitoring that pages me when a server goes quiet; hourly snapshots; and an onboarding wizard that takes a new customer from "I have a WorkMail org" to "my MX points at my own server" without me touching anything.

What I proved

The design promise was that mail never touches my infrastructure. That's now mechanically true, and I can point at the mechanism for every piece: message bodies in the customer's S3, the index on their server, credentials generated on their server and never sent anywhere, migration running on their server, webmail talking to their server. The security page spells it out.

I also proved the migration path on real stakes. My own company domain ran on WorkMail. On September 1st the engine copied its mailboxes, verified the count by reading the server back over IMAP, published the DNS, delivered a probe through the public MX in five seconds, and switched. The next morning I was reading mail on my phone from a server in my own account. A separate post covers the three bugs that night exposed, all fixed the same night, all now defaults.

What I decided

• Managed only, for now. The same engine can run a fully hosted version or a no-standing-access enterprise version. Neither is on the pricing page yet. Managed mode, your account plus one role, is what every early conversation actually wanted.
• Passwords: I set them. Migration needs to log in to WorkMail as each user. Instead of asking customers to hand me passwords, the wizard resets each user's WorkMail password to a new one, uses it for the copy, and sets the same one on the new server. Users get one new password, once.
• Backups over high availability. A single server with hourly snapshots and a self-heal path recovers in minutes and never loses mail, because sending servers retry for days. Zero-downtime clustering costs more than a 20-seat org's whole bill. It's an enterprise option, not the default.

What's next

September: pilots. If you're on the waitlist with a WorkMail org, you'll hear from me directly. October: self-serve signup, calendar and contact migration, and the Stripe checkout nobody has needed yet because pilots are free. Between now and then, the boring stuff that makes this trustworthy: the public repository with the exact CloudFormation template, the restore drill, and a security questionnaire I can hand to someone's compliance team.

WorkMail shuts down March 31, 2027. Teams decide in the fall and migrate in the winter. That's the window, and I'm in it.