- One aMail container per customer at name.amail.stream, kept running, patched, and reachable over HTTPS.
- The MCP and REST endpoint at /mcp and /api.
- Encrypted backups of your container’s volume — ciphertext we cannot open.
- Billing through Stripe, and the analyzed counter your plan is measured by.
Privacy & logging · plain language
We can’t read your mail. We log errors, not you.
Hosted aMail is your own aMail, in its own container, on a box we run. Your mail inside it is encrypted with a key we never store. Nothing on this page is legal boilerplate; it is how the hosted product is built, and where the edges are.
What we host. What you bring.
We run the harness. Everything inside it is yours.
- Your mail accounts — Gmail, iCloud, Outlook, any IMAP/SMTP — attached as sub-emails.
- Your agents — Claude, ChatGPT, Grok, Cursor, a cron job — connected with tokens you issue and revoke.
- The key. It is unwrapped by your tokens, your passkey, or your recovery code. Not by us.
- The reading. Your agents read, act, and mark mail analyzed under your credentials. We count the marks; we do not do the work.
Your key, not ours
Encrypted with a key we never store.
Your container’s whole database — bodies, search index, saved mailbox credentials — is encrypted with one key. That key is never written down. It is wrapped once for each credential you hold: every agent token you issue, your passkey, and a recovery code shown once at signup. Think keyslots on an encrypted disk.
- Boots locked. After any restart the database is ciphertext until one of your credentials unlocks it — usually your agent’s next call.
- Lives in memory. While unlocked the key exists only in your container’s RAM. It is never written to disk or to a log, and it is gone when the container stops.
- Revoke an agent, drop its slot. Rotate a token and the old one can no longer unlock anything.
- Delete means delete. Closing your account removes the volume and every keyslot. Nothing is left that could be decrypted later.
- Lose every credential? You lose the local cache and analyzed state, not your mail — that still lives with your providers. Reconnect and resync.
The honest edge: while your harness is unlocked, the key is in memory on hardware we operate. We ship no tooling to extract it and it never touches disk, but “never store” is the exact claim — not “could never, under any circumstances”. If you prefer convenience over that, an optional escrow slot can keep you unlocked across restarts. It is off unless you turn it on.
lock cyclehow the design behaves
# studio.amail.stream · container boots → state LOCKED · database is ciphertext · key not on disk $ agent → POST /mcp Authorization: Bearer •••• → keyslot token#1 unwraps the key into memory → state UNLOCKED · sync resumes · tools answer # container restarts (our deploy, your reboot, anything) → memory gone · state LOCKED again → next agent call, passkey, or recovery code unlocks it
what we can see
What we can see, and what we can’t.
Running a service means seeing some things. Here is the whole list.
| Data | Detail | We see it |
|---|---|---|
| Analyzed count | How many messages your agents marked analyzed and when. This is what the weekly allotment and Enterprise metering are built on. | yes |
| Routing metadata | Your tenant hostname, the connecting IP, and bytes moved — needed to route and rate-limit. | yes |
| Billing | Name, email, card, and invoices, held by Stripe. We see what Stripe shows us. | yes |
| Mail bodies, subjects, addresses | Encrypted with a key we never store. Not readable by us while your harness is locked. | no |
| Search queries, MCP calls, opened messages | Not logged. Not stored outside your encrypted container. | no |
| Which agents you use, what they do | Your token, your agent, your inference. We do not see the conversation. | no |
Two things outside our fence: your mail providers see your mail — IMAP and SMTP are not anonymised — and whichever model your agent runs on sees whatever your agent reads. Those are your relationships, under your accounts. We are not in the middle of either.
Logging
Errors only. Nothing about what you do.
We deliberately do not keep activity logs on tenant hosts. Access logging is off at the edge and in the app. What remains is what we need to fix a broken deploy: errors, health, and the analyzed counter you are billed on.
| Log | Kept | What is in it |
|---|---|---|
| Errors | yes | Route, HTTP status, an opaque internal id. Never a body, subject, address, or query. |
| Health checks | yes | /api/health up/down and release id — no customer data. |
| Metering events | yes | Analyzed count increments with timestamps. |
| Access logs on tenant hosts | no | Switched off at the edge and in the app. |
| MCP tool calls, search, reads, sends | no | Not logged at any level. |
| Message content, credentials, keys | never | Encrypted in your container. Not present in any log path. |
Error logs are rotated, not archived. If an error entry would need your data to make sense, it gets an opaque id instead and we ask you before looking any further.
Status
This is the design, not a live service yet
Hosted is pre-launch. This page describes how it is built so you can hold us to it. The open-source app encrypts saved credentials today; whole-database encryption with keys you hold is landing upstream, in the open.
Same code as self-host
Everything above ships in the MIT repo. If you would rather hold the box as well as the key, clone it. Hosted is operation, not a locked fork.
nova-centauri/aMail ↗Questions
If anything here is unclear, or you think a claim is too strong, say so. There is a human on the other end.
Contact Steve