NimForum: a small forum server written in Nim

What NimForum is and where it runs

NimForum is a light-weight forum implementation with many similarities to Discourse, implemented in the Nim programming language and using SQLite for its database.

That last clause is the one that matters most for the design. A forum that stores its data in a single SQLite file has no separate database server to operate, and the README makes the point as a feature: utilizing SQLite makes set up much easier.

The forum itself runs at forum.nim-lang.org, the Nim community's own forum, which is the example the README leads with. It is worth noting that the Nim community chose this for itself rather than using a hosted Discourse, which says something about what a small language community considers sufficient.

The implementation language is Nim, which is why the topics name it, and the frameworks are named in the feature list, with Karax for the single-page application front end and Jester for the backend. The type-safe part of the feature list is not decoration, since Nim is a statically typed compiled language and the forum is compiled from source.

The licence field on the repository records MIT, and the README confirms NimForum is licensed under the MIT license. The copyright line attributes the work to Andreas Rumpf and Dominik Picheta for 2012 to 2018, so the code has been around for a long time even though the recent releases are more recent, with v2.5.0 from 2024-09-03, v2.4.0 from 2024-08-20 and v2.3.0 from 2023-10-16. The last push was on 2026-07-03.

The feature list and what it does not try to be

The feature list is short and each entry is specific.

Efficient, type safe and clean single-page application developed using the Karax and Jester frameworks. Endlessly customizable using SASS, which is the styling story rather than a theme picker. Spam blocking via new user sandboxing with great tools for moderators, and that is a design decision rather than a filter, since a new account is held in a sandbox rather than having its posts judged by a classifier. reStructuredText enriched by Markdown to make formatting your posts a breeze, which is an unusual pairing and a generous one. Search powered by SQLite's full-text search. Context-aware replies, so a reply knows what it is replying to. Last visit tracking, so the forum can show you what is new. Gravatar support.

The list ends with And much more, which is where a README usually admits that the summary is incomplete.

What is absent is as informative as what is present. There is no plugin system, no theme marketplace, no email notification pipeline, no single sign-on, no moderation queue with a plugin-driven rule set, no rich user profile system, and no web interface for a moderator to administer the sandbox beyond what the tools provide.

That is the shape of the project. It is a forum with the features a small technical community needs, written from scratch in a language whose community wanted its own forum, rather than a configuration of a general purpose forum software.

Running it from a clone

The development workflow is a short sequence of commands.

git clone https://github.com/nim-lang/nimforum
cd nimforum
git submodule update --init --recursive

# Setup the db with user: admin, pass: admin and some other users
nimble devdb

# Run this again if frontend code changes
nimble frontend

# Will start a server at localhost:5000
# MacOS users should note that port 5000 is reserved for AirPlay
# Set the entry "port" in forum.json to change the default
nimble backend

The submodule update matters and is easy to miss. The repository has a .gitmodules file, so the front end is pulled in as a submodule, and without that step the frontend build has nothing to work with.

The MacOS port note is a real detail. Port 5000 is the default AirPlay port on macOS, and the server binds it, so on a Mac you either change the port in forum.json or the two services conflict. The README names the setting explicitly, which saves the reader a search.

The devdb command creates a database with the user admin, the password admin, and some other users. That is a development convenience and it is the reason the setup instructions are safe to follow, since there is a known credential to log in with. It is also the reason the site must not be exposed as it is.

The nimble tasks are listed in the README, and the set describes the project well: backend compiles and runs the forum backend, runbackend runs the backend, frontend builds the JavaScript frontend with the CSS, minify minifies the JavaScript using Google's closure compiler, testdb and devdb create databases with an admin account, blankdb creates an empty one, test runs the tester, and fasttest runs the tester without recompiling the backend.

The Docker path and the dependency list

There is a Docker route, and the point of it is that you do not have to set up the host dependencies.

cd docker
docker-compose build
docker-compose up

The README says you can easily launch the site on localhost if you have docker and docker-compose, and that you do not have to set up dependencies such as libsass, SQLite and pcre on your host PC. The site is then available at http://localhost:5000.

For a manual install, the dependency list is short enough to be reasonable. libsass, SQLite, pcre, and Nim with the Nimble package manager, which the README marks as a build time dependency. For testing there is geckodriver and Firefox, marked as a test time dependency.

So the runtime needs are modest: a C library for the SASS compilation, a SQLite library, a PCRE library, and a Nim toolchain. That is what makes the container route a convenience rather than a necessity, and the difference is worth noting, because a forum is exactly the kind of service where a one-file database and a handful of libraries is a reasonable long-term operational commitment.

The repository also has a setup.md document, which the README links for the setup instructions, and the full setup steps live there rather than in the README.

The karax pin problem and what it says about the project

The troubleshooting section is worth reading because it reveals how the project is held together.

The README says you might have to run `nimble install karax@#5f21dcd` if setup fails, and gives the failure it produces.

andinus@circinus ~/projects/forks/nimforum> nimble --verbose devdb
[...]
  Installing karax@#5f21dcd
       Tip: 24 messages have been suppressed, use --verbose to show them.
     Error: No binaries built, did you specify a valid binary name?
[...]
     Error: Exception raised during nimble script execution

And then the instruction that the hash needs to be replaced with the one specified in the output.

That is a pinned git revision of a dependency, by hash, with a note that the hash changes. It is a symptom of building on a framework that is developed in the same language as the project, where the framework's own master branch moves underneath you.

The diagnosis is that the project depends on a moving upstream in a way that makes fresh installs fail sometimes. A fork or a release of Karax would remove the problem, and the README's own advice is to pin to whatever hash the current output specifies, which is a workaround rather than a fix.

This is the clearest signal of the project's maturity. A forum server that needs a per-machine hash pin for its front end framework is a project that works for its author and for people who follow the troubleshooting steps, and that will need attention the next time Karax changes its build output.

Where NimForum is the wrong choice

The first limitation is the scale question, and it is the one the architecture decides for you. SQLite with full-text search is excellent for a community forum and becomes the bottleneck at a size where a separate search service is worth running, and there is no path in this codebase to one, because the search is SQLite's own. A forum expecting thousands of concurrent users and a large archive of posts is outside what this design serves well.

The second is the plugin ecosystem. Discourse's extension model is a large part of why communities choose it, and NimForum has no equivalent. Anything a community needs beyond the built-in features means a fork.

The third is the moving dependency. The Karax pin issue in the troubleshooting section is the concrete example, and it affects every fresh install rather than only upgrades. A project that a small team has to maintain long term is carrying a dependency whose master branch moves.

The fourth is that it is a server you have to run. A community that wants a forum with no operations at all should use a hosted service, and a community that wants Discourse's moderation and notification features should use Discourse. NimForum is for the case where the community wants a small thing it can run and understand.

The fifth is the release cadence. The recent tags are v2.5.0 from 2024-09-03 and v2.4.0 from 2024-08-20, with the last push in July 2026, so the code moves more often than the tags suggest, and a deployment pinned to a tag may be a long way from master.

NimForum compared with Discourse and with a minimal forum script

The comparison with Discourse is the one the README itself invites, since it says the implementation has many similarities to Discourse. The difference in approach is that Discourse is a large Ruby and JavaScript application with a plugin architecture, a rich moderation model and a background job system, while NimForum is a compiled Nim program with a single page application front end and a SQLite file. The similarities are in the user-facing model, in the topic and reply structure, in the categories, in the last visit tracking, in the avatar handling, in the sandbox for new users.

So the choice between them is really a choice of scale and of who operates it. Discourse is the answer for a community with a moderation team and a need for extensibility. NimForum is the answer for a community that wants the same shape of thing with one binary and one file.

The second comparison is with a minimal forum script, the kind of thing that is a few hundred lines and handles topics, replies and nothing else. The difference in approach is that NimForum includes the parts that a community actually needs, the new user sandbox, the search, the context-aware replies and the last visit tracking, and those are the parts that take the work. The forum.nim-lang.org instance shows the model at a scale where those features matter.

The third comparison is with a hosted service such as a community platform run by a vendor. The difference is ownership. A hosted platform does nothing for you, and NimForum does everything for you, and the middle ground of a self-hosted Discourse is a different set of operational trade-offs from a self-hosted NimForum with a SQLite file.

Licence, project state and what to check before you deploy it

The licence field on the repository records MIT, and the README states that NimForum is licensed under the MIT license, with a license.txt file in the repository. The copyright notice credits Andreas Rumpf and Dominik Picheta for 2012 to 2018, so the code predates the modern version numbering by a long way, and an MIT licence is a permissive one that lets a community fork it without friction.

The project is not archived and the last push was on 2026-07-03, so it is being worked on, and the release history shows v2.5.0 from 2024-09-03, v2.4.0 from 2024-08-20 and v2.3.0 from 2023-10-16.

The repository layout is small and tells you the shape. There is src/ for the application, public/ for the served assets including the compiled CSS, tests/ for the test suite, a docker/ directory for the Compose setup, a mockup/ directory for the design assets, localhost.local/ for the local deployment, a nimforum.nimble file for the Nimble package and its tasks, and setup.md with the full setup instructions.

Four things to check before putting it in front of users.

The default credentials. The devdb command creates admin and admin, and the setup instructions have to change that before the forum is reachable by anyone other than you.

The port. The default of 5000 conflicts with AirPlay on macOS, and the setting lives in forum.json.

The Karax dependency, because a fresh install can fail on it and the fix is a hash from the error output rather than a documented version.

And the upgrade path, since the released tags are older than the current master branch, so you should decide whether to deploy a tag or a revision, and record which.

Editorial conclusion

NimForum suits a small community or a language project that wants a Discourse-shaped forum with a single binary and a single file database rather than a container stack and a separate search service. It is the wrong tool for a forum expecting a large user base, a moderation workflow at scale, or the plugin ecosystem that Discourse has built, and the wrong choice if your team does not want to run a server at all. Before deploying it, read setup.md, which the README points to for the full instructions, and note that the default development credentials are admin and admin, which has to change before the site is reachable by anyone else.

Frequently asked questions

Official sources

1. License: MIT
2. nim-lang/nimforum on GitHub
3. Project website
4. README
5. Releases