Discourse vs Flarum

This is the comparison where feature checklists are least useful. Post, reply, mention, tag, notify, moderate — both do all of it, and the ticks line up. What does not line up is what each one obliges you to run, and that single difference determines who can adopt which.

The row that decides it

Flarum is a PHP application installed through Composer. It runs where PHP runs, which in practice means almost anywhere, including the hosting plan already serving the main site. Discourse is a Rails application that expects PostgreSQL, Redis and a container host, and its supported installation path assumes you are comfortable with all three.

Neither is harder in the abstract. The question is which one somebody available to you can already operate, because the platform is not a purchase — it is a decade of upgrades, and the upgrades are performed by a person who either knows that stack or does not.

If PHP is what the organisation runs, Flarum removes an entire category of problem before it exists. If there is real infrastructure competence and a container host is unremarkable, Discourse's requirements stop being a cost and the comparison moves on to what it buys.

What the extra machinery buys

Discourse is the more complete product and it is not close. Trust levels that unlock privileges as somebody participates, a moderation queue built for volume, a search that assumes long topics get revisited, an email route that lets a member reply from an inbox and land in the thread — these are in the core, not assembled from extensions.

The reading model is the part people notice first. Pagination is replaced by a reading position, so a long topic behaves like a document you return to. On an active community that is a real improvement. On a quiet one it advertises the absence of activity, which is the honest counter-argument and applies to every busy-board feature in the list above.

What Flarum's restraint buys

A small core is a deliberate position, not an unfinished one. Flarum ships the forum and nothing else; tags, mentions, embeds and the rest arrive as extensions you choose. The result is an installation that contains what you actually use, which is easier to reason about and faster to serve.

It also loads more quickly and feels lighter in use, which is not a benchmark argument — almost no self-hosted community is performance-bound — but a perceptual one. On a board where people dip in for a minute, that lightness reads as respect for their time.

How each one ages, which is the second real difference

Both are extensible and the mechanisms fail in opposite ways, which matters more at year three than at week one.

Flarum extensions are Composer packages. Versions are declared, conflicts surface at install time, and an extension that has not been updated for the current release refuses to install rather than half-working. That is a genuinely better failure mode: the upgrade stops and tells you why, instead of succeeding and leaving something subtly broken.

Discourse plugins are Ruby and run inside the application. The project moves quickly, which cuts both ways — plugins get fixed promptly, and plugins get broken by releases, sometimes the same ones. The core is large enough that many communities need no plugins at all, which removes the problem rather than solving it.

For either, the check is the same and takes a minute: find the extension you would actually need, open its repository, and compare its last commit to the platform's last release.

Storage, which arrives quietly

Text costs nothing. Uploads do, and a board that allows them accumulates them at a rate nobody projects at the start — two years of screenshots in a support forum becomes a backup problem and a bandwidth line.

Discourse supports object storage in the core, so uploads can be pushed off the application server from day one and the disk stops being a deadline. Flarum keeps them on the filesystem by default and reaches object storage through an extension, which works and is one more thing to keep maintained.

If uploads are central to what the community does, check this before adopting rather than after. Retrofitting object storage means rewriting the paths embedded in years of posts, which is the same class of work as a migration and just as easy to underestimate.

Maturity, stated plainly

Discourse has been in production since 2013 on communities of every size, and the questions you will hit have been answered somewhere. Flarum reached its stable line much later and its extension ecosystem is correspondingly smaller — not thin, but smaller, and more of it is maintained by individuals rather than by a company.

That asymmetry is worth weighing honestly rather than dismissing. It is not an argument against Flarum; it is an argument for checking that the specific extensions you depend on have somebody behind them, which is the same check as above and is simply more load-bearing here.

What each costs to run

Both licences are free, which makes the money column identical and unhelpful. The difference is in the hosting shape.

Flarum fits on the plan you already have. PHP and MySQL, no separate cache, no container runtime — for many organisations the marginal cost of adding it is zero, because the capacity is already paid for.

Discourse wants its own server with room for PostgreSQL and Redis alongside the application, which puts it on a small virtual machine rather than shared hosting. That is not expensive in absolute terms; it is simply a different line item, and it comes with a person's attention attached. When the attention is what you are short of, the vendor-hosted figure is the honest comparison rather than the server cost.

Search and the archive

Discourse invests heavily in search because its model assumes topics that stay open and get revisited, and on a board with real history the difference is obvious. Flarum's core search is adequate for a board of a few thousand posts and is commonly extended for anything beyond that.

This only becomes a deciding row when the archive is the point — a support community, a knowledge base with replies, anything where the same question arrives every few weeks. If the board is conversational rather than referential, it barely registers.

Who is behind each one

Discourse is developed by a company that sells hosting for it. That funds full-time maintenance and a predictable release cadence, and it means the open version and the commercial one are the same software rather than a reduced edition.

Flarum is a community project with a smaller core team. The upside is that nothing is held back for a paid tier; the risk is the ordinary one for volunteer-maintained software, which is that a quiet period is harder to read. The activity band in the table above is the cheap version of that check — the fuller one is to look at how quickly questions get answered in each project's own forum, which both of them run on their own software.

Moving between them

Discourse ships a Flarum importer — it is one of the sixty-three scripts in its repository, so the path in that direction is written and maintained. The reverse is not equivalent, which is the usual asymmetry: importers get written towards the platform that wants the users.

The practical consequence is that Flarum is the easier first choice to reverse. Starting there and moving to Discourse if the community outgrows it is a supported path; the opposite is a project. For an organisation genuinely unsure which it needs, that asymmetry is a reason to begin with the lighter one. What imports from what is read from the repositories here.

Two things that look like differences and are not

Appearance. Both ship a clean default and both are themeable, and screenshots of either can be made to look like the other. Choosing on the default theme is choosing on the one variable you will change in the first week.

Single sign-on. Both connect to an existing identity provider, so a comparison that treats SSO as a differentiator is out of date. What does differ is how much rope you get: Discourse can be configured so the forum has no local accounts at all, which enforces one source of identity rather than relying on discipline. With Flarum the same result is achievable and depends on an extension staying maintained — the recurring theme of this page.

Deciding

Take Flarum if the stack is PHP, if the requirement is a forum rather than a community platform, or if the board will be quiet enough that Discourse's activity-shaped interface would work against it.

Take Discourse if the community is or will be busy, if moderation load is the thing you are actually buying software to solve, and if the operational requirements are unremarkable where you work.

If the honest answer to the runtime question is that nobody maintains servers, both are sold hosted by their own vendors, and that is the same software with somebody else on call rather than a lesser version of it.