# GROWI: a self-hosted markdown wiki that expects a database admin

> An MIT-licensed team wiki in TypeScript that keeps pages in MongoDB and hands full text search to ElasticSearch when you need it, with the deployment guides living outside the repository.

**growilabs/growi** — :anchor: GROWI - Team collaboration software using markdown

- Repository: https://github.com/growilabs/growi
- Website: https://growi.org
- Stars: 1,470 · Forks: 246
- Language: TypeScript
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/growilabs-growi

## A markdown wiki that outgrew the single-process model

GROWI calls itself team collaboration software using markdown, and the repository description puts an anchor emoji in front of it. The feature list is short enough to read in one pass: hierarchical pages written in markdown, simultaneous editing by several people, authentication through LDAP or Active Directory, OAuth, SAML single sign-on, and integrations with Slack, Mattermost and IFTTT.

What the feature list hides is the shape underneath. The tree is a monorepo: apps/ for the deployable pieces, packages/ for shared libraries, bin/, docs/, and a .changeset/ directory that drives the versioning of the packages that ship separately. The package.json sets the project type to module and names pnpm as the package manager, and there is a turbo.json plus pnpm-workspace.yaml at the root. That is a much larger footprint than a single wiki binary, and it is the main thing to understand before sizing the deployment.

The team behind it also maintains a developer wiki and a Slack community, and the repository carries SECURITY.md, THIRD-PARTY-NOTICES.md and a Japanese README alongside the English one. For an organisation considering it, the Japanese-first history shows up in the docs: the full text search setup assumes the kuromoji Japanese analysis plugin.

Release activity is current rather than ceremonial. v8.0.3 shipped on 2026-09-07 and v8.0.4 on 2026-09-14, and the last push to master was on 2026-09-19.

## The dependencies you need before the first page is written

The README lists the stack for development, and the required entries are not negotiable:

```yaml
Node.js v24.x
pnpm 10.x
MongoDB v6.x or v8.x
```

Turborepo is the build orchestrator, and MongoDB is where pages live. There is no file-based or embedded storage mode described anywhere in the repository, which is the first thing to accept or reject. A wiki you are happy to lose the contents of on a bad afternoon is a different tool from one holding runbooks.

The optional entries matter just as much:

```yaml
Redis 3.x
ElasticSearch 7.x or 8.x or 9.x (needed when using Full-text search)
```

Redis is listed without a stated purpose, so the docs rather than the README are where you would find out what it is for. ElasticSearch is stated as needed for full text search and nothing else, which makes it the cleanest cost lever in the whole stack. If your wiki is small enough to browse rather than search, you can leave it out and skip operating a search cluster.

One trap: the README names the Japanese kuromoji analysis plugin and the ICU analysis plugin as required for ElasticSearch, so an English-only install still has to install analysis plugins on that cluster.

## Building the app from the workspace and starting the server

The README documents three commands, in a table rather than as a copyable block, and they are worth separating out because the difference between them matters:

```bash
npm run app:build
npm run app:server
npm run start
```

In package.json the story is more precise. The build is `app:build`, which delegates to turbo and filters to the app package. The server is `app:server`, which changes into apps/app and runs its server. `start` runs the server, and a `prestart` hook runs the build first, so a single start does both.

There is also a mismatch worth flagging before you write any onboarding doc. The README says pnpm 10.x while package.json pins `pnpm@11.1.1` as the package manager, and the README's table spells the same three scripts with npm even though the scripts themselves call pnpm.

```json
"name": "growi",
"version": "8.0.5-RC.0",
"packageManager": "pnpm@11.1.1"
```

That version string is a release candidate, and it is worth knowing why the package.json carries one at all: the root package is marked private, and the published artefacts are the scoped packages in packages/.

## Full text search, inline comments and the editor in recent releases

The recent release notes are the best available description of what is actually changing, because they are written as user-visible behaviour rather than as internal refactors.

v8.0.3 added a slash command to the markdown editor. Typing `/` opens a command menu, typing filters it, and picking an entry with the keyboard or a mouse inserts a heading, a bullet or numbered or task list, a quote, a code block or a table without touching the toolbar. The notes also say it works in both the page body and the comment field and coexists with the existing `:` emoji completion and `@` mention completion, which tells you the editor already had a completion layer before this.

v8.0.4 added inline comments on page body text selections. You select text, attach a comment, and the range stays highlighted with threaded replies and mentions, a resolved marker, and highlight restoration after reloads. The one limitation stated is that inline comments are not exposed to share-link viewers. The same release added a filter panel and chips to the search page, so you can narrow by author, editor, group or tag without typing search syntax, and applied filters appear as removable chips that are reflected in the URL.

News rendering was moved to Markdown in between, with a dedicated renderer and a narrowed sanitize schema rather than the wiki renderer, because news content comes from outside. That is a small detail and a good one: it shows the sanitisation boundary being treated as something to narrow per source.

## The plugin surface and the packages that version separately

Extensibility is the feature GROWI leans on hardest. The README points at npm and at GitHub for packages tagged growi-plugin, and the repository has a .changeset/ directory plus a pluginkit package. The versioning setup is visible in the scripts: `version-subpackages` runs changeset version, updates every `@growi/*` package across the workspace and dedupes, while `release-subpackages` builds core and the pluginkit before publishing.

That split is visible in the release feed too. Alongside the app's v8.0.4 and v8.0.3 there is a `@growi/pluginkit@1.2.8` release from 2026-08-27, whose entire changelog is a dependency bump of `@growi/core` to 3.0.0. So the plugin toolkit versions on its own schedule and drags core along with it, which is the thing to watch if you build plugins rather than just install them.

The counterweight to all this flexibility is Slack and Mattermost integration through a separate slackbot-proxy app, which has its own build and server scripts. Integrations are not a plugin here, they are a second service in the compose file.

## Where the README ends and the admin guide begins

Almost nothing operational lives in the README, and the author is upfront about it. The Quick Start for Production section is a list of links: a docker-compose guide in the admin docs, a Helm chart that is labelled experimental and lives in another organisation's repository, and on-premise guides for Ubuntu Server and CentOS with a migration guide from Crowi for existing installations. Configuration points at the Admin Guide, and even the environment variables have their own page.

That is a legitimate split, since a wiki's configuration surface is large and versioned, but it means evaluating GROWI means reading docs.growi.org, not the repository. The repository itself still tells you a lot. The tree shows a devcontainer, a vitest workspace file, biome for linting, lefthook for git hooks, and a patches/ directory, which together suggest a conventional setup with CI. The tree also contains agent instruction files at the root, including AGENTS.md and CLAUDE.md, plus .cursor/ and .serena/ directories, so contributors are expected to use coding agents on this codebase.

For the Crowi import specifically, the migration guide is the page to read first. GROWI grew out of that project, and the guide is documented separately from the install guides, which tells you the data path deserves its own attention rather than being a checkbox in the install wizard.

## Conclusion

GROWI fits a team that wants an internal wiki it hosts itself, writes in markdown, and can extend with plugins, and it asks you to run two datastores well before it asks you to write any configuration. The deciding factor is ElasticSearch: without it you lose full text search, with it you inherit a cluster to version and maintain. Start with the docker-compose guide in the admin docs rather than the on-premise path, read the environment variable page before your first backup, and check the Crowi migration guide if you are moving an existing wiki, since that import path is documented separately from everything else.

## FAQ

### What databases does GROWI need to run?

MongoDB is required, at version 6.x or 8.x, and there is no storage mode that avoids it. Redis 3.x is listed as an optional dependency and ElasticSearch 7.x, 8.x or 9.x is optional but needed for full text search. The README's stated toolchain is Node.js v24.x with pnpm and Turborepo.

### Can I add my own features to GROWI with a plugin?

Yes, and the plugin toolchain ships with the project rather than being bolted on. The README points to npm and GitHub for the growi-plugin tag, and the repository versions a pluginkit package through a changesets setup alongside @growi/core, so plugin infrastructure is maintained on its own release cycle.

### How do I move an existing Crowi wiki onto GROWI?

The README links a dedicated migration guide from Crowi under the on-premise section, separate from the Ubuntu and CentOS install guides. Because GROWI grew out of Crowi, that import path is the first page to read if you already have pages to preserve.

## Sources

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

---

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