Documentation
Docs
Three pages, and deliberately only three. Keelpost is in private development with no production users, so there is no user guide worth writing and no stable interface worth publishing. What can be documented honestly is how the system is built, what standing it up actually costs, and which parts have been exercised rather than merely written.
What is here
The security model, at the level of code
Where each refusal lives: the fixed order of authorization checks, what the approval card is rendered from, the six MCP tools that fail closed, and what does and does not cross a queue.
Deploying it
The resources, the order they have to be created in, the two steps no command performs, and the one secret that cannot be lost. Roughly fifty operator actions, and we would rather you knew that first.
What runs today
What has been exercised by running the application, what is written but unproven, what is not built, and precisely what the word “green” means in this repository.
What is not here, and why
Documentation for something that does not exist is the same lie as a feature list for something that does not exist, and it is harder to spot.
- No user guide. There are no users. A guide written before anyone has used the product would document what we imagine, not what happens.
- No HTTP API reference. The application’s own routes are internal and will change without notice. The one interface intended for other software is the MCP endpoint, and what it will and will not do is on the security page rather than in a reference, because six of its fourteen tools refuse.
- No setup guide for Gmail, Outlook, Zoho or IMAP. None of them is built. The roadmap says so too.
- No compliance documentation. No certification, no audit, no penetration test, and therefore nothing to hand you. The full list of what we do not claim.
- No operations runbook. Nothing is in production, so there is no incident history, no alerting to describe and no service level to promise.
- No source repository. Keelpost is derived from Cloudflare’s Agentic Inbox under the Apache License 2.0, and that attribution stays in the footer and in the source headers. We have not published our own repository and are not promising when or whether we will.
How these relate to the rest of the site
The marketing pages and the docs describe the same system at two different distances, and neither is allowed to be the flattering one.
Security is the model as a reader deciding whether to trust it needs it: what the system refuses to do and what it does not claim. The docs version is the same model one level down — which check runs in which order, what the card is drawn from, and which tools are unreachable.
The roadmap is the ledger of intent: shipping, next, not started. Status is narrower and colder — only what has been exercised, and by what.
Why the docs live on this domain
These pages are served by the same small Worker as the rest of keelpost.com, from the same
origin, reading the same two stylesheets. That is a decision worth stating because the
obvious alternative — docs.keelpost.com — costs three things and buys none of
them back.
A subdomain is not a security boundary. A browser treats
docs.keelpost.com and keelpost.com as the same site, so
SameSite does nothing between them, and any cookie ever scoped to the
registrable domain is sent to both. What a separate host reliably adds is one more name that
has to be defended and one more certificate, DNS record and header policy to keep in step
with this one.
It would also mean a second copy of the stylesheet. This site’s content security
policy is style-src 'self' and there is no third-party origin on it at all, so a
stylesheet cannot be shared across hosts — it can only be duplicated, and a duplicate is
where two surfaces start looking like two products. Here the docs read the same generated
token file the marketing pages do, already in your cache by the time you arrive.
The third reason is the dull one: search engines consolidate a site’s signals more readily within one host than across a subdomain, and every inbound link to documentation would otherwise accrue to a name that exists for no reason.
What we did not do is put the docs in the product. The Worker that holds mail should have no public, unauthenticated, human-readable surface on it at all; this Worker holds no session, no mailbox binding and no product secret, and a defect in a documentation page here cannot reach a mailbox.
Join the waitlist
Sign-ups are closed while we build. Leave an address and we will write once, when they open.
We store the address you type, plus a hashed form of your IP address so the form can be rate-limited. One email when sign-ups open, and nothing after that. We do not share the list, and there is no analytics or third-party script on this site.
Also worth reading: the security model, and what is built and what is not.