ForumMagnum, the forum engine behind LessWrong and the EA Forum

A reddit fork rewritten on Vulcan

ForumMagnum is the codebase that powers LessWrong and the Effective Altruism Forum. The team behind LessWrong created it in 2017 as a rewrite of the original version of LessWrong, which the project notes describe as a difficult-to-maintain fork of reddit. That origin explains the shape of the project. The goal was never to offer a general forum kit, it was to give the maintainers of one large writing community a stack they could modify freely.

The interesting consequence is the relationship with Vulcan, the framework for social applications such as forums and news aggregators. The project notes say the team started out using Vulcan as a library in the usual way, then forked its codebase and diverged considerably. The advice that follows is candid: read the Vulcan docs to understand where the project came from, but be wary of outdated information. One upstream page is still called out as particularly useful, and CEA maintains its own copy of the Vulcan docs on Notion.

So the interesting question for an evaluator is not whether ForumMagnum is a good forum framework in the abstract, but whether a diverged copy of a framework is a defensible thing to build on. Anyone reading the repository should assume that upstream Vulcan releases do not drop straight in.

GraphQL underneath, React and Apollo on top

The data flow is browser to GraphQL endpoint to server side code. GraphQL is the query language the browser uses to get data from the servers, and the project notes record that most usage of GraphQL is hidden behind utility functions, with occasional direct use to define APIs for accessing and mutating data. Apollo is the client side ORM for managing data on the client, and the team interacts with it primarily through the React hooks API. React covers how everything is rendered and how state is managed across the site.

Two editors are supported. CkEditor5 is the default text editor for posts, comments and some other form fields. Draft is described as an alternative rich text editor that is no longer the default but is still supported, which is the kind of detail that tells you about the cost of a rewrite: the old path stays alive rather than being deleted.

For inspection, the project exposes auto-generated documentation of its GraphQL API endpoints and lets you try queries with GraphiQL on the production server or on a development server. The project notes also point at React hooks, JSS styles, GraphQL, Apollo and Lodash references as the reading list for anyone working in the codebase.

The database is postgres 15 with pgvector, applied by hand

Local development runs against postgres, not the Mongo-style collections that later paragraphs of the project notes still describe. The setup notes ask for a local postgres instance, version 15, and require the pgvector Postgres extension to be installed. The database name is an arbitrary choice, and the application connects to a URL of the form postgres://localhost/forummagnum.

The schema is not migrated automatically for you during the local bring-up. Instead the accepted schema file is applied by hand through psql, using the file at schema/accepted_schema.sql in the repository. The package.json also exposes an exec-accepted-schema script that runs psql against $PG_URL with that same file, so the same artifact can be applied from a script in a configured environment.

Two details deserve attention. The extension requirement means a stock postgres install is not enough, and the described procedure for a new MacOS machine does not mention installing pgvector. Second, the project notes still contain an explanation of organizing data into collections such as a Users collection in Mongo databases. That description does not match the postgres and SQL schema instructions that precede it, so treat the collections paragraph as inherited text rather than current architecture.

Cloning the repo and standing up a local instance

Requirements are modest but specific: MacOS or Linux, a node version taken from the .nvmrc file, and curl if you intend to run some of the scripts and tests. The setup notes list known working setups on MacOS 10.15 and Ubuntu 18.04, including Ubuntu 18.04 under the Windows Subsystem for Linux. Node Version Manager is the suggested route to the right node version.

Clone the repository and install dependencies:

git clone https://github.com/ForumMagnum/ForumMagnum.git

cd ForumMagnum
yarn install

Then start a local postgres 15 instance and create an empty database:

brew install postgresql@15
brew services start postgresql@15

createdb forummagnum

Apply the schema:

psql forummagnum -f ./schema/accepted_schema.sql

Finally point the dev server at your local database:

yarn start-local-db --postgresUrl $YOUR_LOCAL_POSTGRES_URL

The instance then answers on http://localhost:3000/. Selecting which site you are working on is a code change, not a flag: you add your forum type to the export of allForumTypes in packages/lesswrong/lib/instanceSettings.ts, then change the forumType value in settings-dev.json from LessWrong to the forum you want. The setup notes list the settings file step as an open item, with no example of the file format.

Branch-specific databases through the branchdb script

Schema work is isolated with a per-branch database mechanism. The stated problem is that a feature touching database schemas is easier to develop when it does not alter shared database instances that other developers are working on. The answer is a script that creates temporary clones of the dev database, with four supported operations.

yarn branchdb create

yarn branchdb drop

yarn branchdb clean

yarn branchdb list

The semantics are per branch and per git clone: create clones a new dev database for the current branch, drop removes that clone, clean removes every cloned dev database created by this git clone, and list enumerates them. That scoping matters when several clones of the repository exist on one machine, since clean is bounded by the clone rather than the machine.

For developers inside CEA, the setup notes point at a separate ForumCredentials repository for access to a remote dev database and offers a different startup path:

yarn ea-start

That path skips the local postgres work entirely, which makes the branchdb workflow and the local database setup relevant mainly to contributors outside the organisation.

What the setup notes leave unfinished

Several rough edges are stated plainly. The database settings step is an open TODO with no example file, so a first run leaves the application without configuration until you work out the shape of that file yourself. The database also starts empty, and the setup notes state that some of the hardcoded links on the frontpage will not work in that state. You create accounts through the normal sign up process, a fake email being acceptable, and the first account you create becomes an admin, so you are advised to create a second account to see the site as a non-admin user sees it.

There is a Docker route as well. The repository ships a Dockerfile based on node:22.12.0, installing bsdmainutils and a transcrypt binary for the EA Forum, running yarn install in a cached layer, exposing port 8080 and starting the production script.

FROM node:22.12.0

EXPOSE 8080
CMD ["yarn", "run", "production"]

A documented deployment path exists, but it is documented at the level of a file rather than a walkthrough, and it assumes the same environment variables and secrets that the local path leaves undefined.

Forked framework, gradual typing, and a copyleft licence

Two structural choices shape the upgrade bill. The first is the Vulcan fork. Working from a diverged copy means bug fixes and features in upstream Vulcan do not arrive automatically, and the project's own advice to be wary of outdated documentation is the visible symptom. The alternative approach would be to keep consuming Vulcan as an unmodified library and layer site-specific behaviour on top, trading some freedom for a lower maintenance cost.

The second is the TypeScript migration. The team states that it is gradually moving from un-annotated JavaScript towards having annotations on everything, and that new code should have type annotations when it is added. That is a moving target rather than a finished state, so contributors inherit mixed code and a convention that new code follows a stricter rule than old code. Check types are enforced by scripts that also run lint, and the repository has separate unit, integration and jest configs, plus Playwright configuration for browser tests.

The licence identifier is GPL-3.0. The repository does not discuss relicensing, exceptions or how the licence interacts with third party components, so anyone planning a proprietary derivative needs to read the licence file itself rather than infer obligations from this summary.

Editorial conclusion

ForumMagnum is a reasonable pick for a team willing to adopt a diverged framework fork, run postgres 15 with pgvector, and read the source to fill in the gaps the setup notes leave open. It is a poor fit for a small team that wants a plugin-based forum with upstream community support, or for a project that expects a documented turnkey install. Before adopting, check that the missing database settings step in the setup notes is covered by your own notes, confirm the node version pinned in .nvmrc matches your environment, and decide whether a forked Vulcan copy is cheaper than tracking upstream.

Frequently asked questions

Official sources

1. ForumMagnum/ForumMagnum on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases