GROWI is an MIT-licensed, self-hostable team wiki and knowledge base built in TypeScript that lets organizations write, organize, and co-edit documentation in markdown on their own infrastructure.

What it is

GROWI is a wiki engine and documentation platform for teams, written primarily in TypeScript and React and running on Node.js with MongoDB as its datastore. It organizes content as hierarchical pages authored in markdown, so a team builds a tree of spaces, sections, and articles rather than scattering notes across flat folders. The project ships as a Docker image, supports docker-compose and an experimental Helm chart, and documents on-premise installation paths for Ubuntu Server and CentOS. Optional Redis and ElasticSearch components extend it, and a plugin ecosystem distributed under the growi-plugin keyword on npm and GitHub allows custom extensions.

The concrete problem it solves is the team that needs an internal wiki but cannot or will not hand its documentation to a hosted SaaS vendor. GROWI provides the collaboration surface — page trees, markdown editing, multi-user simultaneous editing, and enterprise authentication — inside infrastructure the organization controls. For existing users of Crowi, the project publishes a migration guide from Crowi on-premise, positioning GROWI as the successor path for that deployment style.

Key capabilities

• Hierarchical markdown pages, with a hosted demo site for evaluating the page layout before installation.
• Simultaneous editing by multiple people on the same page.
• Authentication through LDAP and Active Directory, plus OAuth providers.
• Single sign-on with SAML.
• Slack and Mattermost integration, plus IFTTT.
• Pluggable architecture; plugins discoverable on npm under the keyword growi-plugin and on GitHub under the topic growi-plugin.
• Docker-ready and Docker Compose-ready distribution, with documentation for running multiple sites from one deployment and for HTTPS termination through a Let's Encrypt proxy integration.

Who uses it and how

• Internal engineering and operations teams running a private wiki on their own servers, installed on Ubuntu Server or CentOS.
• Organizations with existing directory infrastructure that need LDAP, Active Directory, OAuth, or SAML-based SSO rather than local accounts.
• Teams that want chat-adjacent workflows, wiring page activity into Slack or Mattermost or triggering automation through IFTTT.
• Operators running several distinct wiki sites from a shared installation, documented as a multi-app admin cookbook.
• Kubernetes users who can adopt the Helm chart, noting the chart is marked experimental.

Getting started

Production startup is documented through the growilabs/growi Docker image and the docker-compose path in the admin guide. Kubernetes deployments can use the GROWI Helm chart, while bare-metal installs follow the Ubuntu Server or CentOS guides.

How it compares

The facts name no paid products that GROWI replaces, so a like-for-like commercial comparison cannot be made here. The only related tool named in the material is Crowi, for which GROWI publishes a migration guide from Crowi on-premise; apart from that lineage, GROWI stands alone in this registry.

When to use it — and when not to

A self-hoster must operate MongoDB, and optionally Redis and ElasticSearch, where full-text search requires ElasticSearch with the Japanese (kuromoji) and ICU analysis plugins installed. Development and builds additionally assume Node.js v24.x, pnpm 10.x, and Turborepo. Teams unwilling to run a database and a search cluster, or those who need only a handful of static pages, should look elsewhere; the Helm chart is explicitly experimental, so Kubernetes users should treat it as such.