MM-Wiki: a self-hosted Go wiki for teams that want spaces, roles and LDAP without a heavy stack

What MM-Wiki actually solves for a small internal team

The problem is not writing documentation. It is giving a company or a department a place to keep documents where access can be scoped, where roles can be defined, and where the login is the same one people already use at work. MM-Wiki targets that middle ground. Its unit of organisation is the space, described in the README as a collection of documents, usually a company department or a team, with documents under different spaces kept independent of one another. A space carries its own access level, so the engineering space and the HR space do not have to share a permission model. On top of that sits a role system: the README states that the system lets you define custom roles and grant different permissions to each.

The intended user is the operator of a small internal wiki, not a public documentation site. Two features point at that. First, unified login through an external system, with the README naming LDAP as the example. Second, email notification: when it is enabled, document changes are sent to every user following that document. Both are internal-network concerns. The writing format is Markdown, with attachment upload, and the README lists full-text search across documents as a feature. If your team already writes in Markdown and you want a server rather than a folder of files, the shape of the product is recognisable.

Architecture: one Go binary, MySQL, and a separate install program

MM-Wiki is a Go application built on the Beego framework, which is visible in go.mod alongside the MySQL driver go-sql-driver/mysql, an LDAP client (go-ldap/ldap/v3), a Markdown renderer (russross/blackfriday.v2) and gomail.v2 for mail. That dependency list maps closely onto the advertised features: MySQL for storage, LDAP for external authentication, blackfriday for Markdown rendering, gomail for the notification emails. The front end is server-rendered views plus a set of jQuery-era plugins, including editor.md for the Markdown editor and zTree for tree navigation.

The deployment model is unusual in one respect: installation is a separate binary. You download a platform archive, unpack it, and go into the install directory to run an installer that serves a configuration wizard on port 8090 by default. The README notes you can pass --port=8087 to use a different port. Once the wizard has written the configuration, you stop the installer and start the real server with the config file as an argument. This split exists so that database credentials and initial setup are collected through a browser instead of a config file you edit by hand, which is friendlier for operators who are not comfortable editing configuration. It also means the installer is a second program you have to keep around, and the README does not document what happens if you run it twice against an already configured instance.

The Dockerfile shows the same application assembled differently: a first stage clones the repository, a second stage on golang:1.14.1-alpine builds it with go build, copies conf/, install/, static/, views/, logs/ and docs/ into /opt/mm-wiki, and starts the binary with --conf /opt/mm-wiki/conf/mm-wiki.conf. The image does not bundle a database; the README's Docker instructions tell you to import docs/databases/data.sql and docs/databases/table.sql first, and to uncomment the first administrative user insert statement in data.sql.

Installing MM-Wiki on Linux and reaching the setup wizard

The README's self-service path is the shortest one. Download the archive for your platform from the releases page, unpack it, and run the installer. These are the commands as the README gives them for Linux amd64, with the default port 8090.

mkdir mm_wiki
cd mm_wiki
tar -zxvf mm-wiki-linux-amd64.tar.gz
cd install
./install

At this point the installer is listening and you open http://ip:8090 in a browser to complete the configuration. The README says to add --port=8087 to ./install if you need a different port. When the wizard finishes, stop the installer with Ctrl + C, go back up one directory, and start the application itself:

cd ..
./mm-wiki --conf conf/mm-wiki.conf

On Windows the sequence is the same in spirit: unpack the archive, open the install directory, double-click install.exe, finish the wizard in the browser, close that window, then run mm-wiki.exe --conf conf/mm-wiki.conf from the program root in cmd.exe. For Docker, the README gives a DockerHub image and a local build. The DockerHub route pins an older tag:

docker run -d -p 8080:8081 -v /data/mm-wiki/conf/:/opt/mm-wiki/conf/ -v /data/mm-wiki/data:/data/mm-wiki/data/ --name mm-wiki eahom/mm-wiki:v0.1.7

Note the port mapping: the container listens on 8081 and is published on 8080. The README also shows an nginx reverse proxy configuration, with an upstream pointing at 127.0.0.1:8088 and a separate location /static served from the MM-Wiki root directory with a one-day expiry. The README does not document a rollback or upgrade procedure for the Docker path, and the data.sql import step means the database has to exist before the container is useful.

Where MM-Wiki is the wrong tool

The clearest limitation is stated by the author, not by a reviewer. The README opens by saying that the project has not had much maintenance energy in recent years, that a full rewrite of the UI and the technology stack was judged necessary before further feature work, and that the current version was therefore left where it is. The release history matches: v0.2.1 dates to 2020-09-18, v0.2.0 to 2020-08-08, v0.1.9 to 2020-04-15. The repository's last push was on 2026-04-05, so commits have continued, but the published release line has not moved in years. If your selection process requires a vendor or project with a predictable release cadence, this is not it.

A second limitation is export. The README says documents support sharing and download, and then narrows it: currently only the Markdown source file can be downloaded. There is no documented HTML, PDF or archive export. For a team that needs to hand a documentation set to an auditor or migrate out later, that is a real constraint, and the README is silent on a migration path.

Third, the search and scale story is unspecified. Full-text search is listed as a feature, but the README does not say which engine backs it or how it behaves as the document count grows. If you are evaluating MM-Wiki for a corpus of tens of thousands of pages, you are evaluating something the documentation does not describe. Finally, the stack is dated: go.mod targets go 1.12 and the Dockerfile builds on golang:1.14.1-alpine, both of which are old toolchains for a new deployment.

MM-Wiki against Confluence and against a Git-backed docs site

The README names its own reference point: the author writes that the original goal was to build the best free open source wiki in China and to make something as great as Confluence. That comparison is the useful one, because the difference is not features but weight. Confluence is a commercial product with a plugin ecosystem, a hosted option and a support contract. MM-Wiki is a single Go binary plus MySQL that you install with a browser wizard and back up like any other database-backed service. For a department that wants spaces, roles and LDAP without a licence negotiation, the trade is fewer features and no support line in exchange for a deployment you can read end to end.

The other real alternative is a Git repository of Markdown rendered by a static site generator. That approach wins on review workflow, history and portability: every change is a commit and every page is a file you already know how to move. MM-Wiki wins on the things Git does badly: per-space access levels for people who do not use Git, custom roles, attachment upload through a browser, follow-based email notification on document changes, and LDAP login so nobody creates a second account. The decision usually comes down to who the authors are. If they are engineers, a Git-backed site is less software to run. If they are not, the install wizard and the role editor are the point.

Licence, maintenance and what an upgrade actually costs

MM-Wiki is MIT licensed, and the README carries the MIT badge pointing at the LICENSE file. MIT is permissive: it allows use, modification and redistribution, including in closed internal deployments, provided the copyright notice and permission notice are preserved. That is a general description of the licence text, not legal advice for your situation; if you plan to redistribute a modified binary, read LICENSE yourself.

The practical cost is not the licence, it is the maintenance posture. The README states that the author plans a new version and invites participation, but no version, date or scope is given, and there is no published migration path from the current release line. Treat the release you install as the release you will run for a while. That has three consequences worth planning for. You are responsible for the MySQL instance and its backups, since the README's Docker instructions have you import the schema and seed data manually. You are responsible for watching the Go and Beego dependency versions in go.mod, several of which are pinned to 2019 and 2020 revisions. And you should decide up front whether the Markdown-only download is a sufficient exit route, because the README documents no other one. The upgrade story for a self-built Docker image is at least legible: the Dockerfile clones the repository and runs go build, so rebuilding picks up whatever is on master, which also means an unpinned rebuild is not reproducible.

Editorial conclusion

Adopt MM-Wiki if you need an internal document server with space-level access control, custom roles, LDAP login and email notifications, and you are willing to run MySQL and a single Go binary yourself. Do not adopt it if you need an actively developed product with a roadmap you can plan against: the releases stop at v0.2.1 (2020-09-18) and the README says the author has had little time to maintain it, with a rewrite only described as planned. Before committing, verify three things in your own environment: that the install wizard completes against your MySQL version, that your LDAP directory authenticates through the login configuration, and that the Markdown-only export path is acceptable for your backup plan.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. phachon/mm-wiki on GitHub
4. README
5. Releases