If your team's internal documentation currently lives in a shared Google Doc folder, a Confluence instance your company pays per seat, or a Notion workspace where the admin has no idea who can see what, Wiki.js was built for that situation. It is a self-hosted wiki platform (meaning you run it on your own server rather than paying a vendor for access) with a polished editor, granular permissions, and a storage model that sets it apart from most alternatives: your wiki pages can be stored in a relational database (a structured data store that organizes content in tables, the same technology behind most business software), synced to a Git repository, or both at the same time.
The project sits at 28,686 stars on GitHub and is actively maintained by Nicolas Giard and a community of contributors. The AGPL-3.0 license (a free open-source license; any modifications you distribute must also be released as open source, but using the software privately has no restrictions) means there is no per-seat charge, no feature gating, and no vendor to renegotiate a contract with.
| Fact | Value |
|---|---|
| What it is | Self-hosted wiki and documentation platform |
| Built by | Nicolas Giard and community (open-source) |
| License | AGPL-3.0 (free to use) |
| Platforms | Docker, Linux, cloud VPS |
| Requires | Node.js and PostgreSQL (or MySQL/MariaDB/SQLite); or Docker |
| Install method | Docker Compose or Linux installer |
| Verdict | Install for internal team documentation; evaluate if your team already uses Confluence or Notion |
What Wiki.js actually is
Wiki.js is a web application you run on your own server. Once installed, it gives everyone on your team a URL they log in to and a place to write, organize, and search documentation. The editor experience is closer to a modern web app than to a traditional wiki system.
The key differentiator is how Wiki.js handles storage. Most wiki tools store content in a proprietary database you can only access through the application itself. Wiki.js adds the option to sync pages to a Git repository (a version-controlled storage system, the same kind that software developers use to track code changes). When that option is turned on, every page your team writes is automatically committed to a Git repo as a plain text file. You get full change history, the ability to edit pages directly in the repository if you prefer, and a content backup that exists independently of the wiki application itself. For teams that already live in GitHub or GitLab, this is a meaningful integration.
A second storage capability is the ability to mix backends. You can have the live wiki served from a database (for fast performance) while keeping a Git mirror running in parallel, so every edit is both instantly searchable and version-controlled in your code repository.
The feature set covers the standard wiki requirements: a Markdown editor (a lightweight text formatting system where you add characters like asterisks or pound signs to indicate bold, italic, or heading formatting), a WYSIWYG editor (short for "What You See Is What You Get," an editor where text appears formatted in real time as you type, similar to Google Docs or a word processor), a code block editor for technical content, and a diagram editor for flowcharts and system diagrams. Pages can be nested in hierarchies, tagged for cross-cutting themes, and searched across the full content of the wiki.
Access control is more granular than most self-hosted wikis. Permissions are set per user group, not just per individual, and can be applied at the space, page, or asset level. You can have a public section of the wiki that anyone can read without logging in, a team section that requires authentication, and an admin section restricted to a specific group. SSO (Single Sign-On, a system that lets users log in to multiple applications using one set of credentials from a central identity provider) is supported via Google, GitHub, and LDAP. LDAP (Lightweight Directory Access Protocol) is the protocol used by corporate directory systems like Microsoft Active Directory, so organizations that manage employee logins centrally can connect Wiki.js to that system directly.
What you get after installing it
The interface is clean enough that a non-technical teammate can create and edit pages without a walkthrough. The sidebar shows the page tree, recent changes, and tags. The editor opens with a format picker so writers choose Markdown or WYSIWYG rather than being forced into one mode. Code blocks, tables, callouts, and embedded diagrams all work in the visual editor without needing to know any syntax.
Page history is built in. Every edit saves a revision, so you can view the diff between two versions (a line-by-line comparison showing what was added and removed), roll back to an earlier state, or see who made a specific change. When Git sync is enabled, this revision history also appears in your repository's commit log (the chronological record of every change saved to the repository, showing who made each change and when).
Search is full-text across all pages, and the results are fast. Wiki.js indexes page content, titles, and tags, so you can find a page by any word it contains rather than needing to remember where you filed it.
The AI agent angle is practical. Wiki.js exposes a GraphQL API (a type of web API where you describe exactly the data you want rather than getting a fixed response format) that agents can use to read, write, and update pages programmatically. If you are using Claude Code, Cowork, or a similar AI agent setup to generate documentation, research summaries, or process outputs, the API gives the agent a structured way to write those results directly into the wiki. The wiki becomes a live, machine-written knowledge base rather than a static collection of manually written pages.
Content is supported in multiple languages, and the interface itself ships in 50+ languages.
The install experience
The recommended path is Docker Compose. Docker (a tool that packages software and all its dependencies into a container you can run on any server without a complex manual setup) and Docker Compose (a configuration format for running multiple Docker containers together, useful here because Wiki.js needs both an application container and a database container) are the only requirements on the host machine.
The official documentation at js.wiki provides a working docker-compose file. You copy it, fill in a few environment variables (configuration settings you supply before the application starts, such as the database password and the public URL of your wiki), and run one command. Wiki.js starts, runs its database migrations automatically (creating the tables and structure it needs in the database), and opens a setup wizard in the browser. The wizard walks through creating the admin account, setting the site name, and configuring the first authentication method. First launch to a working wiki typically takes under 20 minutes.
The Linux installer, available for Ubuntu and other Debian-based distributions (Linux variants that share the same package management system as Debian, the most common family of Linux for servers), handles Node.js (the JavaScript runtime Wiki.js is built on) and the PostgreSQL database installation if you prefer to avoid Docker. It is more steps but gives you more control over the server configuration.
One genuine complexity: Wiki.js v3 (a significant architectural rewrite of the platform) is under active development as of mid-2026 but is not yet the stable release. The current stable version is v2. If you are installing now for production use, install v2, which is mature and well-documented. Watch the repository for the v3 release if you want the updated architecture.
Hardware requirements are modest. Wiki.js runs on a 1 GB RAM server (a basic cloud server from any major provider runs $4 to $6 per month at that spec). PostgreSQL (an open-source database; the most widely recommended option for Wiki.js) can run on the same machine for most team sizes.
Where it fits and what to compare it to
Wiki.js sits in a specific spot: it is a dedicated team wiki with a cleaner editor and more storage flexibility than most self-hosted alternatives, at a lower total cost than any hosted alternative with comparable features.
The most direct comparison is Confluence from Atlassian, which costs $5.75 per user per month at the lowest tier for the hosted version, and considerably more for self-hosted Enterprise. Confluence is deeper in the Atlassian ecosystem and integrates tightly with Jira for software teams. For teams not already in the Atlassian stack, the per-seat pricing adds up quickly and the interface carries years of accumulated complexity. Wiki.js costs nothing for the software and requires a modest server that typically runs under $10 per month.
Notion is not self-hosted at all. Every document you store in Notion lives on Notion's servers. For teams with legal, compliance, or basic competitive sensitivity reasons to keep documents in-house, Notion is a non-starter regardless of its feature quality.
Outline is another self-hosted knowledge base worth comparing directly. Outline has a stronger real-time collaborative editing experience and shipped a native MCP plugin (a connection that lets AI agents like Claude and ChatGPT read and write your docs directly) in early 2026, which gives it an edge for teams building AI agent workflows. Wiki.js has a broader editor selection (Markdown, WYSIWYG, and diagram editors), more storage backend options, and the Git sync capability that Outline lacks. If your team's primary requirement is AI agent integration with a wiki, Outline is currently ahead on that specific feature. If Git-backed content storage or editor flexibility matters more, Wiki.js is the better choice.
BookStack organizes content in a Books and Chapters hierarchy, which works well for structured technical documentation. It runs on PHP and MySQL rather than Node.js, which some teams prefer. The editor and permission model are simpler than Wiki.js, which is a feature for small teams that do not need granularity and a limitation for larger ones.
Verdict
Install Wiki.js if your team needs a self-hosted wiki and you want to avoid per-seat pricing, keep your documentation under your own control, or give your team the option to back wiki content to a Git repository.
The Git sync feature alone is worth the evaluation for any team that thinks of documentation as part of a codebase. Writing a runbook or API reference that lives in the same Git repository as the code it describes is a coherent workflow that no hosted wiki product supports. Wiki.js makes that straightforward.
The caveats are honest. The v3 rewrite means the platform is in a transitional state: install v2 for stability now. The install is not one-click but it is not a serious infrastructure project either. Docker Compose, a domain, and 20 minutes are the realistic requirements for a basic setup. SSO configuration via LDAP adds time if your organization uses Active Directory.
For teams that are paying per seat for Confluence or Notion and find themselves increasingly uncomfortable with the answer to "where are our documents stored," Wiki.js is the most practical self-hosted migration path. The interface is polished enough that you will not be asking teammates to tolerate a step backward in usability.