Correcting the Record on Garrul

A few weeks ago I published an evaluation of eleven comment systems and landed on Hyvor Talk. Second place went to Garrul, a self-hosted system that runs on Cloudflare Workers — it survived every elimination round and was the last candidate standing against the one I chose. Its maintainer read the post and left a comment correcting three things.

He was right about all three, and he had already fixed his side of them rather than arguing about mine. That deserves the same treatment in return.

Before any of the substance, though, the thing worth recording is that he bothered at all. A maintainer read a post that assessed his software, found two marks against it that it did not deserve, and spent his own time writing a careful correction rather than dismissing the review or letting it quietly stand. Nobody owes anyone that.

It is also exactly why the comment system is here. When I added it I wrote that posts are not conversations — that a reaction usually arrives privately over email or LinkedIn, stays invisible to everyone else, and leaves the next reader with the same question starting from nothing. This is that argument working in practice, and it worked by telling me I was wrong in the one place where it does the most good: underneath the post that carried the error.

What I Got Wrong

Reply notifications were never webhook-only

My functional requirements table marked Garrul’s reply notifications as ⚠️ Webhook, meaning a commenter could only be told about a reply if I wired up an integration to deliver it. That was wrong. Garrul sends plain email reply notifications, and always did.

The reason I marked it that way is worth stating plainly: the documentation had pages for webhook notifications and for Telegram, and nothing describing email. So I recorded what the docs supported. That is an explanation, not a defence — the mark was still wrong, and it is the kind of wrong that a reader trusts precisely because it sits in a table looking like a fact.

The operating cost was smaller than I claimed

I rated Garrul’s DevOps cost at $$ and wrote that “provisioning, configuring, integrating, and maintaining Garrul would quickly cost more than the Hyvor Talk subscription.”

Garrul is one Cloudflare Worker and two credentials. There is no server, no database host, no backup job, no upgrade window of the kind that made me eliminate Remark42 and Comentario. I grouped it with those two on operational burden, and on the evidence that grouping does not hold up.

That sentence about maintenance did exist in the repository when I evaluated it. It was in a file written for AI coding agents rather than in the README, so it was not in the place a human evaluating the software would look. The maintainer identified this himself, and it is the most interesting thing to come out of the exchange — the true description of a system quietly migrating into the machine-readable docs while the human-facing docs go stale. That is going to become a common failure mode and it deserves its own post rather than a paragraph in this one.

What Has Changed Since

The third point was the missing moderator notification, and that one I got right at the time. Garrul had no way to tell me a comment had been posted without an integration, and for a site where comments arrive rarely enough that I will not think to check, that mattered.

It is now fixed. Garrul sends an email digest of the moderation queue. That happened after I published, so the mark in the original post stands as an accurate record of what the software did in July, not of what it does today.

Whether It Changes the Decision

No, but not for the reason the original post gave.

I need to be careful here, because there is an easy dishonesty available: accept the corrections, then claim the outcome was always about something else. Two of the three corrections go directly to reasoning I actually used. I eliminated Garrul on operational burden, and the burden is lighter than I described. The comparison was not as lopsided as I made it sound.

What survives is narrower and more personal. I did not want to own any part of the comment infrastructure, at any size. One Worker is genuinely less than a persistent host, but it is not nothing — it is still my configuration, my credentials, and my problem at seven in the morning when a reader cannot post. I was buying the absence of that entirely, and a €12 subscription is a fair price for it. That was the real reason, and it holds. The cost estimate I dressed it up in was inflated by what I could not find in the documentation.

What I Changed in the Original Post

The reply notification marks are corrected, in both the full comparison and the shortlist, along with two sentences that described Garrul’s notifications generally as webhook-based when only the moderator side was.

Everything else stays as published. The moderator notification mark was true when I wrote it. The $$ DevOps rating was a judgement rather than a fact, and quietly editing judgements after the fact turns a published evaluation into something that cannot be argued with. Reversing it belongs here, in the open, where the reasoning is visible.

The Lesson

• An undocumented feature does not exist. Not to a prospective adopter, not during an evaluation, and not in a comparison table. Nobody deploys software to discover whether a capability they cannot find in the docs is secretly present.
• For self-hosted software, the documentation is the product surface. A managed service is judged on the thing you can immediately use. Free software is judged on what its docs claim, because that is all a reader has before committing time.
• One wrong cell does not stay in its cell. A wrong notification mark became a maintenance concern, which became a cost estimate, which became an elimination reason. Errors propagate downstream into judgements that look independent.
• Watch where the true description of your system lives. If the accurate account of how something is operated sits in a file written for agents, the humans evaluating it are reading fiction.
• Take the correction publicly. A maintainer who takes the trouble to correct the record is doing free, high-quality review. The cheapest possible response is to accept it in the same place the error was published.

I would rather be corrected than accurate by luck. The evaluation method was sound and I would run it the same way again — but it produced a table whose confidence exceeded its evidence, and the only fix for that is someone who knows the software better saying so out loud.

So, to the maintainer: thank you for the time it took to read the post and write the correction. Anyone comparing comment systems next month now finds both, in the same place. That is the entire case for having comments, made better by you than I could have made it myself.