Flarum

Last reviewed Sep 13, 2026 · 734 words

Flarum has no official Docker image, and the supported install path is Composer. If you have never typed composer create-project, that is the most useful thing to know before you read further, because it shapes everything: installing, updating, and adding every feature you are used to seeing in a forum all go through the same PHP dependency manager. Accept that, and you get the fastest, cleanest forum interface you can self-host on 512 MB of RAM. Reject it, and Discourse is the safer, heavier, more complete alternative.

Composer installs it, and Composer updates it too

The requirements are a current PHP 8 release with the usual extensions, MySQL or MariaDB, and a web server whose document root is the public/ directory. The install is a single command in an empty directory:

composer create-project flarum/flarum .

Then you open the site, and a web installer asks for database credentials and an admin account. Upgrades are composer update followed by php flarum migrate and php flarum cache:clear. That is the entire operational surface. It also runs fine on ordinary shared PHP hosting, which is a niche almost nothing else in this directory occupies.

If you want a container, the community mondedie/flarum image is what most people use and it is well maintained; the deployment listing's Docker option refers to images like that, not to anything the Flarum team publishes.

The core is small on purpose

Out of the box you get discussions, tags as the organising unit (no nested forums), mentions, likes, flags, sticky and locked threads, suspensions, subscriptions, Markdown and BBCode. What you do not get: private messages, polls, file uploads, signatures, user badges, reactions beyond a like, or a proper user directory. Each of those is an extension, and most of the good ones come from the FriendsOfFlarum organisation, whose packages start with fof/. Adding one is another Composer line plus a switch in the admin panel:

composer require fof/upload
php flarum cache:clear

A realistic launch set for a hobby community is 6 to 10 extensions: uploads, polls, a byobu-style private messaging extension, social login, a spam filter, a sitemap. Budget an evening for choosing them and reading each one's issue tracker.

Extensions are the operational risk

Flarum's major releases break extension compatibility, and an extension whose maintainer has moved on will block your upgrade until you remove it or find a replacement. This is the single most common reason Flarum instances get stuck on an old version. The defence is discipline at selection time: prefer fof/ packages, check that the last commit is recent, and keep the count low. Every extension you skip is one fewer thing that can hold your forum hostage.

Why pick it over Discourse or NodeBB

Discourse is the bigger project by a wide margin and is what I would tell a company to run. Its official install needs a dedicated machine with 2 GB of RAM, brings its own PostgreSQL, Redis and background workers, and refuses to be installed any way but its own script. Flarum's total footprint is a PHP process and a database, and its single-page interface feels quicker to use than either rival. NodeBB sits between them: a Node.js app with a database of your choosing, a richer core than Flarum and a smaller ecosystem than Discourse. The forums category lists the field, but those three are the real choice for anything new.

The old guard is a different conversation. phpBB still works and has 20 years of plugins, but a fresh forum in 2026 has no reason to start there, and a migration from it to Flarum is a community-maintained, occasionally painful project rather than a supported import.

What I'd do

For a hobby or small-project community with one admin who is comfortable at a shell, Flarum on a 1 GB VPS with MariaDB and Caddy in front, 8 extensions or fewer, all from fof/ where possible, and a calendar reminder to run composer update monthly. For a company forum, a support community or anything where the admin might change, Discourse, because its ecosystem will outlive whichever extension author gets a new job. And in either case, the vBulletin migration crowd should read that page first, because the data move is the hard part, not the install.