Support is the employee a solo developer cannot hire. Mail arrives, and either you read all of it or you read none of it — and the tools that would help cost more per seat than the product earns.
@pithy-sh/support is an inbound support inbox that lands mail in your own D1, classifies it on your own Workers AI binding, and links each sender to the account and purchases your app already knows about.
Every piece it needs was already in the catalog. That is the point of it.
What arriving mail becomes
Mail comes in through Cloudflare Email Routing, is parsed — multipart and attachments included — and is threaded on the standard reply headers, so a conversation stays one conversation rather than five unrelated rows.
Then it is classified three ways at once: category, priority and sentiment. Three axes rather than one label is what makes a sortable inbox instead of a tagged one — angry, high priority, billing is a queue you can work, and billing alone is not.
The taxonomy is federated. Eight categories ship, and you add your own.
Classification runs on your binding
The inference lands on your bill, and your customers’ support mail never leaves your infrastructure.
That is the same argument as the rest of the kit, and it matters more here than almost anywhere: support mail is where people put their account details, their frustration, and occasionally their passwords.
Everything is derived from immutable mail
A message is what arrived. It is never edited.
So a wrong classification is recomputed, not repaired — you change the taxonomy or the model and re-derive, rather than hand-correcting rows and losing the ability to reproduce anything.
Replies go out as you
Through email, carrying your domain, your DKIM signature and correct threading headers — which only the Worker can set. A reply that lands in the customer’s existing thread is the difference between a support tool and a mail merge.
The MX constraint, before you enable anything
Cloudflare Email Routing takes over a zone’s MX records.
So use a subdomain — support@help.yourdomain.com — and never your apex, or you will move your real mail off your existing provider on the day you provision.
That is why the three routing flags on pithy support provision are all or nothing, and why passing two of three is refused rather than partially applied.
What it deliberately does not do
No assignment and no status workflow. No assigned to, no open/pending/closed state machine, no SLA timers. That is a helpdesk product, and this is not one — if you have a support team, buy them a helpdesk.
No canned responses, no macros, no knowledge base.
No live chat, no phone, no social. Mail.
It does not read your mail for you. It sorts it. Somebody still has to answer.
The admin surface is control-plane only and default-denied, which means the hosted dashboard is where a human works the queue — and a management client you wrote yourself works just as well.
When you would reach for it
When you are one person, or a few, and customer mail is arriving faster than you can triage it by reading every message in order.
The specific thing it buys you is the link between a sender and an account: an email address resolves to the user, their purchases and their entitlements, so is this person paying is on the screen rather than three queries away.
Not if you have a support team with a helpdesk. Not if your support volume is five messages a week — a mailbox is fine.
What it needs
It requires secrets.
Six optional capabilities each add something, and this is the most composable thing in the kit:
| Compose | What it adds |
|---|---|
email | Replies, going out over your own domain and DKIM |
auth | Sender-to-user resolution |
payments | Purchases and entitlements on the sender’s record |
controlplane | The admin surface a dashboard reads |
storage | Attachments and raw message retention |
audit | A trail of who read and answered what |
Without email, mail arrives and is classified and nothing can reply. Without auth, a sender is an address rather than a person.