XWiki vs Wiki.js: which fits your team
Choose XWiki when your wiki has to behave like a governed information system rather than a shared notebook. Its structured wiki keeps every page change under version control and grants view, comment, edit and delete rights at wiki, page or hierarchy level, which matters when different business units must see different spaces and when auditors ask who changed what. XWiki is licensed under *LGPL-2.1-or-later*, and XWiki SAS sells support, hosting and paid Pro applications on top of the free core. Because XWiki maintains several release branches in parallel, you can stay on a branch that matches your upgrade tolerance and move between branches on your own schedule. Confirm which branch your team would run, how long each branch receives fixes, and what the Java runtime and database requirements are for that branch before you commit.
Choose Wiki.js when your editors work in Markdown, your permission model is simpler, and you want a lightweight Node.js application with a broad choice of database. Wiki.js 2.x is AGPL-3.0 licensed, and its requirements documentation lists PostgreSQL as the recommended database, with MySQL, MariaDB, MS SQL and SQLite also supported. Treat the version question as the central risk: the stable 2.x line now lives in a separate repository, while the 3.0 release on the main repository is a beta marked not for production use. Plan to run 2.x in production, confirm with the maintainers what a future migration to 3.0 will involve, and budget for that work even if it is not urgent. AGPL-3.0 also carries network-use obligations for any modifications you publish, so have counsel review them if you plan to customize the code.
The decision turns on three questions. First, the permission model: if you need per-page and per-hierarchy rights tied to organizational structure, XWiki fits; if a single access tier per wiki is enough, Wiki.js is simpler to administer. Second, editing habits: teams fluent in Markdown and code-adjacent documentation will be productive in Wiki.js, while teams that need structured data inside pages should test XWiki's model with real content. Third, your tolerance for upgrade work: XWiki's parallel branches give you a choice of pace, whereas Wiki.js users must track a stable line and a pending major version. Run a pilot with your own identity provider, your largest space and your most demanding editors before you decide.
Which scenarios favor XWiki and which favor Wiki.js
This table maps common wiki scenarios to the platform that usually fits best and the condition under which the other option would still be reasonable. Read each row against your own approval, permission and database requirements, since the verdict shifts with those constraints. The main takeaway is that XWiki suits governed, permission-heavy documentation, while Wiki.js suits Markdown-first technical content on a database your team already runs.
| Scenario | Better fit | When the other option is still reasonable |
|---|---|---|
| Regulated documentation with approval and audit needs | XWiki | Wiki.js could work if approvals happen in an external process and your assessor accepts exported version history. Confirm how each platform records page changes before deciding. |
| Engineering runbooks written in Markdown | Wiki.js | XWiki is reasonable if runbooks need structured data or must sit alongside formal governance pages in one wiki. Check whether your authors will accept its editing model. |
| Mixed-permission intranet with departments and restricted areas | XWiki | Wiki.js fits if access needs are coarse, such as a few public and internal sections. Test the exact permission model against your access matrix first. |
| Small team on a single existing database | Wiki.js | XWiki fits if the team already operates Java services and needs its richer structure. Confirm which database engines each platform supports against your standard stack. |
| Long-term maintenance with minimal upgrade churn | XWiki | Wiki.js 2.x remains a stable line, but its successor 3.0 is still in beta and not for production use. Plan the upgrade path before committing to a multi-year rollout. |
| Documentation written by many non-technical contributors | XWiki | Wiki.js suits contributors who are comfortable in Markdown. Run a short authoring trial with the actual contributors before choosing. |
| Quick internal knowledge base with few permission rules | Wiki.js | XWiki is still viable if the organization expects wiki growth into governed content. Weigh the added setup effort against that future need. |
How XWiki and Wiki.js are built and what that means for operations
XWiki and Wiki.js take very different routes to the same job: a shared knowledge base. The cards below cover the runtime, the database layer, how history is kept and the upkeep each design asks of the team that runs the server.
XWiki as a Java application
XWiki is a Java enterprise application, so the server team operates a Java runtime, an application server and a relational database. Confirm with XWiki which Java version, servlet container and database engines the release you plan to run supports, and which of those your standards already cover. Plan the Java patching cadence alongside XWiki's own upgrade path, since both affect the server.
Wiki.js as a Node.js application
Wiki.js runs on Node.js, so the team that maintains it needs Node.js expertise, npm dependency handling and a process manager or container setup. A single small application with fewer moving parts can suit a lean platform team. Check which Node.js version the 2.x release you choose requires before you commit to a build pipeline.
Database choice for Wiki.js
Wiki.js 2.x recommends PostgreSQL and also supports MySQL, MariaDB, MS SQL and SQLite. Choosing SQLite is simple for a pilot but ties backups and concurrency to one file, so most production teams should standardize on the recommended engine. Ask whether your database operators already run PostgreSQL backups and point-in-time recovery.
XWiki database and runtime requirements
Before you size hardware, confirm XWiki's supported database engines and Java runtime requirements with the vendor for the exact release and branch you will deploy. Ask whether the branch you pick is supported for the period your operations plan needs, since XWiki maintains several release branches in parallel. Put those answers into your build and patching calendar before the platform goes live.
How page history is stored
XWiki markets version control for every page change and fine-grained rights at wiki, page or hierarchy level, so history is part of the platform's data model. Wiki.js history depends on the storage and editor workflow of the 2.x line, so confirm how revisions are retained, exported and purged. Ask both vendors how history is covered by backups and how long it is kept by default.
What each design asks of operators
XWiki asks more of the platform team: Java tuning, app server care and branch planning in exchange for structured pages and rights. Wiki.js asks less infrastructure work but requires Node.js upkeep and a deliberate stance on the 3.0 beta, which the project marks not for production use. Decide which skills your team keeps in-house before you choose.
XWiki vs Wiki.js on editing, data, rights and identity
This table compares how XWiki and Wiki.js differ on license, editing, version history, rights, databases, identity and extensibility. Where a supplied fact does not settle a capability, the cell tells you what to confirm in each vendor's documentation before you decide.
| Capability | XWiki | Wiki.js 2.x |
|---|---|---|
| License | LGPL-2.1-or-later, with XWiki SAS selling support, hosting and paid Pro applications | AGPL-3.0, stable line maintained in the wiki-v2 repository |
| Editing style | Structured wiki pages with version-controlled changes, suited to teams that want page structure | Markdown-based wiki, a lighter editing model for documentation-first teams |
| Version control of page changes | Every page change is kept under version control, per xwiki.com | Confirm page history and revert behavior in the Wiki.js 2.x documentation for your edition |
| Rights granularity | View, comment, edit and delete rights set at wiki, page or hierarchy level | Confirm which rights can be set per page or per group in the Wiki.js 2.x documentation |
| Database support | Confirm supported database engines against the XWiki installation documentation for your release line | PostgreSQL (recommended), MySQL, MariaDB, MS SQL and SQLite, per the Wiki.js requirements |
| Identity integration | Confirm supported SSO and directory options in the XWiki admin documentation before scoping | Confirm supported authentication providers in the Wiki.js 2.x documentation before scoping |
| Extensibility | Paid Pro applications from XWiki SAS, plus open extensions; confirm which apps you need and their license | Confirm the extension model and available modules in the Wiki.js 2.x documentation |
| Long-term maintenance risk | Several release branches maintained in parallel, with 18.8.0 published on September 29, 2026 | Stable 2.x line is current, with v2.5.316 published on October 2, 2026, while 3.0 remains a beta not for production use |
What the licenses and paid offerings cover for each platform
XWiki is licensed under LGPL-2.1-or-later, a weak copyleft license that applies most directly to the platform code itself. For an internal deployment, you can run XWiki, configure it and build your own applications on it without publishing your organization's content or internal applications, provided you meet the license terms for any modified platform files you distribute. The commercial layer comes from XWiki SAS, which sells support, hosting and paid Pro applications on top of the open-source core.
- Source license: LGPL-2.1-or-later covers the platform. Sharing duties attach mainly to changes you make to those files and then distribute.
- Support: XWiki SAS sells support. Confirm response commitments, covered versions and whether your custom extensions fall inside the scope in writing.
- Hosting: XWiki SAS also hosts instances. A hosted deployment changes who operates the server, so confirm data location, exit terms and who holds the operational keys.
- Pro applications: Paid Pro apps are separate products. Check each app's license terms, update path and compatibility with the branch you choose.
- Branch choice: XWiki maintains parallel branches, including 18.8.0 published on September 29, 2026 and 16.10.19 on October 2, 2026. Pick a branch your support contract covers and plan its end of life.
Ask counsel to review your modification and distribution plans, and ask XWiki SAS for the support scope in writing before you commit.
Wiki.js is licensed under AGPL-3.0, a strong copyleft license with a network provision that matters for any wiki that people reach through a browser. The stable line is the 2.x series, which now lives in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. The main requarks/wiki repository holds a 3.0 beta that the project marks as not for production use, so a production plan should target the 2.x line until the 3.0 release is final.
- Stable line: The 2.x line in the wiki-v2 repository is the branch to evaluate for production. Track its release page for security and maintenance updates.
- Beta line: The 3.0 beta in the main repository is marked not for production use. Plan a migration path to it only after a stable release and a published upgrade guide.
- Repository confusion: Two repositories share the Wiki.js name. Confirm which one your installer, documentation and container images point to before you pin a version.
- Paid support: The supplied material does not describe a paid Wiki.js tier. Ask the maintainers or a services provider whether commercial support exists, and what it covers.
- Dependencies: Your own database, reverse proxy and identity integration are your responsibility to patch, whichever license applies.
Before you commit, confirm the target branch, its support status and your legal position on AGPL-3.0 obligations with counsel.
The AGPL-3.0 is designed to close a gap in ordinary copyleft: running modified software over a network without distributing it. In practical terms, if you modify Wiki.js and users interact with it over a network, the license generally expects you to offer those users the corresponding source of your modified version. Internal-only use by employees is still a network interaction, so the question is not hypothetical, but how the duty applies to purely internal use is a point for counsel to confirm.
- Unmodified internal use: Running the unchanged 2.x release for staff carries no source-offer duty beyond the normal conditions of the license. Keep a record of the exact version you run.
- Modified internal use: Custom themes, modules or code changes may trigger the network provision. Document each change and decide how you will provide the source if asked.
- Hosted by a vendor: The party that modifies and operates the service usually carries the duty. Ask a hosting provider how it handles source offers for any changes it makes to your instance.
- Plugins and integrations: Whether a separate tool that talks to Wiki.js over an API is a combined work is a question for counsel, not an assumption to make in a procurement file.
- Audit trail: Keep version pins, patch records and change logs, which help an assessor and a lawyer answer the same questions.
Ask counsel to confirm how the AGPL-3.0 network provision applies to your planned customizations, internal users and any external access before you deploy.
LGPL-2.1-or-later is a weaker copyleft license than AGPL-3.0. Its sharing obligations focus on the licensed library code when you modify it and distribute it. It does not include the network provision found in the AGPL, so running an unmodified XWiki instance for your own staff creates little or no obligation to publish source. Custom applications and extensions are a separate question, because whether they count as a work based on the platform depends on how they are built and linked.
- Unmodified internal use: Running standard XWiki for employees carries minimal sharing duty under the LGPL. Keep the version record for support and audit purposes.
- Modified platform files: If you change core platform files and distribute them, you will need to meet the license's source and notice terms for those files.
- Custom extensions: Extensions written against XWiki APIs may be separate works or may be treated as derived. Ask counsel to review your extension architecture.
- Hosted modified versions: Because the LGPL has no network provision, running a modified instance as a service does not by itself trigger the same source-offer expectation as the AGPL. Confirm this reasoning for your jurisdiction and contracts.
- Paid Pro apps: Their license terms are separate from the core and can add restrictions. Read each one before you assume the LGPL applies to it.
Have counsel confirm the boundary between platform code, custom extensions and Pro applications before you describe the deployment to auditors or customers.
How parallel XWiki branches and the Wiki.js 3.0 beta affect long-term maintenance risk
XWiki's parallel release branches let an organization choose its upgrade pace rather than follow a single line. The xwiki-platform releases page shows 18.8.0 published on September 29, 2026, alongside 18.4.7 and 17.10.14 on October 15, 2026, and 16.10.19 on October 2, 2026. An operator with a strict change window can stay on the branch that fits its testing calendar and apply maintenance releases within that branch, while a team that wants newer features can move to the latest line. The practical check is to map each branch to your own freeze periods, confirm with XWiki SAS how long each branch receives fixes, and confirm that your installed extensions and custom applications support the branch you pick. Extensions are often the real constraint, so test them against the target branch before committing.
Wiki.js has a different risk profile because its stable line and its next major version now live in separate places. The stable 2.x line sits in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. The main requarks/wiki repository holds a 3.0 beta that is marked not for production use. Staying on 2.x is therefore a current, supported choice, but it also means the eventual move to 3.0 is a planning decision with no fixed date. Confirm with the maintainers which 2.x releases will receive security fixes once 3.0 reaches stable, and check the Wiki.js requirements for the database versions your 3.0 target would need. Treat any 3.0 migration as a project in its own right: back up the database, test a restore, rehearse the upgrade in a staging copy, and review your content, storage and authentication settings against the new release notes before cutover.
The planning question is when to move, and the answer should come from your own change calendar. For XWiki, the decision is which branch to hold and how often to take maintenance releases. For Wiki.js, the decision is whether to remain on 2.x until 3.0 is stable and proven in comparable environments, or to pilot 3.0 early in a non-production copy. Either way, write down who approves a branch change, what evidence is needed, and how a rollback would work. Ask DeployOpen or your internal team to document these steps in the runbook so that maintenance risk is managed through a repeatable process rather than through a single upgrade event.
What drives the running cost of each wiki
The running cost of either wiki is mostly labor, not licenses, because both products are free under their open-source licenses (XWiki under LGPL-2.1-or-later, Wiki.js 2.x under AGPL-3.0). Your one-time costs are the installation, the permission model, and any content migration. Permission design deserves the most attention in XWiki, where view, comment, edit and delete rights can be set at wiki, page or hierarchy level, so a poorly planned rights tree is expensive to untangle later. Wiki.js has a simpler access model, so its one-time effort is usually smaller, though you still need to confirm that its groups and page rules match your requirements. If you bring in an implementation partner for permission design or migration, that fee is a one-time cost, and it scales with the number of spaces, page hierarchies and content sources you need to map. Ask for those counts explicitly in the scope. Recurring costs fall into four buckets: server and database infrastructure, skilled staff time, upgrades, and support. XWiki runs on Java and maintains several release branches in parallel, so your team will need Java operations skills, and each upgrade must be planned against the branch you have chosen. Wiki.js 2.x runs on Node.js, and the requirements documentation recommends PostgreSQL, with MySQL, MariaDB, MS SQL and SQLite also supported. Your recurring database and backup work depends on which engine you pick. The Wiki.js 3.0 line is still in beta and marked not for production use, so a plan that depends on it carries a migration risk you must budget for. XWiki SAS sells support, hosting and paid Pro applications, which replace some internal staff time with a subscription. Confirm what each option covers before you compare it with internal effort. When you request a written quote, ask for the scope split into one-time and recurring items, with named deliverables for installation, permission model design, content migration, backup and restore testing, and upgrade runbooks. Ask which XWiki release branch the quote assumes, how many upgrades per year are included, and who performs patching outside business hours. For Wiki.js, ask which database engine and version the quote assumes, and how a move from the 2.x line to 3.0 would be scoped if you choose to adopt it later. Request the hourly or fixed-fee basis for each item, the assumptions behind any retainer, and the exit terms for hosting or support contracts. DeployOpen provides fixed-scope quotes after the written scope is agreed, so those assumptions should appear in the scope document.
Moving content from one wiki to the other without losing page history
This sequence moves pages, attachments and their revision history from XWiki to Wiki.js or the reverse, and ends with a source system that can be read-only, archived and retired with users' sign-off.
Inventory spaces, pages and attachments
Start by listing every space or site section, page, attachment and linked asset in the source wiki, with its owner, last edited date and whether anyone still uses it. Export that list from the source's own tools or an administrative query, then mark pages as move, archive or delete. The output is a signed-off inventory that the migration team and content owners both accept, so that the scope is fixed before any content is touched. Ask the vendor which export formats the source supports for bulk listing, since this varies by version and configuration.
Map permissions onto the target model
Document the source's rights at wiki, space, page and hierarchy level, then write down how each right has to be expressed in the target. XWiki grants view, comment, edit and delete rights at several levels, while Wiki.js access is controlled through its own group and path rules, so some grants will have no exact equivalent. Security and content owners review the mapping table and approve every exception. The output is a permission map with each gap marked for a decision, and it should be checked against the identity provider groups that the target will use.
Convert content between Markdown and structured pages
Choose the conversion path for page bodies. Moving from Wiki.js to XWiki means converting Markdown into XWiki's syntax or structured content, and the reverse direction means flattening XWiki's structured objects and macros into Markdown. Expect macros, embedded applications, custom forms and structured data fields to need manual rebuilding, because a plain text conversion drops them. Run the conversion on a copy and produce a short report of pages that converted cleanly, pages that converted with loss and pages that failed. Confirm the conversion tooling with each vendor before relying on it.
Migrate attachments and revision history where tooling allows
Move attachments with their original file names, folders and links, then test whether page revision history can be imported. Page history is the part most likely to need a decision: some migrations keep the full history, some keep only the latest version as a baseline, and some keep the history as a read-only archive in the source. Record which option was chosen for each space. The output is a migration log that shows how many pages, attachments and revisions were moved, and any broken links flagged for repair. Ask each vendor directly whether revision history is importable and in what format.
Rebuild what does not transfer
Recreate the items that the conversion cannot carry across, such as custom macros, structured data layouts, search configuration, navigation menus, templates and scheduled notifications. Assign each rebuilt item to a named person and track it in the same inventory used at the start. The output is a closed list of manual work items, each with a reviewer, so that nothing is lost silently. Keep the source open during this step so that the original layout can be used as a reference.
Validate with a pilot group of users
Ask a small set of readers and editors from each team to test their most-used pages in the target. They should check formatting, images, internal links, search results, sign-in through the identity provider and whether their group can see and edit what it should. Log every defect with a severity and retest after fixes. The output is a signed sign-off from the pilot group for each space, along with a defect list that is either closed or accepted with a documented workaround.
Retire the source wiki
Once the pilot is accepted, set the source to read-only, keep a full export for the retention period your records policy requires, and redirect links where the platform allows. Then remove user access and decommission the server and database after a final backup is verified. The output is a retirement record that names the archive location, the date of the read-only switch and the owner who approved decommissioning. Confirm with your security and records teams what must be retained, because this depends on your own obligations rather than on either product.
What implementing each wiki involves and where projects run long
Implementing either wiki starts with the same decisions: where it runs, which database it uses, how people sign in, and who can see what. XWiki needs a Java application server, a supported database and an identity connection that the team confirms against the release line it selects. Wiki.js 2.x needs a Node.js runtime and a database, with PostgreSQL the recommended choice in the Wiki.js requirements. After that come permission design, content structure, templates, scheduled backups and an upgrade runbook. XWiki's page-level and hierarchy-level rights and its version history shape the design, so the permission map and space layout should be settled first. With Wiki.js, page path conventions and group-based access need the same early decisions, and they should be written down before any pages are created.
Projects usually run long in three places. The first is a permission model that was never written down. Teams assume a space or path hides content, then find that a group inherited rights from a parent or that an editor can delete pages a reader depends on. The second is a content migration from a file share, an older wiki or a document store where structure was never consistent. Headings, templates and page owners must be mapped by hand before anything moves. The third is upgrade planning across release branches. XWiki maintains several lines in parallel, including 16.10.19, 17.10.14 and 18.4.7, so the team must choose a line and a target date. Wiki.js 2.x follows its own cadence, and the 3.0 line is still in beta and marked not for production use, so any move to it is a separate project to confirm later.
The team carries most of the decision load. It must name an owner for each space or path, approve the permission matrix, decide which legacy content is retired, and grant access to the identity provider, the database host and the backup target before work begins. DeployOpen plans scope in writing before work starts, so the permission map, migration rules, upgrade target and handover checks should appear in the agreed scope and deliverables. Ask any implementer for a written list of what they expect from your staff, and ask how the upgrade runbook will be tested on a copy of production data. Cost follows that scope: setup and migration work is one-time, while upgrades and support recur if you buy a retainer.
Questions buyers ask before choosing or hiring help for XWiki or Wiki.js
What drives the cost of implementing XWiki or Wiki.js?
The main cost drivers are the size and structure of your existing content, the number of integrations, and how much custom work your authentication and permission model needs. Both platforms are free to download under open-source licenses, so the spend is almost entirely people: your internal staff time, and any external partner paid under a written, fixed scope. Ask any provider for a quote that separates one-time work (planning, migration, configuration, testing, documentation) from recurring work (upgrades, backups, monitoring, support). Ask whether the quote includes a named acceptance test for permissions and content, because that is where scope usually grows.
How long does it take to migrate an existing wiki?
Duration depends mostly on the volume of pages, how many page histories you must keep, how clean your existing permissions are, and whether content needs restructuring rather than a straight copy. Wiki.js 2.x stores content in a database and works best when pages are cleaned up before import, while XWiki's structured pages may need data mapping if you want to use its object model. No migration duration figure is supplied for either platform, so ask for a timeline based on a sample export from your own wiki, and confirm how page history and attachments will carry over.
What does my team have to provide during an engagement?
Expect to provide a named business owner who signs off on the information architecture, an administrator with access to the hosting environment, and an identity contact who can confirm how single sign-on and group membership should map to wiki rights. You will also need to supply a sample of real content for testing, a list of who can view, edit and delete which spaces, and an agreed backup and restore owner. Confirm these responsibilities in the written scope so that delays in access or sign-off do not become unpriced change requests.
Can my team run the wiki itself after launch?
Yes, if you have people who can handle the platform's upgrades, database maintenance, backups and restore tests, and access control reviews. Both projects are self-hosted, so you own patching in your environment. XWiki publishes several release branches in parallel, so you must choose which branch to follow and plan upgrades on that line. Wiki.js 2.x is the stable line, and its 3.0 work is still beta, so plan your own upgrade path. If you lack this capacity in-house, a retainer for upgrades, support and testing is one option, and the scope of that retainer should be written down.
Which database should I choose for Wiki.js?
Wiki.js 2.x supports PostgreSQL, which its requirements documentation recommends, along with MySQL, MariaDB, MS SQL and SQLite. Choose the database your organization already backs up, monitors and restores well, because that operational skill matters more over time than the initial install. SQLite suits small trials rather than production use with multiple editors. Confirm the exact versions and supported configurations for your target release with the Wiki.js requirements page before you commit, and ask your provider how database backups will be tested.
Can I use the Wiki.js 3.0 beta in production?
No. The 3.0 work lives in the main Wiki.js repository and is marked not for production use, so the stable choice today is the 2.x line, which is maintained in its own repository. Plan a path for the eventual move, including how you will test content and configuration against a new major version before switching. Ask any provider how they will handle that transition and whether it is in scope or a separate written change.
How do permissions differ between XWiki and Wiki.js?
XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, and it keeps page changes under version control, which suits organizations with complex access rules. Wiki.js is simpler in its permission model, so you should confirm that its rules meet your separation requirements before choosing it. Whichever platform you select, write a permission matrix, test it with real user accounts and groups, and keep the results as evidence for internal reviews. Note that DeployOpen prepares controls and evidence for compliance assessments, but independent auditors issue any assessment outcome.
How DeployOpen helps teams choose, implement and run a self-hosted wiki
DeployOpen helps teams decide between XWiki and Wiki.js by mapping editing style, permission model, database standard and maintenance capacity to the platform's actual release line. We then plan, build, document and hand over the chosen wiki inside your own cloud accounts, data centers or air-gapped network.
How we scope
- We confirm which XWiki release branch or Wiki.js 2.x line your team would run and why
- We record required identity sources, database engine and page permission structure in writing
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- We ask you to confirm the Wiki.js 3.0 production status before any upgrade plan is written
How we build
- We install the platform in your environment and connect it to your chosen sign-in provider
- We configure spaces, rights at wiki, page or hierarchy level, and content templates to your access model
- We test permissions, backups and restores against the scoped requirements before go-live
- We migrate existing content only within the agreed scope, with a verification step for each batch
How we hand over
- You receive installation, configuration and permission documentation written for your own administrators
- We document the upgrade path between release branches so your team knows what each step changes
- Handover includes a walkthrough of editing conventions for authors and rights administrators
- We prepare the evidence your compliance team needs to review wiki access and change history
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers
- Retainers can cover patching across the maintained branch you choose, with the scope agreed in writing
- We run security testing of the wiki and its integrations on a scope you define
- Support terms, response expectations and fees are set in the written quote, not published prices
