Confluence vs Wiki.js: when a Git-synced Markdown wiki fits a Confluence team
Wiki.js fits an engineering team when Git sync and self-hosting matter more than Confluence's rich structure. Its Git storage module synchronizes content in both directions, so pages can live as Markdown in a repository and be reviewed like code. Confluence fits when macros, Marketplace apps and deep space hierarchies carry the team's documentation workflow. Most teams sit somewhere between those two poles, so the decision should be made against specific requirements rather than general preference.
Four questions decide it. First, does the team want documentation changes to go through the same pull request process as code, or do editors work directly in a browser? Second, which Confluence features are load-bearing today: macros, page templates, Marketplace apps, or permission schemes that a Markdown wiki does not replace? Third, which identity provider will sign people in: Azure AD, Okta, Keycloak, LDAP or SAML 2.0 are all available as Wiki.js authentication modules, but each needs its own configuration and testing. Fourth, who will run the server, apply upgrades and restore backups? Wiki.js requires a dedicated domain or subdomain and cannot be mapped to a subfolder, so plan that DNS and TLS work before any content moves.
Confirm the version before you plan. The stable line is 2.x, which is the release line to deploy. The 3.0 line is in beta and its README says it is not for production use, so a production plan should not depend on it. Ask your implementation partner or your own team to map each Confluence feature in use to a Wiki.js equivalent or a documented gap, and to test your identity provider integration in a staging environment before cutover.
Which option fits which team
This table maps common team scenarios to the better fit between Confluence and Wiki.js, with the supplied fact behind each judgment. Read it against your own constraints: a row that matches your situation points to the option whose strengths or gaps decide the outcome.
| Scenario | Better fit | Reason |
|---|---|---|
| Engineering docs kept beside code | Wiki.js | Git storage syncs content in both directions, so Markdown pages can live in a repository next to the code they describe. |
| Teams relying on Confluence macros and Marketplace apps | Confluence | Wiki.js is a Markdown wiki and does not replace macros or Marketplace apps, so confirm each app needed has a replacement before choosing it. |
| Teams needing Keycloak or Okta sign-in | Wiki.js | Wiki.js ships Keycloak OpenID Connect and Okta authentication modules, plus SAML 2.0 and LDAP, with TOTP two-factor authentication. |
| Organizations that must keep content on their own servers | Wiki.js | Wiki.js runs on Linux, Docker or Kubernetes and supports sideloading files for environments without internet access. Confirm the offline update path for your network. |
| Teams needing a production wiki on the current release line | Wiki.js 2.x | Use the stable 2.x line. The 3.0 code in the main repository is marked beta and not for production use, so plan upgrades when a stable 3.0 is released. |
| Teams planning a Confluence Cloud or Data Center exit | Either, after a pilot | Both options need a content migration plan. Test a representative space in each tool and confirm how macros and attachments come across before committing. |
| Teams that need a fixed space and permission model | Confluence | Confluence spaces and page-level permissions map to structures Wiki.js does not reproduce in the same way. Verify your permission model against each platform. |
What a Markdown wiki does not replace
Business users usually care about the pages they build every day: status reports, meeting notes, team home pages, templates and approval layouts. Many of these depend on Confluence macros such as table of contents, status labels, Jira issue lists, page properties reports and page layouts that have no direct equivalent in a Markdown wiki. Wiki.js edits pages in Markdown and its editors, so layout-heavy pages will need to be rebuilt or simplified.
- Macros: Inventory which macros appear in high-traffic spaces, because each one needs a Markdown pattern, a Wiki.js feature or a manual replacement.
- Page layouts and columns: Check whether teams rely on multi-column layouts or templates that enforce a structure.
- Marketplace apps: List every installed app and the features users depend on, since Wiki.js has no Marketplace equivalent for Confluence add-ons.
- Jira links and dashboards: Confirm which live Jira views or issue lists would need an integration or a static replacement.
- Permissions and review workflows: Confirm whether teams rely on page restrictions or approval steps that a Markdown wiki may handle differently.
Ask each team to name its five most-used pages and the features those pages use, then confirm any plugin replacement in your own environment before you commit to a target.",
Engineers often want architecture notes, runbooks and API references to live next to the code they describe. Wiki.js can synchronize content with a Git repository in both directions through its Git storage module, so pages can be reviewed through the same workflow as code. This suits technical documentation well, but the Git sync does not carry over everything a Confluence space holds, such as comments, Marketplace app data or macro output.
- Two-way Git sync: Confirm the branch, folder layout and conflict handling your team expects, since Wiki.js storage behavior determines how edits flow back.
- Repository access: Decide which repositories hold documentation and who can merge changes to them.
- Non-Markdown content: Identify diagrams, embedded files and exported reports that need a separate storage path.
- Comments and discussion: Check whether reviewers rely on inline page comments that do not map to repository history.
- Search and indexing: Confirm that search covers the repositories and storage modules you choose.
Before migrating engineering content, test one repository end to end, including a pull request that changes a page and a page edited in the browser, and confirm the result in your own Wiki.js setup.
The decision should rest on an inventory, not on a list of features. A plugin inventory records every Confluence macro in use, every Marketplace app installed, the owner of each, and the business process that depends on it. Without this record, teams often discover a missing feature after cutover, when a status report or an approval step stops working.
- Source data: Export or query the installed apps and the macro usage per space from your Confluence administration views.
- Ownership: Name an owner for each app and macro, and record whether it is still used.
- Replacement status: Mark each item as replaced by a Wiki.js feature, replaced by an external service, rebuilt manually or retired.
- Dependencies: Note which integrations, such as Jira or single sign-on, each replacement needs.
- Verification: Confirm each replacement with the vendor or your own test environment, since plugin equivalents change over time.
Keep the inventory with the migration plan so that auditors and business owners can see which functions were retained, changed or removed.
A Markdown wiki is a good fit when most pages are text, code and simple tables, and when the team accepts a different editing model. It is a weaker fit when Confluence is the place where business processes run, because macros and apps carry logic that a documentation tool does not hold. The checklist below helps decide before any content moves.
- Usage weight: Count how many spaces rely on macros or apps, not just how many pages exist.
- Editor skills: Confirm that authors can work in Markdown, or budget for training and templates.
- Business-critical pages: Keep pages that drive approvals or reporting in a tool that supports them, or rebuild them with care.
- Hybrid option: Consider running Wiki.js for engineering docs while a broader wiki such as XWiki covers business spaces.
- Exit path: Record how content can be exported later, so the choice does not become a new lock-in.
Review the inventory and checklist together with the business owners, and confirm each replacement in your environment before you set a cutover date.
Where the content and identity data live with each option
Confluence keeps content and user accounts inside Atlassian's cloud or in a Data Center deployment you operate, while Wiki.js runs on infrastructure you choose. The cards below cover where pages are stored, what Wiki.js needs to run, how it signs users in through your identity provider, and how it works without internet access.
Where pages and accounts sit
A Confluence Cloud site keeps page content and user records in Atlassian's hosting, and a Data Center deployment keeps them on servers you run. A self-hosted Wiki.js keeps pages, users and the database on infrastructure your organization controls, so the question shifts to who administers that stack. Ask Atlassian which region holds your site, and decide which team owns backups, patching and database access for Wiki.js.
Dedicated domain requirement
Wiki.js requires a dedicated domain or subdomain and cannot be mapped to a subfolder of an existing website. Plan the DNS record, the TLS certificate and the reverse proxy before installation, since the wiki cannot share a path with your intranet or public site. Confluence sites are reached through an Atlassian-managed or Data Center hostname, so this change affects links, bookmarks and any embedded pages that point to the old address.
Host sizing and runtime options
On Linux, Wiki.js needs at least 1 GB of RAM, which is a floor for a small instance rather than a sizing plan for a large organization. It runs wherever Node.js is supported, and the project's documentation lists Docker and Kubernetes as deployment targets. Confirm the database choice and its backup schedule with your platform team, because the wiki's content is only as recoverable as the database behind it.
Sideloading for offline networks
Wiki.js supports sideloading files for environments without internet access, which matters for disconnected networks and regulated enclaves. Confluence Cloud depends on Atlassian's hosted service, and Data Center depends on the license and update channel you maintain. Confirm with your security team how offline packages, modules and updates reach the server, and who signs off on each transfer.
Identity through your own IdP
Wiki.js authentication modules include Azure AD, Okta, Keycloak OpenID Connect, LDAP and Active Directory, and SAML 2.0, with TOTP two-factor authentication. Connecting the wiki to your own identity provider keeps account lifecycle and group membership under your existing controls, but you must map groups to Wiki.js permissions yourself. Test deprovisioning, since a removed employee should lose wiki access through the IdP without manual cleanup.
Git and object storage sync
Wiki.js storage modules include Git and AWS S3 or DigitalOcean Spaces, and some modules such as Git synchronize content in both directions. This means a page edited in the wiki can reach a repository, and a repository change can reach the wiki, so the repository becomes a second place where content and its history live. Decide which copy is authoritative, who may push to the repository, and how credentials for that sync are stored and rotated.
How Wiki.js storage, database and search choices shape operations
The database choice sets your operating burden more than any feature on the page. Wiki.js 2.x recommends PostgreSQL 9.5 or later, and also runs on MySQL 8.0 or later, MariaDB, MS SQL and SQLite. Most teams will land on PostgreSQL because it is the path the project documents most fully, but the decision should follow what your database team already patches, backs up and monitors. If you choose PostgreSQL, the built-in search module needs the pg_trgm extension, so confirm your DBA can install it and that your managed database service allows it. Check the Wiki.js requirements documentation for the current list before you commit to a version, since the search behavior depends on it.
Storage modules change what a restore means. The Git module synchronizes content in both directions, so a repository can become a second copy of your pages, and the AWS S3 and DigitalOcean Spaces modules store page content in a bucket. Either way, the database no longer holds the only copy, and recovery plans must cover the database, the repository or bucket, and any sideloaded files together. Decide which system is the source of truth for each page before go-live. If Git is the source, an edit made directly in the web interface and a commit pushed from an editor can conflict, so set a rule for who edits where. Ask your engineers to test a full restore into a clean environment, not just a database dump, and record how long it takes.
How AGPL-3.0 and the 2.x and 3.0 lines affect the decision
Three questions shape a Wiki.js decision before any feature comparison: which license terms apply to your deployment, which release line you run, and how Confluence licensing compares. The cards below cover each one and name what to confirm with counsel, Atlassian and your own engineering team.
AGPL-3.0 and network use
Wiki.js is licensed under AGPL-3.0. Unlike licenses that only trigger obligations on distribution, AGPL-3.0 is written to reach software that users interact with over a network. If your organization modifies Wiki.js and makes the modified copy available to employees, partners or customers through a browser, the source code of those modifications may need to be offered to those users. Ask counsel whether internal-only use, contractor access and any customization you plan fall under these terms.
Stable 2.x line for production
The stable line is the 2.x series in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. Plan deployments, patching and upgrades against this line. Confirm with the maintainers which 2.x release your team should pin, and check the release notes before each upgrade, since the project is maintained by a small group of contributors.
Wiki.js 3.0 is not for production
The main requarks/wiki repository holds Wiki.js 3.0, and its README marks the release as beta and not for production use. Do not build a company wiki on it, and do not plan a migration around its feature set or schedule without a current statement from the project. Treat any 3.0 pilot as a test environment, and reassess when the project changes that status in writing.
Confluence licensing by edition and deployment
Confluence is sold as a subscription, and the price and terms depend on the edition and deployment model you choose, such as Cloud or Data Center. Atlassian has announced changes to Data Center sales and end-of-life dates, so your current contract and the vendor's published terms determine what you pay and until when. Confirm current terms directly with Atlassian before comparing totals with a self-hosted Wiki.js run.
Self-hosting responsibilities under the license
A self-hosted Wiki.js moves patching, backups, TLS, identity configuration and incident response to your team or your implementation partner. Under AGPL-3.0 you also carry the license obligations that come with running and changing the code. Ask whether your legal team has reviewed the license for your intended use before the project is scoped, and record that decision in the project file.
What moving Confluence content into Wiki.js involves
The sequence turns a Confluence estate into a Wiki.js instance with clear ownership of what moves, what stays archived, and how sign-in and Git sync behave before the team switches over. Each step ends with a check that someone in your organization can sign off.
Inventory spaces, macros and apps
List every Confluence space, its owner, page count, attachment volume, and the macros and Marketplace apps that pages depend on, such as Jira issue embeds, page properties, or diagram plugins. Confluence administrators can produce much of this list from the site admin tools, but space owners must confirm which content is still in use. The step is done when each space has a named owner and a status of move, archive, or retire, and when every macro in active use has a noted Wiki.js equivalent or a documented gap.
Decide what becomes Markdown
Agree with content owners which spaces become Markdown pages in Wiki.js and which stay in Confluence for a fixed period or move to a read-only archive. Pages that rely on Confluence macros, dynamic tables, or app-specific content usually need rework or archiving, while plain procedural documentation converts more cleanly. Compliance, legal, and records owners must confirm retention requirements for archived content before anything is deleted. The step closes with a signed-off list of spaces and a retention decision for each.
Export from Confluence
Run exports from Confluence for the spaces selected in the previous step. Atlassian's support documentation describes space export as PDF, CSV, HTML, or XML, and site backups from the backup manager. XML site and space export reaches end of life on December 1, 2026, after which Atlassian will no longer fix bugs or accept support tickets for it and recommends CSV. Confirm the export format with your Atlassian administrator and keep a complete copy of each export outside the migration workspace. The step is done when every selected space has an export file stored in a location the migration team controls, with an inventory of attachment counts.
Convert and clean pages
Convert exported pages into Markdown files, either with a conversion script written by your team or a tool your engineers select after testing. Check internal links, image paths, tables, code blocks, and heading structure, and rewrite pages that depended on macros into plain Markdown or into linked references. Page owners review their own content, because conversion can change meaning in tables and status lists even when the text looks correct. The step is done when a sample from every space has been reviewed by its owner and the broken-link report is empty or accepted.
Configure authentication and storage sync
Set up Wiki.js with a dedicated domain or subdomain, since it cannot run in a subfolder, and connect the authentication module your identity team runs, such as Azure AD, Okta, Keycloak, LDAP, or SAML 2.0. Configure the Git storage module so that the Markdown source repository stays in sync with the wiki in both directions, and decide which storage module serves attachments, such as AWS S3 or a self-hosted S3-compatible store. Identity and security teams must confirm group mapping, MFA policy, and who can edit which paths. The step is done when a test user from each group can sign in, edit a page, see the change appear in the Git repository, and be denied in the areas they should not reach.
Pilot with one team
Move one team's spaces into the Wiki.js instance and run them in daily use for a period agreed with the team lead. Track broken links, search results, edit conflicts between the wiki and Git, and any content the team needs but cannot recreate in Markdown. Record each issue with an owner and a decision, such as fixing the conversion, rewriting the page, or keeping the page in Confluence. The step is done when the team lead confirms in writing that the pilot content is usable and that open issues have a plan.
Cut over and retire Confluence content
Move the remaining spaces in agreed batches, redirect users from Confluence links where possible, and set the archived spaces to read-only or remove edit rights according to the retention decision. Verify backups of the Confluence archive and of the Wiki.js database, storage, and Git repository, and document the restore procedure. Retire Confluence access only after the retention owner confirms the archive is complete. Ongoing ownership of upgrades, backups, and Wiki.js versions moves to your platform team, which should confirm how it will track the Wiki.js 2.x release line and check the 3.0 beta status before any future move. The step is done when the cutover checklist is signed by the content, security, and platform owners.
Questions buyers ask before choosing Wiki.js or Confluence
What does it cost to move from Confluence to Wiki.js?
The cost comes from people and infrastructure more than from the software, because Wiki.js is AGPL-3.0 licensed and there is no license fee to pay for the core product. The one-time costs are planning, the content audit, the Git or S3 storage design, the SSO integration, the content conversion and testing. The recurring costs are the servers or containers, database backups, patching, upgrades and staff time to run it. Costs rise with the number of spaces that rely on macros or Marketplace apps, the number of identity integrations and any compliance evidence you must produce. Ask any quote for a line-item breakdown of design, migration, integration, hardening, backup and handover, and for what is included after go-live.
How long does a Confluence to Wiki.js migration take?
Timing depends on the volume and shape of the content, not on the software alone. The main drivers are how many spaces and pages move, how many use Confluence macros that must be rewritten as Markdown, how many attachments and permissions need mapping, and how many identity systems must be connected. Teams that choose Git sync also need time to agree on repository structure and sync direction. Wiki.js requires a dedicated domain or subdomain, so DNS and certificate work belongs in the plan. No duration is given here because none is supplied for this comparison. Ask for a timeline tied to a written scope with named phases and sign-off points.
What does the team need to provide for a Wiki.js project?
You need a named business owner who can decide page ownership and what to retire, an engineer or platform owner for hosting, and someone who knows your identity provider and can grant the application registration. You also need access to a Confluence export in a supported format, a list of the Marketplace apps and macros in use, and a Git repository or S3 bucket if you want content stored outside the database. Wiki.js 2.x recommends PostgreSQL 9.5 or later, and the PostgreSQL search module needs the pg_trgm extension, so a database administrator should be available. Linux systems need at least 1 GB of RAM according to the requirements documentation. Confirm these prerequisites against your own environment before scoping.
Can a small team run Wiki.js without outside help?
A small team can run Wiki.js if it has someone comfortable with Node.js containers, PostgreSQL backups, reverse proxies and identity configuration, and if the wiki stays close to standard Markdown pages. Wiki.js runs in Docker and Kubernetes and supports sideloading for offline environments, which keeps the install simple. The harder parts are ongoing: patching the application and database, testing restores, managing SSO changes and keeping storage sync healthy. Teams without that skill set usually buy support for the setup and handover, then run it internally. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and supports them through fixed-scope engagements or retainers, with the scope agreed in writing first.
Is Wiki.js 3.0 safe to adopt for production documentation?
No. The main requarks/wiki repository holds Wiki.js 3.0, and its README marks that version as beta and not for production use. The stable line is 2.x, which lives in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. Build on the 2.x line for production and plan an upgrade path when a stable 3.x release is published. Before any upgrade, read the release notes, test on a copy of the database and content, and confirm that your authentication modules and storage sync still behave as expected.
Does Git sync in Wiki.js keep Confluence macros working?
Git sync keeps Markdown content in a repository, but it does not reproduce Confluence macros or Marketplace apps. Wiki.js storage modules include Git, and some modules synchronize content in both directions, which suits engineering teams that want pages in version control. Confluence features such as Jira issue macros, page properties reports and app-based content have no direct Markdown equivalent, so each one must be rewritten, replaced with a Wiki.js feature or dropped. Ask for an inventory of macros and apps during scoping, and check how each synced page renders after a round trip through the repository.
How is SSO set up for Wiki.js?
You configure SSO as an authentication module in the Wiki.js administration area, using the settings from your identity provider. Wiki.js supports Azure AD, Okta, Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, and SAML 2.0, and it offers TOTP two-factor authentication. Each module needs its own client registration, callback URL and attribute mapping, so plan the group and role mapping before cutover. Test sign-in with a non-admin account and confirm that deprovisioned users lose access. Confirm the exact steps for your provider against the authentication documentation and your own tenant configuration.
Does Wiki.js meet the compliance needs of a regulated team?
Wiki.js can support access control, SSO, two-factor authentication and self-hosting in your own infrastructure, but it does not produce compliance evidence on its own. Auditors look at configuration, access reviews, logging, backup testing and change records, and these must come from your processes and tooling. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your assessor early which evidence they expect from the wiki.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Confluence to Wiki.js decision, the useful first step is a written evaluation: we map each Confluence feature your teams use (macros, Marketplace apps, space permissions, blog posts, page history and attachments) against what Wiki.js does and does not provide, then record the gaps as decisions rather than surprises. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope.
On the implementation side, the work that usually takes the most care is identity and storage. We configure the authentication module that matches your directory, whether Azure AD, Okta, Keycloak, LDAP or SAML 2.0, and test sign-in, group mapping and TOTP enrollment with real accounts before cutover. We also set up the storage target, such as Git sync or S3, decide which side is the source of truth, and confirm how edits flow in both directions. Migration from Confluence is scoped separately, covering the export format, the content that moves cleanly, and the pages a person must review by hand. Ask any partner for the exact test cases and acceptance criteria in the written scope.
Ongoing work is available through retainers that cover upgrades, backups, security updates and continuous testing after go-live. Wiki.js 2.x and the 3.0 beta carry different maturity levels, so a retainer should state which line is in production and who decides when to move. DeployOpen does not hold partner status with Wiki.js, Requarks or Atlassian, and it does not issue audit reports or certifications. Where you need evidence for an assessment, we prepare the controls and records, and independent auditors make the determination.
