# Matterwiki: a self-hosted team wiki on Node.js and React, with a new version in active development

> Matterwiki is a self-hosted wiki for small teams built on Node.js, React and SQLite3, with MySQL available via Knex, distributed under the MIT license. The README warns that the master branch may have broken features while a new version is under development.

**Matterwiki/Matterwiki** — A simple and beautiful wiki for teams

- Repository: https://github.com/Matterwiki/Matterwiki
- Website: http://matterwiki.com
- Stars: 2,094 · Forks: 175
- Language: JavaScript
- License: MIT
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/matterwiki-matterwiki

## What Matterwiki is and what the README warns before you start

Matterwiki is a self-hosted wiki for small teams to store documentation, onboarding content, culture guidelines and notes. Articles are organized under topics, and every change records who made it and when, making history visible to all users. The only GitHub release is v0.2.3 from 2017-02-12, and the last push to the repository was on 2026-05-20.

Before anything else, the README opens with a stability warning: some features may be broken while the team works on the next major version. The README advises waiting until that work is complete if stability matters, and points to the development branches for a preview. This context shapes the adoption decision: Matterwiki in its current state is a project mid-development, and its master branch carries that caveat explicitly.

The project targets small teams where conventional wiki platforms carry too much complexity. Setup requires Node and npm, and the full installation takes eight numbered steps, two of which are optional depending on how you choose to run the process.

## Node.js API, React front-end, Bookshelf ORM and Knex query builder

Matterwiki runs a Node.js API served by Express, with a React front-end compiled by Webpack. The database layer uses Bookshelf as an ORM sitting on top of Knex as the query builder. Knex is the reason switching between SQLite and MySQL is a configuration change rather than a code change: only the connection object in knexfile.js needs to change, and the query layer stays the same.

Authentication uses JSON Web Tokens. The auth_secret value in config.js is the signing key for every access token, and that file lives in the project root alongside index.js and knexfile.js, with no separate secrets management mechanism. The README calls this value out explicitly and marks setting it as a mandatory step.

The JSON API is documented in API.md at the repository root. Because the React front-end communicates with the back-end entirely through that API rather than through server-rendered pages, any HTTP client can use the same interface. The README mentions integration with mobile apps and external blogs as a consequence, though no authentication flow for external callers is documented there. Dependency versions in package.json are fixed pins: Express 4.14.0, React 15.3.0, Bookshelf 0.10.0, Knex 0.11.10 and sqlite3 3.1.4.

## Installing and starting: eight steps from git clone to admin account

Setup requires Node (version 7 or above, per the README) and npm. Clone the repository, install dependencies, then build the client bundle:

```bash
git clone http://github.com/matterwiki/matterwiki
npm install
npm run build
```

Before npm run build, open config.js and replace the auth_secret value with a private phrase used to encode and decode access tokens. The README marks this step as mandatory.

For production, the README shows PM2 as the process manager:

```bash
NODE_ENV=production PORT=8000 pm2 start index.js --name "matterwiki"
```

NODE_ENV accepts dev or production. PORT defaults to 5000 if not set. Running npm start builds and starts the production process directly without PM2.

Once running, visit yoururl.com/#/setup (or localhost:5000/#/setup for local access) to create the first admin account. That account gives access to the admin dashboard, where topics and users are created. Every article belongs to one topic, so creating at least one topic before inviting users ensures there is somewhere to file new articles.

## SQLite is the default; switching to MySQL requires editing knexfile.js

SQLite3 is configured by default, stored as a file at db/matterwiki.sqlite. No separate database server is required for this path, which reduces the deployment footprint for a small team. MySQL is available for situations where concurrent write performance matters, and it requires MySQL 5.6.5 at minimum.

Switching to MySQL is a two-step process: install the driver and update the connection object in knexfile.js:

```bash
npm install mysql
```

Change the db configuration in knexfile.js from the SQLite block to a MySQL connection object:

```js
module.exports = {
  client: 'mysql',
  connection: {
    host : '127.0.0.1',
    user : 'your_database_user',
    password : 'your_database_password',
    database : 'myapp_test'
  },
  useNullAsDefault: true
}
```

No data migration path from SQLite to MySQL is documented in the README or anywhere in the repository. A team that starts with SQLite and later needs MySQL has no documented procedure to transfer existing articles, which makes the initial database choice more consequential than the simple knexfile.js change might appear.

## Running with Docker: three commands and a Node version conflict across three files

A Dockerfile is included at the repository root. Running Matterwiki with Docker takes three commands:

```bash
git clone http://github.com/matterwiki/matterwiki
docker build -t matterwiki .
docker run --name=matterwiki -p 5000:5000 matterwiki
```

By default the SQLite database lives inside the container. Adding -v /<path>/db:/server/db mounts the database directory on the host filesystem so data persists across container restarts or removal. Adding -v /<path>/config.js:/server/config.js supplies a custom auth_secret without requiring an image rebuild. Passing --restart=always -d runs the container as a daemon.

Reading the three Node-related files in the repository reveals a disagreement. The README's setup section states that Node version 7 or above is required. The Dockerfile specifies FROM node:6, which is below that stated minimum. The package.json engines field gives a third answer: ~0.12.0 or ^4.2.0 or ^6.5.0 as compatible ranges, none of which includes version 7. All three files give a different answer. Running docker build uses the Dockerfile's node:6 image unless you override it, while the README's stated requirement is Node 7. Testing on a Node 7 or later installation matches the README, but the Docker path as written does not.

## Topics, admin dashboard and what the JSON API exposes

Every article belongs to a topic, and topics are the primary organizing layer. A topic typically corresponds to a department or knowledge domain, and new topics are created from the admin dashboard after initial setup. Users are also managed from that dashboard. The README does not document per-user or per-topic permissions beyond the admin and regular user distinction, so finer access control is not a documented feature.

The JSON API in API.md covers the same interface the React front-end uses. An external client, such as a mobile app or a static site build pipeline, can read and write articles through that interface without the web front-end. The README points this out as an integration path but does not describe authentication flows, rate limits or API keys for external callers. Reading API.md in full is necessary before building any integration that depends on that interface.

Adding at least one topic before inviting users is a practical requirement, not just a preference. Without a topic in the system, there is no category to file new articles under, and the README does not describe a default uncategorized state.

## Jingo and Dokuwiki as alternatives with different storage models

Matterwiki's README lists four alternatives for teams that want to compare. Jingo is a Node.js wiki that stores content in Git rather than a database. Every article edit becomes a commit, which gives a full history in standard version control format and makes content portable to any tool that reads a Git repository. Matterwiki stores history in a database table, keeping everything in one place but tying the content to the database's storage and backup approach.

Dokuwiki stores articles as plain text files rather than in a relational database. No SQL layer is required, and backup is a file copy. Concurrent editing relies on file-based locking rather than database transactions, which is a different concurrency model from what Knex provides.

MediaWiki is the largest listed alternative: it powers Wikipedia, requires a PHP environment and a database server, and carries a large extension ecosystem and an active community. The README positions it as a contrast rather than a recommendation for the audience that Matterwiki targets.

Tettra, also listed, is a paid service with Slack integration and no self-hosted deployment. It operates on a different budget and infrastructure model from what Matterwiki provides.

## Conclusion

Matterwiki suits a small team that wants a minimal self-hosted wiki and can accept some instability while a new version is in progress. A team that needs production stability should wait until a stable build is available, since the README warns that some features on master may be broken. Before deploying, set auth_secret in config.js to a private value and decide between SQLite and MySQL in knexfile.js before content accumulates, because no migration path between the two is documented. Resolve the Node version discrepancy: the README requires Node 7 or above, but the Dockerfile specifies Node 6.

## FAQ

### What is Matterwiki?

Matterwiki is a self-hosted wiki for small teams built on Node.js, React and SQLite3. Articles are organized under topics, and every edit records who made it and when.

### Is Matterwiki still maintained?

The README opens with a warning that some features in the master branch may be broken while the next version is in development. The CONTRIBUTING.md at the repository root describes how to help with the work in progress.

### Does Matterwiki support MySQL?

Yes, MySQL 5.6.5 or newer is supported. Install the mysql npm package and update the connection object in knexfile.js at the application root. No data migration path from SQLite to MySQL is documented.

### How do I run Matterwiki with Docker?

Clone the repository, build the image with docker build -t matterwiki ., and start it with docker run --name=matterwiki -p 5000:5000 matterwiki. Mount -v /<path>/db:/server/db to persist the database on the host filesystem.

### What is the default port for Matterwiki?

Port 5000 is the default. Set the PORT environment variable when starting the process to use a different port.

## Sources

- [License: MIT](https://github.com/Matterwiki/Matterwiki/blob/master/LICENSE)
- [Matterwiki/Matterwiki on GitHub](https://github.com/Matterwiki/Matterwiki)
- [Project website](http://matterwiki.com)
- [README](https://github.com/Matterwiki/Matterwiki/blob/master/README.md)
- [Releases](https://github.com/Matterwiki/Matterwiki/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/matterwiki-matterwiki