There is some confusion about what ihasmail is, and lately a bit of effort spent framing it as a contest it never entered. Both are easy to fix, so here is the whole thing, plainly.
Updated 12 September 2026: the comparison page this piece originally pointed at has been taken down, and the section about it has been replaced with the reason why. Nothing else has changed.
It was written for one mailbox: mine
The first commit is dated 18 October 2025. I had been self-hosting my own mail for longer than I care to admit and had landed on Stalwart, which gives you mail, calendars, contacts, filters and file storage out of a single binary with a config you can actually read. What I did not have was a browser client that treated it as any of that. I was on Roundcube.
Roundcube is good software, and I want to be unambiguous about that, because "I replaced Roundcube" reads as an insult and is not meant as one. It has quietly run a large share of the world's self-hosted webmail for two decades. It is also, by design, an IMAP client: IMAP for mail, SMTP for sending, CalDAV and CardDAV for the rest, and a database of its own for whatever those protocols cannot express. Point any client built that way at Stalwart and you are using none of what makes the server interesting. That is not a fault in the client. It is a gap between what I had and what I wanted, and nobody was going to close it for me.
So I did what nerds do. I wrote my own. For me, on one server, with no plan for anybody else to ever run it.
That is not modesty or a founding myth. It is the reason the software is shaped the way it is, and it explains most of the decisions people ask me about.
Then I pushed it, and people showed up
On 23 August 2026 I pushed the v2 code — a rebuild as a Stalwart-first JMAP client — and announced it. That was just over two weeks ago.
It went better than I expected. People turned up and filed bug reports, several of them very good, and asked for things I had not thought of. Since that day, 32 issues have come in from people outside the project, and every one of them is closed. Most were adopted: the bug got fixed or the enhancement went in, usually within days. Nobody was owed that response and nobody paid for it — I did it because a stranger taking the time to write a careful bug report against your weekend project is a gift, and the correct response to a gift is to use it.
That is the part I did not plan for and now think is the best thing about the project.
What it is
Five rules, unchanged since the first commit:
Lean. No database. No IMAP. No SMTP. No CalDAV or CardDAV. One protocol — JMAP — plus Stalwart's blob, upload and EventSource endpoints. Everything durable belongs to the mail server, because the mail server is already the thing you back up.
Fast. JMAP batches. "Archive these forty messages and update the counts" is one round trip, not forty. Change tracking and server push mean a message read in Thunderbird disappears from the browser without a refresh.
As few moving parts as possible. It is one container in front of your existing server. With IMMUTABLE=1 it runs read-only with no volume at all. There is no admin panel, no plugin system, no second service to stand up, and nothing to keep in sync.
Disposable, and that one is a goal rather than a consequence. What I actually wanted was a webmail container I can destroy and recreate in seconds, anywhere, without burning a single synapse on reconfiguring it or syncing it back up afterwards. Deploy is the only step. There is no step two — no migration to run, no cache to warm, no state to carry across, nothing to restore, and nothing left behind when the old container goes. Move it to a different host and the only thing that changes is where it runs. Everything that matters was always on the mail server, which is the one machine you were backing up anyway.
Feature rich. Lean is not the same as thin. Mail, threads, calendars, contacts, file storage, a visual Sieve filter builder, nine interface languages, PWA push that arrives with the app closed. FEATURES.md is fourteen thousand words and lists the Stalwart capability each feature needs, so you can tell in advance what your server will and will not give you.
Those pull against each other constantly, and every interesting decision in the project has been about where exactly to give.
What it is not
It is not a replacement for anything. It replaced Roundcube for me, on my server, and that is the whole extent of the claim. If what you run now fits your setup, nothing about my project is an argument that you should stop using it.
It is not a response to any other project. The first commit is dated 18 October 2025 and the history is public. It was not built in reaction to anything, because at the time there was nothing to react to, and I am not going to spend words on who came first. The dates are in the repository for anyone who cares to look.
Parity is not a design goal. Not with anyone. A feature goes in when it earns its place against those five rules, and "the other one has it" is not an argument that it does. Chasing someone else's feature list is how you end up with their architecture, and their architecture is not the one I want. How much a webmail should keep is a real design question with more than one right answer, and the useful thing for you is knowing which answer you want, not knowing which project won an argument.
There is no comparison page
There was one, briefly. I was asked for it repeatedly, and I wrote it under rules I would want applied to me: the other side taken from their own published material, silence recorded as silence rather than absence, both columns dated, and plenty of rows where we were behind. I thought a straight answer would be more useful than a diplomatic one.
It was not. A comparison page attracts exactly the readers a comparison attracts, and almost none of the ones it was written for. It becomes a scoreboard, and then a fight about the scoreboard, and none of that has anything to do with whether the software is any good for your server. So it is gone, along with every other comparison that was on the site, and they are not coming back.
The rule now is simple: this project is this project. I will say what it does and what it does not do, and I will say why. Comparing it with something else is a job for you, because you know your setup and I do not, or for anyone else who wants to take it on. I will not be doing it.
That is not a retreat from what I said in the previous version of this piece. If something else fits your server better, run it. I mean that without any hedging. There is more than one AGPL webmail being actively built for Stalwart right now, by people who care about the details, and that is a better position than this ecosystem was in a year ago.
Saying no is a feature
ROADMAP.md is eight entries long and it is not a plan. It is the list of things ihasmail does not do, each with the reason it does not. Mail folder sharing, because Stalwart stores the share and never delivers it. Snooze, because nothing could act on your mailbox while the app is closed and ihasmail never stores a password. Encryption at rest, because turning it off does not decrypt what is already there, and a switch that reads as "make my mail safer" while quietly being irreversible is the wrong thing to hand an ordinary person.
A "not yet" that is really a "no" should say so, and it should say why. Every request I have declined is on that page with its reasoning, which is the least I owe someone who took the trouble to ask.
The whole ambition
It is still software written for one user, that other people now happen to run. Weekly images, an issue tracker I answer, a roadmap that says no out loud, and no intention of turning it into anything else.
If it suits your server, it is AGPL-3.0 and right here. If it does not, something else will, and that is a fine outcome too.