Wiki.js vs DokuWiki: which one fits your team
Choose Wiki.js when the wiki must sit inside a larger identity and governance model: several sign-in modules (Azure AD, Keycloak OpenID Connect, LDAP and Active Directory, Okta, SAML 2.0 and others), TOTP two-factor authentication, and many editors working on the same pages. Its 2.x line stores content in a database, and the Wiki.js requirements recommend PostgreSQL, with MySQL 8.0 or later, MariaDB, MS SQL and SQLite also supported. Expect to run a Node.js service, a database and a dedicated domain or subdomain, since Wiki.js cannot be mapped to a subfolder and Linux systems need at least 1 GB of RAM. Choose DokuWiki when the team is small, the hosting budget is minimal, or the wiki must run on an isolated network. It is a PHP application that keeps pages as files under a data directory by default, bundles the authplain, LDAP, Active Directory and PDO authentication plugins, and needs PHP 8.2 or later. For a very small installation, that is often the whole stack.
The decision turns on four questions. First, identity: list every sign-in source the wiki must honor and confirm which Wiki.js module or DokuWiki plugin covers each one, including group mapping for editor and reader roles. Second, backup model: Wiki.js content lives in your database, so backups must cover the database and any Git or S3 storage target you configure, while DokuWiki backups are largely a copy of its data and configuration directories. Test a restore on both before committing. Third, hosting footprint: count the services each option adds to your patching cycle, and confirm the sideloading path if the network has no internet access. Fourth, maintenance ownership: decide who applies updates. Wiki.js 3.0 remains in beta and is marked not for production use, so plan around the 2.x line, and check the Wiki.js 2 releases page for the current stable version before you scope the work.
Which wiki fits which scenario
This table maps common team situations to the wiki that fits better and the condition that decides it. Read each row against your own hosting, identity and migration constraints, since the better fit often depends on one requirement rather than overall features.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Small team on one server | DokuWiki | Plain files under a data directory need no database to run, so there are fewer moving parts to patch and back up on a single host. |
| Enterprise directory with SSO | Wiki.js | Built-in modules cover Azure AD, Okta, Keycloak OpenID Connect, generic OpenID, SAML 2.0 and LDAP or Active Directory, with TOTP two-factor sign-in. DokuWiki's bundled authad and authldap plugins cover directory logins, but SSO federation beyond them needs confirmation. |
| Air-gapped network | Depends on the stack you can keep current | Wiki.js supports sideloading files for environments without internet access, but it needs Node.js and a database. DokuWiki needs only PHP and a web server. Confirm that your offline update process can carry either runtime and its dependencies. |
| Wiki content kept in Git | Wiki.js | Wiki.js ships a Git storage module that synchronizes content in both directions. DokuWiki stores pages as files in its data directory, so any Git workflow would be a separate process you must design and verify. |
| Team expects to migrate later | Wiki.js | A database-backed wiki with Git and object storage modules gives more exit paths. Confirm export formats and page history fidelity with each tool before committing, since both depend on the content you hold. |
| Dedicated domain or subfolder hosting | Confirm before choosing | Wiki.js requires a dedicated domain or subdomain and cannot be mapped to a subfolder. If your site must live under an existing path, DokuWiki is the one to test first. |
| Limited hosting with PHP only | DokuWiki | DokuWiki's composer.json requires PHP 8.2 or later and no database, which suits hosts that already run PHP. Wiki.js needs Node.js and, for production, PostgreSQL recommended. |
| Memory-constrained Linux host | Confirm before choosing | Wiki.js needs at least 1 GB of RAM on Linux. Measure your DokuWiki and Wiki.js footprints under expected page counts before deciding on a small virtual machine. |
How each wiki stores pages and runs
Wiki.js and DokuWiki solve the same problem with different parts. Wiki.js is a Node.js application that keeps page data in a database, with optional storage modules for Git or object storage, while DokuWiki is a PHP application that writes pages as files and needs no database by default. The cards below cover what those choices mean for backups, hosting and runtime versions.
Wiki.js as a database-backed Node.js app
Wiki.js runs as a Node.js application and stores page content in a relational database. The 2.x line recommends PostgreSQL 9.5 or later, and also supports MySQL 8.0 or later, MariaDB, MS SQL and SQLite. Backups therefore cover the database as well as any uploaded assets, and the database engine becomes a platform you must patch, monitor and restore. Confirm which database your team already operates before you choose the wiki.
DokuWiki as a flat-file PHP app
DokuWiki is a PHP application whose default configuration keeps all content as files under a data directory rather than in a database. There is no database server to install, patch or back up separately. Backing up DokuWiki means copying the data directory consistently with the web server's configuration, and restoring it is largely a file operation. Check that your web host and PHP setup can run the current PHP version before you commit.
Optional storage modules in Wiki.js
Wiki.js can add storage modules for Git, AWS S3 and DigitalOcean Spaces, and some modules, such as Git, synchronize content in both directions. A Git module can give you a versioned copy of page content outside the database, but it does not replace database backups. Test how conflicts are resolved and who may edit content through the repository before you rely on a sync path. Storage modules are an add-on, so they add configuration and an operating surface that DokuWiki does not have.
Dedicated domain and host requirements
Wiki.js requires a dedicated domain or subdomain and cannot be mounted on a subfolder of an existing site. It also needs at least 1 GB of RAM on Linux systems. DokuWiki is typically installed inside an existing PHP-capable web server, so it can share a host with other applications. If your team wants the wiki at a path like /docs on an existing intranet, this difference alone may decide the question.
Running without internet access
Wiki.js runs wherever Node.js is supported, including Linux, Windows, Docker and Kubernetes, and it supports sideloading files for environments without internet access. DokuWiki is a PHP application with bundled plugins and its own documentation on dokuwiki.org, so an offline install depends on copying the release and any extensions you need into the environment. In an air-gapped network, list every runtime dependency, including the database engine, and confirm each one can be mirrored and patched inside the enclave.
Patch cadence and runtime upgrades
Each stack carries its own upgrade path. Wiki.js 2.x is maintained in its own repository, with v2.5.316 published on October 2, 2026, while 3.0 remains in beta and not for production use. DokuWiki's latest release, 2026-07-14 "Mort", received hotfix 2026-07-14c on September 2, 2026, and a security hotfix on August 11, 2026. Ask each project which release line receives security fixes and how long, then plan the database and runtime upgrades alongside the application.
Wiki.js vs DokuWiki feature by feature
This table compares Wiki.js and DokuWiki on license, runtime, storage, databases, authentication, two-factor support, storage modules, bundled admin tools and version lines. Read each row as a check on your own requirements, and treat any row marked for confirmation as a question to put to the project or to your own test installation before you decide.
| Capability | Wiki.js | DokuWiki |
|---|---|---|
| License | AGPL-3.0 | GPL-2.0, per the repository license metadata |
| Language and runtime | Node.js, runs on Linux, macOS, Windows, Docker and Kubernetes | PHP, composer.json requires PHP 8.2 or later |
| Storage model | Content held in a database, with Git, AWS S3 and DigitalOcean Spaces storage modules available | Flat files under a data directory (savedir ./data) by default, no database required |
| Database options | PostgreSQL recommended (9.5 or later), plus MySQL 8.0 or later, MariaDB, MS SQL and SQLite | No database for default setup, authpdo plugin for SQL-backed user lookups |
| Authentication modules | Azure AD, GitHub, Google, Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, Okta and SAML 2.0 | authplain (default), authldap, authad for Active Directory and authpdo for SQL databases |
| Two-factor support | TOTP two-factor authentication | Confirm 2FA options and plugins for your DokuWiki release on dokuwiki.org before relying on them |
| Storage modules and sync | Git synchronizes content in both directions, plus S3 and DigitalOcean Spaces | Backup by copying the data directory; confirm any external sync options with the project |
| Bundled access control and admin plugins | Permissions managed inside the wiki; confirm the granularity you need against the current documentation | acl, user manager, extension manager, config manager, revert and log viewer plugins bundled |
| Remote API | Confirm API coverage and authentication for your version | Remote API bundled in the repository |
| Version lines | 2.x stable (v2.5.316 on October 2, 2026); 3.0 in beta and marked not for production use | Dated releases, for example 2026-07-14 "Mort" with hotfix 2026-07-14c on September 2, 2026 |
Licensing and paid options for each wiki
Wiki.js is licensed under AGPL-3.0, which applies to the code you run and to modified versions you make available to users, including over a network. For production, the stable line is the 2.x series, which lives in the requarks/wiki-v2 repository. The most recent release in the supplied facts is v2.5.316, published on October 2, 2026. The main requarks/wiki repository holds the 3.0 code, and its README marks that work as beta and not for production use, so any plan that depends on 3.0 features should wait for a stable release.
- License obligations: AGPL-3.0 generally requires you to offer the source of modifications to users who interact with a modified instance over a network. Ask counsel how this applies to internal-only deployments and to any custom authentication code you write.
- Stable release line: Plan against 2.x and follow the wiki-v2 release page for patches, since the stable line is where production fixes are published.
- Beta boundary: Treat the 3.0 code in the main repository as a preview. Do not set a production cutover date on it until the project marks it stable.
- Paid options: The supplied facts do not confirm a paid edition, a commercial support contract or vendor-hosted Wiki.js. Confirm these with the maintainers or a services provider before assuming any of them exist.
Before you commit, confirm with counsel that the AGPL-3.0 terms fit your deployment model and check that the 2.x release cadence matches your internal patch window.
DokuWiki is licensed under GPL-2.0, according to the license metadata of its GitHub repository, whose README credits Andreas Gohr and the DokuWiki community. The release described in the supplied facts is 2026-07-14 "Mort", published on July 14, 2026, followed by hotfix 2026-07-14c on September 2, 2026. Because DokuWiki is a community project, its release history and hotfix notes are the main maintenance signals you can verify yourself.
- Security hotfix: Hotfix 2026-07-14b, published on August 11, 2026, fixed a security issue according to its release notes. Any instance still on the base Mort release should move to the hotfix line, and the 2026-07-14c hotfix should be reviewed as well. Check the DokuWiki releases page for the current state.
- GPL-2.0 obligations: Copyleft terms apply when you distribute modified copies. Internal use without distribution generally does not trigger a source release, but confirm this with counsel for your own case.
- Version recording: Record the exact release string in your change records so auditors and operators can match a running instance to its release notes.
- Paid options: The supplied facts do not confirm paid support, commercial hosting or a vendor edition for DokuWiki. Ask the DokuWiki community and any third party offering services what they provide, on what terms and for how long.
Before you deploy, confirm which hotfix level your installation package includes and who will apply future security releases.
Neither project charges a license fee for use, so the paid items are services: installation, configuration, hardening, backup testing, upgrades, documentation and ongoing support. The supplied facts do not confirm paid support or hosting for either wiki, so you should ask the maintainers, community channels or any services provider to state what they offer in writing. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing, and ongoing support is available as a retainer. DeployOpen is not an official partner or reseller of either project.
- Who is paid for what: The license costs nothing, so the quote covers staff time, service delivery and infrastructure. Separate these lines so you can see what recurs.
- One-time versus recurring: Initial setup, authentication integration and migration are typically one-time. Security hotfixes, minor upgrades, backup restore tests and access reviews recur.
- Quote contents: Ask for written deliverables covering installation, authentication configuration, backup and restore verification, upgrade procedure and handover documentation.
- Cost drivers: The number of identity integrations, the volume of content to migrate, and the number of environments such as test and production each raise effort.
- Hosting questions: Ask whether managed hosting exists for either wiki, where data would reside, and who holds the backup keys.
Before you sign, ask each provider for the written scope and confirm which recurring tasks are included in the first year and which are billed separately.
What drives the running cost of each wiki
The running cost of a Wiki.js or DokuWiki installation is mostly the labor around the software, not the software itself, since both are free to download under their licenses. For Wiki.js, the recurring cost centers on a Node.js runtime, a database server and a dedicated domain or subdomain, because Wiki.js cannot be mapped to a subfolder and Linux systems need at least 1 GB of RAM according to the Wiki.js requirements. For DokuWiki, the database server disappears from the picture, because its default configuration stores everything under a data directory (savedir in conf/dokuwiki.php), so the server footprint is a PHP runtime and a web server. Ask any quote to separate hosting for the application from hosting for the database, and to state whether backups of the database are included.
The one-time setup cost is where the two platforms diverge most. Wiki.js needs identity integration against its built-in modules, including Azure AD, Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, Okta and SAML 2.0, plus TOTP two-factor authentication, and that configuration is paid once but must be tested again after each identity change. DokuWiki's bundled authplain, authldap, authad and authpdo plugins cover similar directory needs, but they are configured through plugin settings that you should verify against your directory before go-live. Ask the vendor or integrator to price identity work as a separate line, with a named test plan and the directory versions they will test against.
The recurring cost that most often surprises teams is maintenance of upgrades and extensions. Wiki.js 2.x is on a maintained stable line, so upgrades follow the release cadence in its releases page, and you should plan a test cycle for each one. DokuWiki's extension manager and bundled plugins reduce some work, but any third-party plugin you add becomes a recurring item to review after every core update. Backup tooling also recurs: Wiki.js backups must capture the database and any Git or S3 storage target, while DokuWiki backups are a file copy of the data directory, which is simpler but grows with content. Ask for the backup schedule, restore test frequency and who owns plugin reviews, and confirm whether those tasks sit inside a fixed-scope engagement or a retainer.
Moving content from one wiki to the other
This sequence moves pages, users, access rules and attachments from one wiki to the other without losing track of what changed, and it ends with a documented cutover that your team can verify.
Inventory pages, users and attachments
Before touching either system, the wiki owner and an administrator list every space or namespace, page count, attachment type, user account and group, and any external links that point into the wiki. Export a read-only snapshot of the source wiki so the inventory matches what exists today. The step is complete when the team can state how many pages, files and accounts are in scope and has signed off the list. Confirm the exact export options with the vendor of your current version, since the supplied facts do not describe export tooling for either product.
Decide the target storage model
Choose whether the destination keeps content in a database or in flat files. Wiki.js 2.x stores content in a supported database such as PostgreSQL, which is recommended, or in a storage module such as Git. DokuWiki keeps pages as files under a data directory by default. Make this decision with the backup model in mind, because the destination determines what you back up and how you restore it. The output is a written storage decision that names the database or file path, the backup owner and the restore test you will run.
Map namespaces and paths to the new structure
Build a mapping table that links each source namespace or path to its destination location. Wiki.js requires a dedicated domain or subdomain and organizes pages by path, while DokuWiki uses namespaces that map to directories. Decide where top-level namespaces will sit, how renamed pages will be handled, and which internal links need rewriting. The check is a mapping sheet with one row per source space, reviewed by the content owners, that shows every destination path and flags any collisions before import begins.
Rebuild identity and access rules
Recreate sign-in and permissions in the destination rather than copying them blindly. On the Wiki.js side, configure the authentication module your directory uses, such as LDAP and Active Directory, SAML 2.0 or OpenID Connect, and set TOTP for accounts that need it. On the DokuWiki side, decide between the default plain authentication, LDAP, Active Directory through authad, or a SQL-backed module through authpdo, then set access control lists per namespace. Confirm that group membership maps to the same effective rights, and test with at least one account per role. The output is a permissions matrix that the owners have approved.
Migrate content, attachments and history
Import pages and attachments into the destination using the mapping table, then rewrite internal links and check media references. Expect that plain page text and attachments transfer more reliably than revision history, and that formatting, plugin-specific syntax and macros usually need rebuilding by hand. Page history and permissions require manual checking after import, because revisions may arrive as a single version or may not carry authorship. The step is complete when a sample of pages from every namespace has been compared side by side with the source, and the list of items that did not transfer cleanly is recorded.
Verify rebuilt content and access
Run a structured review before users see the new wiki. Reviewers open a defined sample of pages, search for known terms, confirm that attachments open, and sign in with test accounts to confirm that each role sees only the spaces it should. Log any mismatches in a defect list with an owner for each item. The output is a signed verification record showing the sample size, the defects found, and the fixes that were applied and retested.
Run both wikis in parallel
Keep the source wiki available in read-only mode or as a fallback while users work in the destination for a period agreed in your project plan. During this window, record edits made in each system so that changes can be carried across. The team should confirm backups for both systems, including a tested restore of the destination. The check is a daily reconciliation log that shows no unexplained differences in page counts, access rules or reported errors.
Cut over and retire the source
Switch users, bookmarks and links to the destination, redirect or document the old addresses, and set the source to read-only before final archival. Keep an exported copy of the source under the same backup policy you use for production. The step is complete when the old wiki no longer accepts edits, the redirect or link plan is published, and the owner has signed off that the archive is restorable.
Where Wiki.js and DokuWiki projects usually run long
On the Wiki.js side, the longest stretch is usually the identity provider configuration, followed by the database choice and the 3.0 beta decision. Wiki.js authenticates through modules such as Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, Okta and SAML 2.0, and each one needs redirect URIs, claim mappings and group handling agreed with the identity owners before a test sign-in means anything. Plan for the dedicated domain or subdomain requirement early, because Wiki.js cannot be mapped to a subfolder and DNS, certificates and reverse proxy routing all depend on that name. Decide on PostgreSQL, which the requirements documentation recommends, or on another supported database, and confirm the pg_trgm extension if you want the PostgreSQL search module. Settle the 3.0 question in writing: the main repository marks 3.0 as beta and not for production use, so a production build should target the stable 2.x line.
On the DokuWiki side, the effort sits in access control rules across namespaces, the plugin set and the data directory backup routine. DokuWiki stores content as files under the data directory rather than in a database, so the backup design is a file backup design, and the team must confirm how that directory is captured consistently and restored in a test. Access control is granted per namespace through the bundled acl plugin, so the client team needs to supply the directory structure, the group names and an owner for each namespace before anyone writes a rule. Choose the authentication plugin deliberately (authplain, authldap, authad or authpdo), and document which extra plugins are enabled and why. Test users from each group should be part of the acceptance run.
The client team must supply the information that drives both projects: the directory structure, the identity owners who approve claim mappings and group membership, named test users for each role, and a decision on who maintains the platform after go-live. DeployOpen can take on scoping, configuration, hardening, backup and restore testing and documentation under a written scope, with deliverables and timelines agreed before work starts. Ask any quote to separate the identity integration, the access model and the backup routine as line items, so you can see which parts recur and which are one-time. Confirm current versions and release status with each vendor before the scope is signed.
Wiki.js vs DokuWiki questions buyers ask
What drives the cost of running Wiki.js versus DokuWiki?
Most of the cost comes from people, not licenses, because both are free open-source software with no paid edition covered by the supplied facts. For Wiki.js, the main drivers are the database you operate (PostgreSQL is recommended), the Node.js runtime, a dedicated domain or subdomain, and the identity integration you configure. For DokuWiki, the drivers are much lighter: a PHP web server and a data directory that you back up. Recurring costs are patching, backups, plugin review and staff time. One-time costs are installation, theming, authentication setup and migration of existing pages. Ask any implementation partner for a quote that separates the one-time build from the recurring operations work, and that names who maintains the server, the database and the upgrade cycle.
Can a small team run Wiki.js or DokuWiki without outside help?
A small team with one or two people who manage Linux servers can usually run DokuWiki without outside help, because its default setup stores everything in files and needs only a PHP-capable web server. Wiki.js is also manageable in-house, but it asks for more: a database, a Node.js service, a dedicated domain and, for enterprise sign-in, an identity provider integration. The work that most often needs outside help is the first SSO configuration, the database hardening and the backup and restore test. Whether you need help depends on your team's skills in those areas and on whether a second person can cover the system during absences. Confirm the staffing model before you pick a platform.
How long does setup usually take, and what does it depend on?
Setup time depends on scope, not on a fixed figure this page can supply. For DokuWiki, the core install is small, so most of the time goes into content structure, access control rules, plugin choices and any LDAP or Active Directory connection. For Wiki.js, the time grows with the database setup, the authentication modules you enable (for example SAML 2.0, OpenID Connect or LDAP), the storage module you choose and the content migration. Other factors include how many pages you migrate, whether the source wiki exports cleanly, and how many approval steps your change process requires. Ask for a written timeline in the scope document that lists each integration as a separate deliverable.
Can DokuWiki serve an air-gapped network?
Yes, DokuWiki is a practical candidate for an air-gapped network because its default configuration keeps all content in files under a data directory rather than in a database, and it has no required external service. Before you rely on that, confirm three points in your own environment: that every PHP dependency and plugin you need is staged inside the enclave, that you have a process for applying the hotfixes, such as the 2026-07-14b security fix published on August 11, 2026, and that your media and backup transfers follow your data handling rules. Wiki.js can also run offline, since its documentation describes sideloading files for environments without internet access, but it needs more components to stage.
Is Wiki.js 3.0 ready for production?
No, not based on the supplied facts. The main requarks/wiki repository holds Wiki.js 3.0, and its README marks it as beta and not for production use. The stable line is the 2.x series in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. If your team wants Wiki.js for a production knowledge base, plan on the 2.x line and check the release page before each upgrade. Ask your implementation partner how they would handle a future move to 3.0, including content and configuration export, and do not treat the beta as a planning baseline for a go-live date.
What does the work need from identity and infrastructure teams?
Identity teams own the sign-in design, and infrastructure teams own the hosting, network paths and backups. For Wiki.js, identity work usually means choosing one of its authentication modules, such as SAML 2.0, OpenID Connect, LDAP and Active Directory, Okta or Azure AD, and agreeing on group mapping, TOTP policy and how accounts are deprovisioned. For DokuWiki, the bundled authldap and authad plugins and the authpdo option need the same kind of directory decisions. Infrastructure teams need to provide a dedicated hostname for Wiki.js, a database or storage location, TLS certificates, the backup target and monitoring. Request a responsibility matrix in the statement of work so each team can see its tasks before work starts.
What should I ask for in a quote for either platform?
Ask for a fixed scope that lists each deliverable in writing, because DeployOpen works mainly on fixed-scope engagements where scope, deliverables and timelines are agreed before work starts. Good quotes separate the installation, the authentication configuration, the content migration, the backup and restore test, the documentation and the handover. Ask which items are one-time and which recur, such as patching, upgrades and support, and whether those are offered as a retainer. Confirm which versions are in scope, how the supplied release facts will be used at the time of build, and who signs off acceptance. DeployOpen does not publish a price list, so the quote is the only place to find its numbers.
How DeployOpen helps choose and implement a wiki
DeployOpen helps teams decide between Wiki.js and DokuWiki against their own storage, authentication and hosting rules, then plans and implements the chosen platform inside the client's infrastructure, including air-gapped networks. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Written scope records which wiki platform is chosen and why it fits your environment.
- Scope lists the authentication modules, such as LDAP or SAML 2.0, that your users will sign in with.
- Scope states where the wiki runs, whether on a dedicated domain, containers or air-gapped hosts.
How we build
- Installation covers the database choice for Wiki.js, or the data directory layout for DokuWiki.
- Build includes configuring sign-in, access rights and any storage module such as Git or S3.
- Testing checks backup and restore paths before users are onboarded to the new wiki.
How we hand over
- Documentation covers installation steps, configuration keys, backup routines and upgrade procedures.
- Handover includes a walkthrough of editing, page structure and permission management for administrators.
- Deliverables list the versions deployed and the steps needed to move to a later release.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover patching of the wiki platform and its database or runtime dependencies.
- Ask for the support scope, response expectations and upgrade responsibilities in your written quote.
