Self-hosted wiki software compared

Which self-hosted wiki fits your team's content and identity needs

Choose XWiki when internal knowledge needs structure, page-level permissions and a paid vendor support path, and choose BookStack when documentation fits books, chapters and pages on shelves and the stack should stay small. Most of the decision comes down to how much governance your content needs and how much operating surface your team wants to run. XWiki is LGPL-2.1-or-later and grants view, comment, edit and delete rights at wiki, page or hierarchy level, so access can follow your org chart. XWiki SAS sells support, hosting and Pro applications, with tiers set by user count. BookStack is MIT licensed, requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and supports OIDC, SAML2 and LDAP sign-in with role-based MFA enforcement.

Choose Wiki.js for a lightweight Node.js wiki that needs many storage and authentication modules. Its stable line is 2.x, maintained in the requarks/wiki-v2 repository, while the 3.0 beta in the main repository is marked not for production use, so plan on 2.x. It needs a dedicated domain or subdomain, at least 1 GB of RAM on Linux, and PostgreSQL is recommended. Its Git and S3 storage modules and SAML 2.0, Keycloak and LDAP options suit teams whose content lives in repositories. For other needs, MediaWiki is the GPL engine behind Wikipedia, and DokuWiki is a lighter option, but confirm each one's storage model, extensions and upgrade path against your requirements. Outline's community edition is under the Business Source License, which is not OSI open source, so check those terms with legal before you standardize on it.

Before you choose, run the same pilot on each shortlisted wiki: connect your identity provider, test group-based permissions on a restricted space and time an export of your largest space. Ask XWiki SAS to quote Pro and support tiers in writing, and ask whether a Confluence exit needs their Confluence Migrator Pro, which the XWiki Store lists from 2000 EUR. For BookStack, confirm that your operations team supports the required PHP and database versions, since the project publishes installation scripts for Ubuntu but no official Docker images. For Wiki.js, settle your database and storage choices early, because PostgreSQL search depends on the pg_trgm extension.

Which wiki to pick for each scenario

This table matches common wiki scenarios to the platform whose supplied facts fit them best, with what to confirm before deciding. Read each row as a starting point: the fit is tied to a licensing, structure, authentication or storage fact, and the confirmation column names the check that still belongs to your environment.

Scenario	Best fit	Why	What to confirm
Confluence replacement with page-level permissions	XWiki	XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level and keeps every page change under version control. XWiki SAS also offers a Confluence migration tool that carries pages, users, groups and permissions.	Whether the Confluence Migrator Pro trial limit of 30 pages per migration fits your volume, and how attachment history will be handled since only page history is kept.
Small team documenting procedures	BookStack	BookStack organizes content into books, chapters and pages on shelves, offers a WYSIWYG editor with an optional Markdown editor, and has built-in diagrams.net diagrams. It is MIT licensed and needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later.	Whether your team can run a PHP stack, and whether you need official Docker images, since BookStack does not publish them and points to community setups.
Node.js shop wanting Git-synced content	Wiki.js	Wiki.js runs wherever Node.js is supported and has a Git storage module that synchronizes content in both directions. It is AGPL-3.0 licensed, with stable 2.x receiving releases such as v2.5.316.	Whether to stay on the 2.x line, since the 3.0 beta in the main repository is marked not for production use, and whether your Git sync needs match the module's behavior.
Team needing air-gapped sideloading	Wiki.js	Wiki.js supports sideloading files for environments without internet access and runs on Linux, Docker and Kubernetes. Its requirements also state a dedicated domain or subdomain and at least 1 GB of RAM on Linux.	Which storage and search modules work offline in your network, and whether the PostgreSQL search module's pg_trgm extension can be installed in your isolated environment.
Enterprise wiki needing SSO and multi-factor sign-in	XWiki or BookStack	BookStack supports OIDC, SAML2 and LDAP sign-in with multi-factor authentication that can be enforced per role. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, with the Pro applications being a paid addition.	Which identity provider you use, whether your SSO requirement sits in the free edition or a paid XWiki Pro plan, and whether you need enforced multi-factor per role.
Teams that want the most mature Git or LDAP-backed authentication options	Wiki.js	Wiki.js authentication modules include Azure AD, GitHub, Google, Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, Okta and SAML 2.0, with TOTP two-factor authentication.	Whether TOTP is sufficient for your policy, and whether each module you need has been tested against your identity provider version.
Large organization needing vendor support and training	XWiki	XWiki SAS offers on-premises professional support, installation help and training, and XWiki Pro adds connectors such as Google Apps, Office365 and OnlyOffice. Consulting requires a Business or Enterprise support plan.	Which support tier matches your user count, since the tiers are sized by users, and whether cloud and on-premises pricing will be quoted as the same.
Multi-database operations with PostgreSQL recommended	Wiki.js	Wiki.js 2.x recommends PostgreSQL 9.5 or later and also supports MySQL 8.0 or later, MariaDB, MS SQL and SQLite. The PostgreSQL search module needs the pg_trgm extension.	Whether your database platform team supports the recommended PostgreSQL version and extensions, and whether MS SQL or SQLite is acceptable for your scale.
Team standardizing on containerized deployment	XWiki	The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8, and are maintained by the XWiki Core Dev Team.	Which release line to pin, since 18.8.0 is stable, 17.10.14 is LTS and 18.4.7 is the intermediate LTS, and how you will track upgrades between them.

What the license and paid editions mean for each wiki

XWiki is licensed under the LGPL 2.1 or later, and its official Docker image repository is also LGPL 2.1. The core platform can be run, modified and redistributed under those terms. XWiki SAS sells the commercial layer around it: support subscriptions, hosting, consulting, training, migration tooling and paid Pro applications. Those paid pieces are licensed and priced separately from the core, so the license of a feature set may differ from the license of the platform underneath it.

Free edition. XWiki Standard is the free open source version. The Pro applications, including the Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros and the Google Apps, Office365 and OnlyOffice connectors, sit outside it.
Subscription tiers. Starter covers up to 25 users and is available on XWiki Cloud only. Basic covers up to 1,000 users, Business up to 10,000 and Enterprise unlimited. XWiki SAS states that cloud and on-premises pricing is the same, so the user count and tier drive the cost, not the hosting choice.
Consulting and training. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day (XWiki pricing).
Confluence migration. Confluence Migrator Pro is priced from 2000 EUR. Its trial is limited to 30 pages per migration, which cannot prove a full migration. It keeps page history but not attachment history.

Before you commit, ask XWiki SAS which Pro applications your SSO and connector requirements depend on, and confirm the user tier against your headcount including external guests.

How structure, editing and permissions differ across the options

The data model decides how content is organized, who can change it, and how hard it is to leave later. XWiki models content as structured pages inside a hierarchy, and it keeps every page change under version control. Its permissions can be granted to view, comment, edit and delete at the wiki, page or hierarchy level, which makes it the strongest fit when access must follow a document tree or differ between sections. Confirm in a test wiki that the rights you need can be set at the depth you plan to use, and that inherited rights behave as you expect when a page moves.

BookStack uses a fixed four-level model: books, chapters, pages and shelves, where shelves group books. Editing is WYSIWYG with an optional Markdown editor and built-in diagrams.net diagrams, so authors can work in the mode they prefer. Its role and permission system is the main access control, and the question to settle is whether your access rules fit at the shelf, book, chapter or page level. Content in this model is stored in the database, so a later move depends on exporting pages in a usable format, which you should test with a sample book before committing.

Wiki.js takes a different approach to storage. Its page editing sits on top of the storage layer, and its Git storage module can synchronize content in both directions, which keeps a copy of your pages in a repository you control. That can simplify review, backup and an eventual exit, but the sync behavior and conflict handling need to be tested against your own editing habits. Wiki.js also has no per-page permission model comparable to XWiki's hierarchy rights, so confirm whether its access rules meet your requirements before you design the site.

How SSO, LDAP and MFA compare in each wiki

Identity is often the deciding factor for a self-hosted wiki, because it determines who can sign in, how groups map to permissions and whether MFA can be required. The options differ by product, and in some cases the features you need sit in a paid layer, so confirm each one against your directory and your sign-in policy before you commit.

BookStack: OIDC, SAML2, LDAP and role MFA

BookStack supports OIDC, SAML2 and LDAP sign-in, and its built-in multi-factor authentication can be enforced per role, which lets you require a second factor for administrators or editors without forcing it on every reader. Check how your directory groups map to BookStack roles, because permissions are granted through its role and permission system rather than inherited automatically. Test the enforcement path with a real administrator account before rollout.

Wiki.js: Azure AD, Keycloak and Okta

Wiki.js includes authentication modules for Azure AD, Keycloak OpenID Connect, Okta, generic OpenID and OAuth2 and SAML 2.0, so most enterprise identity providers have a path. TOTP two-factor authentication is available for local accounts. Confirm which module matches your identity provider's protocol and claims, and test group mapping, since Wiki.js access control depends on how groups are assigned in the wiki itself.

Wiki.js: LDAP and Active Directory

Wiki.js offers an LDAP and Active Directory module, which suits organizations that keep user accounts in an on-premises directory. Confirm how the module handles group membership, account disablement and password resets, since these determine whether a departing employee loses wiki access on the same day. Also verify whether TOTP enrollment can be required for directory accounts, because the second factor is a separate setting from the directory login.

XWiki Pro: AD and Azure AD applications

XWiki Pro lists Active Directory and Azure Active Directory SSO applications among its paid business applications. Because these are part of the Pro offering, budget for them as a licensing decision rather than assuming they come with the free XWiki Standard. Confirm which tier and support plan includes each application and what your directory requires, such as group attributes and certificate handling.

XWiki OIDC: confirm before you commit

The xwiki-contrib/oidc project provides OpenID Connect support for XWiki. It is a community project, so treat it as something to verify rather than assume. Test it against your identity provider, confirm its compatibility with the XWiki release branch you plan to run, and document who maintains the component and how upgrades will be tested before you use it for production sign-in.

Paid tiers may gate enterprise sign-in

For several of these wikis, the stronger identity features sit in paid layers or depend on a support plan, while the free edition covers basic sign-in. Ask each vendor, in writing, which protocol, directory connector and MFA option are included in the edition you will run, and whether the license changes if your user count grows. Ask for these answers before you size the platform.

Capability table across the wiki options

This table sets XWiki, BookStack and Wiki.js side by side on license, stack, databases, sign-in, permissions, storage and paid tiers, with MediaWiki, DokuWiki and Outline as alternatives. Where our research has no supplied fact for a cell, it says to confirm with the vendor, so treat those cells as checklist items rather than answers.

Row	XWiki	BookStack	Wiki.js
License	LGPL-2.1-or-later; SAS sells support, hosting and Pro apps	MIT	AGPL-3.0; stable 2.x line in requarks/wiki-v2
Stack	Java, deployed on Tomcat in the official Docker images	PHP 8.2 or later with the Laravel framework	Node.js; runs on Linux, macOS, Windows, Docker and Kubernetes
Databases	MySQL, PostgreSQL or MariaDB image variants	MySQL 8.0 or MariaDB 10.6 or later	PostgreSQL recommended (9.5 or later); also MySQL 8.0+, MariaDB, MS SQL, SQLite
SSO and LDAP	Active Directory and Azure AD SSO apps listed in XWiki Pro; confirm LDAP and SAML in Standard	OIDC, SAML2 and LDAP sign-in	Azure AD, GitHub, Google, Keycloak OIDC, LDAP/AD, generic OIDC and OAuth2, Okta, SAML 2.0
MFA	Confirm with vendor	Built-in MFA, enforceable per role	TOTP two-factor authentication
Permission granularity	View, comment, edit and delete rights at wiki, page or hierarchy level	Full role and permission system; confirm scope of book and page controls	Confirm with vendor
Storage modules	Confirm with vendor	Database-backed; confirm any external file storage options	Git, AWS S3, DigitalOcean Spaces; Git syncs both directions
Versioning	Every page change kept under version control	Confirm with vendor	Confirm with vendor
Hosting footprint	Tomcat plus a relational database; 1 GB RAM and dedicated sizing not supplied	PHP web server plus MySQL or MariaDB; install scripts for Ubuntu 22.04, 24.04 and 26.04	Node.js app needs a dedicated domain or subdomain; at least 1 GB RAM on Linux
Paid tiers	Pro and support tiers: Starter, Basic, Business, Enterprise; cloud and on-premises priced the same	Paid support plans and sponsorship; confirm current plan contents	Open-source core; confirm any commercial support with vendor

What storage and dependencies each wiki needs to run

Start by checking the database and runtime each wiki expects, because this decides which servers you must build, patch and back up before any content goes in. BookStack needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and its installation docs cover Ubuntu 26.04, 24.04 and 22.04 scripts. BookStack does not publish official Docker images and points to community setups such as LinuxServer.io, so a container-first platform team should decide whether it will adopt an image it does not maintain or build its own. XWiki's official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8, which makes the database choice a tag decision made at deployment time.

Wiki.js is the most database-sensitive of the three in this section. Its 2.x line recommends PostgreSQL 9.5 or later, also supports MySQL 8.0 or later, MariaDB, MS SQL and SQLite, and needs the pg_trgm extension for its PostgreSQL search module. Confirm that your database provider permits that extension before you commit to PostgreSQL, and confirm the search behavior you need on the database you choose. Wiki.js also requires a dedicated domain or subdomain, since it cannot be mapped to a subfolder of an existing site, and Linux systems need at least 1 GB of RAM. Plan the DNS record and certificate for that hostname early, because changing it later affects every link to the wiki.

Runtime and offline operation differ as well. Wiki.js runs wherever Node.js is supported, including Linux, macOS, Windows, Docker and Kubernetes, and it supports sideloading files for environments without internet access. If you run in an air-gapped network, test the sideloading path with your own package process before go-live and confirm with your platform team how Node.js versions will be patched. For any of the three, ask the vendor or community maintainers which versions are supported on your target operating system and database, and budget the recurring work of tracking those versions against your change calendar.

How release lines and upkeep shape the effort to run each wiki

Release cadence determines how often your team patches, upgrades and retests a wiki. The four cards below cover the upkeep decisions that matter most across XWiki, BookStack and Wiki.js, and the checks to run before committing to one.

XWiki runs parallel release branches

XWiki publishes a stable line alongside LTS and intermediate LTS branches. At research time, 18.8.0 was the stable release, 18.4.7 was the intermediate LTS, 17.10.14 was the LTS, and 16.10.19 was still receiving releases. Choosing a branch sets how long you stay on it and how often you must move to the next one. Confirm with XWiki SAS how long each branch receives fixes before you pick one for production.

BookStack ships frequent point releases

BookStack publishes releases often, such as v26.09 on September 24, 2026 and v26.09.1 on September 29, 2026. Frequent point releases mean small, routine upgrades, but they also mean your team must test and apply them on a regular schedule. Because BookStack does not publish official Docker images, you must also check whether your chosen community image tracks each release before you rely on it.

Wiki.js 2.x stable and 3.0 beta

The stable Wiki.js line is 2.x, with v2.5.316 published on October 2, 2026, and it lives in its own repository. The main repository holds Wiki.js 3.0, which is marked beta and not for production use. Plan for 2.x as your production line and confirm the maintenance window for 2.x before 3.0 is ready, because a later move from 2.x to 3.0 would be a separate upgrade project.

Self-hosting puts backups and patching on your team

In a self-hosted deployment, your organization owns the database, file storage, backups, patching and upgrade testing for each wiki. Vendors supply the code, not the operating service. Each platform depends on a database and some on search or storage modules, so every component needs its own backup and restore test. Ask who on your team owns each of these tasks and how often restores are tested.

Confirm support windows with each vendor

Release dates alone do not show how long a line stays supported. Ask XWiki SAS, the BookStack maintainers and the Wiki.js maintainers in writing how long each branch receives security fixes, what notice you get before end of life, and whether paid support changes those windows. Record the answers in your upgrade plan so the next major move is scheduled, not forced by an unpatched vulnerability.

How to choose and pilot a self-hosted wiki

This sequence turns a shortlist of wiki platforms into a decision backed by a working pilot on your own database, identity provider and backup process. Each step produces a written artifact that the next step depends on.

Inventory content types and permission needs
Knowledge owners, the documentation lead and a sample of editors list the content you must hold: runbooks, policies, architecture notes, customer-facing guides, and any attachments or diagrams. For each type, record who must view, comment, edit and delete, and whether rights should follow a space, a page or a hierarchy. Done when you have a one-page matrix that a reviewer can test against a real platform, not a generic feature list.
Map identity requirements for sign-in and MFA
Your identity team confirms which sign-in methods the wiki must accept, such as OpenID Connect, SAML 2.0 or LDAP and Active Directory, and whether group membership must drive access. They also state whether multi-factor authentication must be enforced for every user or only for certain roles. Ask each shortlisted vendor to confirm these protocols and enforcement options in their current documentation, and note which features sit in a paid tier. Done when the identity requirements are signed off and every candidate has a written answer for each one.
Check migration paths from existing wikis
Inventory the source systems, export formats and page counts, and identify who owns the migration. Ask each vendor whether it has a supported import path, what it carries across (pages, history, users, groups, permissions, attachments) and what it does not. For example, one vendor's Confluence migration tool keeps page history but not attachment history, so that gap must be confirmed before you rely on it. Done when you have a migration gap list per candidate and an estimate of the work that stays in-house.
Shortlist two platforms against the requirements
Score each candidate against the content matrix, identity requirements, migration gaps, license terms and paid tiers, and the stack it needs (database, PHP, Node.js or Java runtime). Keep two options that clear every must-have, and record the reason for each exclusion. Confirm license and edition terms directly with the vendor before the pilot, since paid features can change between editions. Done when a short written shortlist exists with the open questions for each option.
Run a pilot on your target database and identity setup
Deploy both shortlisted platforms in a non-production environment that matches production: the same database engine and version your team supports, the same identity provider and a dedicated domain or subdomain where the platform requires one. Load a representative sample of content, including large pages, attachments and diagrams, and sign in with accounts from each relevant group. Done when each pilot runs on the target stack and you have a log of configuration steps, issues and the effort each one took.
Test permissions, search and restore from backup
Run the permission matrix from the first step with test accounts for each role, confirming both that access is granted where it should be and denied where it should not. Verify that search works on the chosen database configuration, that MFA enforcement behaves as documented, and that a full restore of content, users and attachments succeeds into a clean instance. Record every failed check and whether the vendor or your team must fix it. Done when the permission matrix passes, and a restore has been completed and timed by your own operators.
Decide and document the operating model
Compare the two pilots on the evidence gathered: permission accuracy, identity fit, migration gaps, restore results and the upkeep your team observed during the pilot. Decide who will patch, back up and upgrade the platform, and what support, if any, you will buy from the vendor or an implementation partner under a written scope. Record the decision, the rejected option and the reasons. Done when the decision record is approved and the runbook for upgrades and backups is assigned to named owners.

What do self-hosted wiki projects cost to run and migrate?

What actually drives the cost of running a self-hosted wiki?

Most of the cost is staff time and infrastructure you already pay for, not licence fees, because XWiki, BookStack and Wiki.js are open source and free to self-host. The main drivers are the hosting footprint, the database you choose, how much identity integration you need, the volume and age of content, and how many people will edit. Each platform adds different dependencies: BookStack needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, Wiki.js recommends PostgreSQL 9.5 or later and needs a dedicated domain, and XWiki ships official Docker images for MySQL, PostgreSQL and MariaDB variants running on Tomcat. Ask your team to price each of these against the infrastructure and skills you already run.

Do paid support tiers matter for a self-hosted wiki?

They matter when you need a vendor to answer for the product, not when you only need the software. XWiki SAS sells support and Pro applications in Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users) tiers, and states that cloud and on-premises pricing is the same. Consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, and training at 1500 EUR per day. BookStack offers paid support plans and Wiki.js has no published paid tier in the supplied facts, so confirm the current options directly with each vendor before you assume either way.

When is Confluence Migrator Pro's 2000 EUR starting price worth paying?

It is worth pricing when you are moving a large Confluence estate and want spaces, users, groups, permissions and attachments carried across in one tool. The XWiki Store lists Confluence Migrator Pro from 2000 EUR, which migrates spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history but not attachment history. The trial is limited to 30 pages per migration, so it is useful for testing mapping and layout but not for proving a full migration. For a small wiki, manual export and import or a scripted approach may cost less in effort, so compare the tool price against the hours your team would spend.

Can a team run a self-hosted wiki without outside help?

A team with Linux, database and web server experience can usually run BookStack, Wiki.js or XWiki on its own, because all three are open source and documented. BookStack provides official installation scripts for Ubuntu 26.04, 24.04 and 22.04 but no official Docker images, so Docker users rely on community setups such as LinuxServer.io. Wiki.js runs on Linux, macOS, Windows, Docker and Kubernetes and needs at least 1 GB of RAM on Linux. The harder questions are identity integration, backup and restore testing, and upgrades across release lines, which is where a team with thin operations capacity often asks for outside help.

What skills does the work need from the team?

Plan for database administration, reverse proxy and TLS configuration, identity provider setup and a named owner for upgrades. Each platform asks for different depth. Wiki.js needs a dedicated domain or subdomain because it cannot be mapped to a subfolder, and its PostgreSQL search module needs the pg_trgm extension. BookStack needs PHP administration and MFA or role policy decisions. XWiki needs Java and Tomcat familiarity if you run it outside Docker, and you should choose between its stable, intermediate LTS and LTS lines based on your upgrade appetite. Name these owners before the pilot starts.

How long does a pilot take to set up?

The pilot is usually short for BookStack and Wiki.js because each is a single application with a standard database, and longer for XWiki because it adds an application server and more configuration choices. The actual duration depends on your identity integration, the number of spaces you want to test, and whether you are importing content. Treat any timeline as something to agree in writing with your implementation partner or internal team, based on your own environment, rather than a figure taken from this page.

What should I ask for in a quote for a self-hosted wiki project?

Ask for a written scope that lists the platform and version, the hosting target, the database, the identity provider and SSO method, the content volume and import sources, and the permission model. Ask which items are one-time work, such as installation, integration, migration and hardening, and which recur, such as support, upgrades and backup testing. Ask how the vendor will handle the upgrade path between release lines, what the trial or pilot covers, and what changes if the content volume or user count grows. DeployOpen plans, implements, integrates, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts.

How DeployOpen helps teams select and implement a wiki

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, whether that is the client's cloud account, data center or air-gapped network. For a wiki decision, that work usually starts before any installation: agreeing which platform fits the content model, how editors will work, which identity provider must sign users in and where the wiki's storage and database will live. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and ongoing support, upgrades and continuous testing can be added as optional retainers.

DeployOpen does not favor one platform in this comparison. It does not publish a price list, so a quote follows from the written scope, and the cost drivers are the ones this page describes: the number of users and editors, the identity integrations, the data migration and the hardening and backup requirements. Ask any implementation partner, including DeployOpen, to write down which platform it recommends, why, and what it would cost to change course later. Ask for the same breakdown from each option you shortlist so the comparison stays about your requirements.

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. If your wiki will hold policies, procedures or evidence used in an audit, confirm with your auditor or certification body which records they will accept and how the wiki's version history, access logs and retention settings will be presented. DeployOpen can help set up and document those controls so your team has them ready for that review.