MinDoc: a self-hosted documentation system for IT teams, built on Beego

What MinDoc solves and which teams it fits

MinDoc is a document management system aimed at IT teams. The README describes its origin plainly: a company IT department needed a simple way to manage and share project interface documentation, and the feature set and interface derive from kancloud. The stated uses are everyday API documentation, database dictionaries and manuals. That is a narrower brief than a general wiki. The built-in pieces are project management, user management and permission management, which the README says covers the documentation needs of most small and mid-sized teams.

The project has a lineage worth knowing before you commit. It began as SmartWiki, a PHP and Laravel system, and was rewritten in Go because PHP deployment was too complicated for ordinary users. The original author, lifei6671, handed the project to the mindoc-org GitHub organisation on 2021-03-23 and the README asks interested developers to join that organisation. The last push to the repository was on 2026-07-01, and the repository is not archived. Releases, however, are sparse: v2.1 in July 2022, v2.2-beta.1 in August 2023, and v2.2-beta.2 in January 2026. If you need a project with a predictable release cadence, that history is the thing to weigh, not the commit activity.

Who it is for: teams that want the documentation server on their own hardware, behind their own accounts, with no per-seat plan. Who it is not for: anyone who wants a managed service, or who needs the doc site to be a static export they can host on a CDN.

The Beego architecture and where the pieces live

MinDoc is a single Go binary built on the Beego framework, and the repository layout reflects a conventional Beego application. Controllers, models, routers and views are separate top-level directories. Configuration lives in conf/, with app.conf.example as the template that must be renamed to app.conf. Static assets and uploads have their own directories, and there is a database/ directory for the SQLite file when that backend is used.

The data layer is chosen at configuration time. MySQL is supported, and the README is explicit that the MySQL encoding must be utf8mb4_general_ci. SQLite is the alternative, configured by pointing the config file at a database path. The go.mod file shows the drivers: github.com/go-sql-driver/mysql and github.com/mattn/go-sqlite3, plus github.com/lib/pq for PostgreSQL, and github.com/go-ldap/ldap/v3 for directory authentication.

Two dependencies are worth flagging because they shape deployment. The SQLite driver needs CGO, so a pure static build is not the default path. The README also notes that CentOS 7 has an old GLibC and that a normally compiled binary will not run there; you must compile from source or use the musl build. The repository ships build_musl_amd64.sh and a documented musl-gcc procedure for exactly this case.

A newer piece is the MCP server. The repository has an mcp/ directory and go.mod requires github.com/mark3labs/mcp-go v0.45.0. The README documents enabling it in app.conf with enable_mcp_server and mcp_api_key, and connecting a client over streamable_http to a URL of the form http://127.0.0.1:8181/mcp/?api_key=... That makes the documentation corpus reachable from AI tooling that speaks MCP, which is an unusual feature for a documentation system of this size.

Installing MinDoc from a release, from source, or with Docker

The README gives three routes. Users without Go experience are told to download a compiled binary from the releases page. Developers are told to compile, with Go 1.23.0 or newer, supporting CGO, go mod and the time/tzdata import; the recommended line is Go 1.23.x.

The source build follows the commands in the README. The install step must run before the first start, and it reads conf/app.conf, so that file has to exist first. If conf/app.conf is missing, rename app.conf.example.

git clone https://github.com/mindoc-org/mindoc.git
go mod tidy -v
go build -ldflags "-w" -o mindoc main.go
./mindoc install
./mindoc

After the first start the README states the program initialises a super administrator account with the username admin and the password 123456, and instructs you to change the password after logging in. Do that before exposing the instance. There is also an update command for refreshing part of the database configuration on an older installation.

./mindoc update

For Docker, the README points at the project Dockerfile and at the published image registry.cn-hangzhou.aliyuncs.com/mindoc-org/mindoc. The example below is the Linux and macOS form given in the README, mounting the host conf directory into the container and publishing port 8181.

export MINDOC=/home/ubuntu/mindoc-docker
docker run -it --name=mindoc --restart=always -v "${MINDOC}/conf":"/mindoc/conf" -p 8181:8181 -e MINDOC_ENABLE_EXPORT=true -d registry.cn-hangzhou.aliyuncs.com/mindoc-org/mindoc:v2.2-beta.2

The environment variables the README lists for container startup include DB_ADAPTER (default sqlite), MYSQL_PORT_3306_TCP_ADDR, MYSQL_PORT_3306_TCP_PORT, MYSQL_INSTANCE_NAME, MYSQL_USERNAME, MYSQL_PASSWORD, HTTP_PORT and MINDOC_ENABLE_EXPORT, which defaults to false. The repository docker-compose.yml uses the MINDOC_-prefixed variants instead, including MINDOC_DB_ADAPTER, MINDOC_DB_DATABASE, MINDOC_CACHE and MINDOC_RUN_MODE. Note that the compose file pins image tag v2.1 while the README run example pins v2.2-beta.2; pick your tag deliberately rather than copying either one blind.

For a one-command setup, edit the volumes and environment nodes of docker-compose.yml, then bring it up and open the instance in a browser.

docker-compose up -d

The README says the site is then reachable at http://localhost:8181/.

Where MinDoc is the wrong tool

The release history is the first limitation. Two of the three most recent releases carry a beta label, and the gap between v2.1 in July 2022 and v2.2-beta.2 in January 2026 is over three years. A team that treats documentation infrastructure as something to upgrade on a schedule should look at that pattern and decide whether it is acceptable.

The second is deployment friction that the README admits rather than hides. The musl section exists because CentOS 7 cannot run the standard build. The SQLite backend pulls in CGO. On Windows, the README points to a separate project, mindoc-daemon, for running in the background, which means the binary alone does not give you a service on that platform. None of this is unusual for a Go application, but it does mean the "download and run" story is cleanest on a modern Linux host.

The third is scope. MinDoc is not a static site generator and the README does not document rollback of an upgrade or a documented export-and-rebuild workflow for the whole corpus; export is a toggle, MINDOC_ENABLE_EXPORT, not a migration strategy. If your requirement is versioned docs that build into a CDN-hosted site, or docs that live beside code in the same repository and are reviewed in pull requests, this is the wrong shape of tool. It is a database-backed server with a web editor, and that is a different product category.

Finally, the README notes that the original author removed his personal donation information in 2021 and that the mindoc-org organisation had published no donation information as of 2023-03-27, with a warning not to trust any that appears. If your procurement process checks project governance, read that section before you file anything.

MinDoc compared with a repository-native docs toolchain

The closest alternative in practice is a Markdown-based documentation toolchain such as MkDocs or Docusaurus, where the documentation source is a set of files in a Git repository and the output is a static site. The difference is not cosmetic. In that model, review happens in pull requests, history is the repository history, and hosting is a bucket or a CDN. There is no database, no admin account, and no server process to keep alive.

MinDoc inverts each of those. Content lives in MySQL or SQLite, editing happens through the web interface, access control is MinDoc's own user and permission system rather than the repository's collaborator model, and the running artefact is a Beego application on port 8181. The trade is real in both directions. You gain a permission model that non-developers can use, an editor that does not require a Git client, and the ability to store documents that should not sit in a source repository. You lose diff-based review, offline editing, and the ability to rebuild the site from files alone.

The MCP server is the one place where MinDoc does something a static toolchain typically does not: it exposes the document corpus to MCP-capable AI clients over streamable_http with an API key. If that integration is why you are looking at MinDoc, the static alternatives will not match it. If you do not need it, it is a feature you can leave disabled.

Licence, upgrades and what maintenance costs you

MinDoc is licensed under Apache-2.0, and the repository carries LICENSE.md. That is a permissive licence, which matters for internal deployment and for redistribution inside a company product; it is not legal advice, and if you plan to redistribute a modified binary you should read the licence text yourself.

Upgrade cost comes from two directions. The binary is a single artefact, so replacing it is easy, and the README provides ./mindoc update for refreshing part of the database configuration on an older installation. The harder part is configuration drift: the README points at conf/app.conf.example as the reference for the full set of environment variables, and the Docker Compose file and the README run example use different variable prefixes (DB_ADAPTER versus MINDOC_DB_ADAPTER) and different image tags. Any upgrade should start by diffing your conf/app.conf against the version shipped in the release you are moving to.

Operationally, budget for a database. MySQL requires the utf8mb4_general_ci encoding, and SQLite requires CGO in the build. If you run the container, the compose file mounts conf, static, views, uploads, runtime and database from the host, so a container replacement does not lose data as long as those mounts are correct. Backups are therefore a matter of backing up the database and the uploads directory, not the whole container.

Editorial conclusion

Adopt MinDoc if your team wants a self-hosted place for API docs, database dictionaries and internal manuals with project-level permissions, and you are comfortable running a Go binary, MySQL or SQLite, and a config file you edit by hand. Skip it if you need a hosted service with no server to run, or if you depend on a stable release rather than a beta: the newest release listed is v2.2-beta.2. Before committing, verify that conf/app.conf.example documents every environment variable you intend to set, confirm your MySQL encoding is utf8mb4_general_ci, and change the default admin password immediately after the first login.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mindoc-org/mindoc on GitHub
3. Project website
4. README
5. Releases