Why self-hosted IT documentation and runbooks need their own design
A self-hosted wiki can stay reachable during an outage only if it runs outside the infrastructure it documents and its access path does not depend on that infrastructure. Many teams keep recovery runbooks in a wiki hosted on the same cluster, the same identity provider and the same network they need to recover, so the document disappears exactly when it is needed. For simple, separately hosted runbook libraries, BookStack is the straightforward fit: it is MIT licensed, runs on PHP with MySQL 8.0 or MariaDB 10.6 or later, and organizes content into books and chapters that are easy to print or export. Where structured applications, enterprise support and fine-grained permissions matter, XWiki is the stronger candidate. Outline should be considered only after your legal team has checked its Business Source License 1.1 terms against your intended use, since that license restricts offering it as a commercial Document Service.
This page covers only what differs from a general wiki. Selecting a platform, structuring spaces, configuring single sign-on and migrating content are covered in the sibling pages and the requirements checklist, so they are not repeated here. The differences that matter for runbooks are hosting placement (a second instance or a separate failure domain, reachable from the networks on-call staff actually use), exports (a current, offline copy of every runbook in a format that opens without the wiki), on-call access (a break-glass path that works when the primary identity provider is down) and alert links (stable URLs that monitoring tools can embed in notifications).
Each of these decisions has a cost and an owner. Ask your team to name who maintains the secondary instance, how often offline exports are generated and tested, which accounts can sign in if the primary identity provider fails, and whether your monitoring platform can store and link to wiki URLs without depending on the wiki being up. If any of these answers is unclear, the design is not ready, regardless of which platform you select.
Requirements that shape a runbook wiki
This table lists the requirements that decide how a runbook wiki is hosted, accessed, versioned and retained, with the source of each one. Read each row as a design input: the source tells you whether the requirement is regulatory or internal, and the build column says what it changes. Regulatory rows apply only where the named rule covers your organization or the records in the wiki.
| Requirement | Source | What it means for the build |
|---|---|---|
| Recovery docs readable during cluster failure | Internal recovery constraint | Host the wiki outside the production cluster with its own database and backup path, so engineers can read recovery steps when the cluster is down. |
| Offline or exported copies of recovery procedures | Internal recovery constraint | Schedule regular exports of critical runbooks to storage outside the primary environment and confirm the export format can be read without the wiki running. |
| On-call access through the identity provider | Internal recovery constraint | Use SSO for daily access, but confirm the identity provider is not a single point of failure for recovery pages, since an outage there can lock out responders. |
| Break-glass access path | Internal recovery constraint | Keep a separately stored, audited local administrator or emergency account for the wiki, reviewed on a fixed schedule and tested before it is needed. |
| Version history for procedures | Internal recovery constraint | Keep page revisions with editor and timestamp, and confirm the platform lets reviewers compare and restore earlier revisions for operating procedures. |
| Audit of who changed or read sensitive runbooks | HIPAA 164.312(b) audit controls, where the wiki holds ePHI | Where runbooks describe systems holding ePHI, the wiki needs logs of access and changes that someone reviews. Where ePHI is absent, treat this as an internal control and confirm what the platform logs. |
| Transmission security for runbook access | HIPAA 164.312(e)(1), where the wiki holds ePHI | Encrypt all access paths, including admin and on-call connections, and confirm this applies to exports and attachments as well as the web interface. |
| Retention of communications and records | SEC 17a-4(b)(4), where a broker-dealer is in scope | This rule covers business communications for at least three years. Runbooks are generally not communications, so confirm with counsel whether any wiki content, comments or chat links fall under it before setting retention. |
Which platforms fit runbook and recovery documentation
Recovery documentation has to be readable during an outage, so the platform choice depends on where it runs, how people sign in when identity is down, and whether pages can be exported offline. The four options below differ mainly in license terms, hosting dependencies and how much structure they impose on runbooks.
BookStack for lean runbook libraries
BookStack is MIT licensed, with v26.09.1 published on September 29, 2026. It organizes content into books, chapters and pages, which suits a runbook library grouped by system. It needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and it provides official install scripts for Ubuntu 22.04, 24.04 and 26.04. It does not publish official Docker images, so a container setup depends on community maintenance. Check whether your team needs OIDC, SAML2 or LDAP sign-in for on-call access, and confirm how you will keep a copy of the database and attachments outside the main cluster.
XWiki for structured recovery procedures
XWiki is licensed under LGPL-2.1-or-later and offers a stable line, a long term support line and an intermediate LTS line, so you can choose a release cadence that fits change control. Its official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat. XWiki's structured data model suits runbooks with fixed fields such as owner, last test date and recovery time. Confirm which authentication features you need, since some connectors and SSO applications are listed under XWiki Pro. Also confirm how you will export pages for an offline copy that does not depend on the wiki server.
Outline and its license limit
Outline is licensed under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. A company documenting its own infrastructure is usually not offering that service, but the grant's wording should be reviewed by counsel before you adopt Outline for runbooks that may be shared with customers or managed-service clients. Outline 1.11.0 was published on October 12, 2026. Before choosing it, confirm the OIDC or SAML options, how search works when the wiki is degraded, and whether an offline export path exists.
Wiki.js 2.x for Git-based content
Wiki.js 2.x is licensed under AGPL-3.0, and the stable line lives in the requarks/wiki-v2 repository, with v2.5.316 published on October 2, 2026. The main requarks/wiki repository holds a 3.0 beta marked not for production use, so do not deploy it for recovery documentation. The 2.x line is a practical option if your team wants Markdown and Git-based review of runbooks. Confirm the authentication providers you need, how the database and content store are backed up, and whether an on-call engineer can reach the wiki without the main cluster.
How to host the wiki outside the main cluster
This sequence places the wiki in its own failure domain so that runbooks stay readable when the production cluster, its identity provider or its network is down. Each step produces a artifact or check that the team can verify in its own environment before an incident forces the question.
Define the failure domains the wiki must survive
The infrastructure lead lists what the wiki depends on and what it must still serve during an outage: the cluster, the primary identity provider, DNS, the primary network path and the main backup system. The output is a short dependency table that names each dependency and marks which ones the wiki must not share with the production environment. Confirm the list with the on-call team, because they know which runbooks they open first during an incident. The step is done when every shared dependency has either a documented alternative or an explicit, signed-off risk.
Provision a standalone host outside the cluster
The platform team deploys the wiki on its own virtual machines or a small standalone host in a separate account, hypervisor or availability zone, with its own network path and firewall rules. BookStack, for example, runs on PHP and a MySQL or MariaDB database, so the team should confirm that the database also lives on the standalone host rather than in the cluster. Check the vendor's current installation documentation for supported operating systems and database versions before building. The step is done when a test deployment serves a page with the production cluster powered off or isolated.
Separate the network path and DNS
The network engineer gives the standalone host a reachable address that does not route through the cluster's ingress, load balancer or service mesh, and confirms that on-call laptops and the monitoring system can reach it from outside the cluster network. The team should also decide on a stable DNS name that does not depend on the cluster's internal resolver. The output is a reachability test run from each on-call access point, recorded with the date and the network segment tested. The step is done when the test passes from the path on-call staff would really use, not only from the office network.
Schedule read-only exports of key runbooks
The operations lead chooses the runbooks that must be readable during a full outage, such as cluster recovery, database restore, identity provider fallback and network access steps. A scheduled job exports those pages in a readable format, such as HTML or Markdown with attachments, to storage outside the cluster and outside the wiki host. The export account should have read-only permission on the wiki, and the copies should be signed or checksummed so a reader can confirm they are current. Ask the vendor which export formats and API endpoints the chosen platform supports, and verify them in a test. The step is done when a fresh export opens offline on a device that has no access to the cluster.
Build a second identity path for break-glass access
The security lead configures a local administrator or a separate identity source that works when the main single sign-on provider is unavailable, and stores its credentials in a sealed, audited vault that the cluster does not control. BookStack, for instance, supports OIDC, SAML2 and LDAP sign-in, but the team must still confirm how a local account behaves when those sources fail, and how multi-factor authentication is handled for that account. Each break-glass account needs a named owner, a review date and a documented method for revoking it. The step is done when the team has logged in with the break-glass path on the standalone host during a test window and recorded the result.
Back up the wiki to a separate target
The backup engineer configures the standalone host to send database dumps, attachments and configuration files to a backup target that is separate from the cluster's backup system and protected by a different credential set. The retention period, encryption method and restore responsibilities should be written into the runbook itself. Test a restore into an empty environment, because a backup that has never been restored is not yet evidence of recoverability. The step is done when a restore test completes and the team has measured how long it took, using its own environment rather than a vendor estimate.
Link monitoring alerts to stable runbook URLs
The monitoring engineer adds a runbook link to each alert rule, pointing to a stable address on the standalone host or to the exported copy, so that the on-call engineer reaches the right procedure from the alert itself. The links should use a fixed path that is not reorganized when pages move, and the alert template should state which copy to open if the wiki is unreachable. Test the links by firing a test alert from a monitoring system that is itself outside the cluster, if one exists. The step is done when a test alert from each monitored system opens the correct runbook on a device that is off the cluster network.
Rehearse the outage and record the gaps
The incident commander runs a tabletop exercise in which the cluster and primary identity provider are treated as unavailable, and the on-call team uses only the standalone wiki, the exported copies and the break-glass account to follow a recovery runbook. The exercise lists every step where someone was blocked, missing a page, or relying on an assumption about the cluster. Those findings go back into the dependency table and the runbook set, and the exercise repeats on a schedule the organization sets. The step is done when the gap list has an owner and a date for each item and the next exercise is on the calendar.
Who needs access to runbooks, and how it differs by role
On-call engineers need to read a runbook quickly, often from a phone or a laptop on a hotel network, while a service is down. Their access should be read-only by default, with search that works without the main cluster, and with a clearly documented path for the rare case where the normal login is unavailable. Both BookStack and XWiki support role-based permissions, so read access for on-call groups can be granted per shelf, book or space without giving them edit rights.
- Read-only default: Grant the on-call group view rights on runbook shelves or spaces and keep edit rights with the owners.
- Fast search during incidents: Confirm that search is served from the wiki host itself, not from a third-party service, and test it with the cluster degraded.
- Break-glass access: Keep a local administrator or emergency account stored outside the identity provider, with credentials held in a sealed process and every use logged.
- Multi-factor sign-in: BookStack offers built-in multi-factor authentication that can be enforced per role. Confirm how the on-call group signs in when the identity provider is unavailable.
- Offline copies: Keep exported PDFs or static copies of critical recovery procedures on a separate host, and state which copy is authoritative.
Check with the platform team which accounts can still sign in during an identity outage, and run a drill that starts from a locked-out on-call engineer.
Runbook owners write, update and approve procedures for the systems they run. They need edit rights limited to their own shelves or spaces, and a review step that makes an unreviewed change visible. Neither BookStack nor XWiki should be treated as providing a formal approval workflow out of the box, so the approval process is usually a combination of page permissions, page history and a sign-off recorded in a template or change record. Confirm the exact capabilities against the installed version.
- Scoped editing: Assign edit rights per book or space to the owning team, so a database team cannot rewrite network recovery steps by accident.
- Version history: Both platforms keep page revisions, which lets owners compare a change against the last approved version during a review.
- Review metadata: Add a page template with an owner, a review date and an approver field, and make the review date part of the regular maintenance cycle.
- Separate draft space: Use a draft shelf or a restricted space for pages that are not yet approved, so on-call staff do not follow unverified steps.
- Editor and format choices: BookStack offers a WYSIWYG editor with an optional Markdown editor, which matters for teams that keep procedures in version control.
Ask the platform team how the approval step is enforced in practice, and whether the chosen platform or an extension provides it, rather than assuming the wiki enforces it.
Security staff and auditors need to answer questions such as who could read a recovery procedure, who changed it, and when. They usually need read access across all runbook spaces, plus the ability to review page history and the platform's activity records, without the ability to change content. That read-only audit role should be deliberately created, not borrowed from an administrator account, so the evidence shows that reviewers did not alter what they were reviewing.
- Read-only audit role: Create a role with view and history rights across runbook spaces, and no edit or delete rights.
- Page history: Use page revisions to show what a procedure said at a given date, which supports the sign-off trail of each change.
- Activity and access logs: Confirm which activity records the chosen platform keeps, how long they are retained, and whether they can be exported to a central log system. Access logs at the web server and database layer should also be retained.
- Audit controls mapping: Where a regulation requires audit controls over systems that hold sensitive information, the HIPAA Security Rule at 45 CFR 164.312(b) asks for mechanisms that record and examine activity, so the wiki's logs need to be part of that design.
- Permission reports: Export a list of who can read each shelf or space on a schedule, and keep the report with the review record.
Confirm with the auditor which evidence they will ask for, and test that the chosen platform can produce it without manual database queries.
Contractors and managed service vendors often need to read or update runbooks for the systems they support. Their access should be limited to the spaces that cover their work, time-bound where the process allows it, and separated from employee accounts so that their activity is easy to identify and remove. Because the wiki may describe recovery steps for the whole environment, the default for external accounts should be narrower than the default for staff.
- Scoped spaces: Place vendor-relevant runbooks in a dedicated shelf or space, and keep unrelated infrastructure documentation out of their reach.
- Separate identity: Keep external users in a distinct group in the identity provider so that group membership can be reviewed and removed in one step.
- Removal process: Define how access ends when a contract ends, and check that disabling the identity provider account also blocks wiki sign-in, including any local accounts.
- Local accounts: Confirm whether the platform allows local accounts for external users and, if it does, whether they can be disabled centrally.
- Attribution: Require vendors to use named accounts, not shared logins, so page history shows which person made each edit.
Ask the vendor which of their staff will hold accounts and whether those accounts can be traced to a named individual in the contract.
Evidence that recovery documentation can produce for auditors
How do I prove a recovery procedure was current when an incident happened?
Page version history is the primary evidence: each saved revision of a runbook records who changed it, when, and what the content said at that point, so you can show the procedure in force on a given date. BookStack and XWiki both keep page revisions, and Outline does as well, but the depth of history, how long it is retained, and whether you can export it in a readable form should be confirmed in the version you deploy. Ask the partner to demonstrate restoring a prior revision of a runbook, showing the author, timestamp and diff, and to show where that history lives if the wiki database is restored from backup. Keep in mind that history only proves what was written, not that anyone followed it.
What approval records should a runbook carry for audit purposes?
Approval is usually recorded through a documented review step, such as a status field, a review date on the page, or a named approver in a page or chapter template, combined with the version history showing when the approval was made. Most open-source wikis do not provide a native formal sign-off workflow, so confirm with the partner whether approval is handled by page conventions, a built-in or extension feature in your chosen platform, or a ticket in your ITSM tool linked from the runbook. Ask the partner to demonstrate a runbook moving from draft to approved, with the approver identity and date visible on the page and in the history.
Can access logs show who opened a sensitive runbook?
Access logging depends on what the wiki records, which varies by platform and version, so confirm it before promising it to an auditor. Typical sources are the application's activity log, the web server or reverse proxy access log, and the identity provider's sign-in log, which together show who authenticated and which pages were requested. For sensitive runbooks, such as break-glass or privileged recovery steps, ask the partner to restrict those pages to a named group, enable multi-factor authentication for that role, and demonstrate a log entry for a read event. If ePHI is in scope for the systems a runbook covers, HIPAA 164.312(b) requires audit controls that record and examine activity in those systems, so the logging design should be reviewed against that requirement with your compliance lead.
What backup and export records prove the wiki content can be recovered?
The evidence is a set of dated backup job records, the checksum or integrity result of each backup, and a documented export of the content in a format that does not depend on the running application. Backups of the wiki should cover the database, the attachments and uploaded files, and the configuration, and should be stored outside the main cluster so a cluster failure does not remove both the wiki and its copies. Ask the partner to show the backup schedule, the retention rule applied to each copy, a successful backup log, and an export of a sample space produced without logging into the live application. Confirm the exact export formats each platform offers in your version, since capabilities differ between BookStack, Outline and XWiki.
How do I show that the restore procedure has been tested?
Tested restore evidence is a dated record from a recovery exercise showing that the wiki was rebuilt from a backup, that the runbooks it held were readable, and that the time taken and the problems found were written down. This evidence is more persuasive than backup logs alone because it proves the chain works end to end. Ask the partner to run a restore into an isolated environment, record the steps and outcome in the wiki or a linked ticket, and show the list of corrections made to the procedure afterwards. The exercise should also confirm that the wiki stays reachable when the main cluster is down, which is the core purpose of hosting it separately.
Which retention settings should apply to runbooks, history and logs?
Retention rules set how long each class of evidence is kept, and they need to be decided with your compliance and legal teams before deployment. Runbooks, page revisions, backups and access logs may each have a different period, and some are governed by regulation. For example, SEC Rule 17a-4(b)(4) requires broker-dealers to preserve communications relating to the business for not less than three years, which applies to communications rather than runbooks but shows how retention periods are set by rule. Ask the partner to configure and demonstrate retention for each evidence class, to show how old backups are expired and how page history is pruned or kept, and to document the decisions in writing so an auditor can trace them.
Who is responsible for producing this evidence after go-live?
Your team owns the evidence, the partner can design and set it up, and the operating routine decides whether it stays complete. Setup work, such as configuring backups, retention, logging and the restore exercise, is one-time, while reviewing logs, running restore tests on a schedule and reviewing approvals are recurring tasks that either your staff or a support retainer must cover. DeployOpen plans, implements, backs up, documents and supports self-hosted platforms in your own infrastructure, and it prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Ask for a written split of responsibilities and a schedule of recurring tasks in your quote.
What changes when the runbook wiki must work during an outage
A runbook wiki is different from a general wiki because its own availability becomes part of the recovery path. When the cluster, identity provider or network is down, the people who need the recovery steps are often the same people who cannot reach the wiki. The first design decision is therefore where the wiki runs. Host it outside the production cluster, on separate compute and storage, and confirm that on-call staff can reach it from networks and devices that do not depend on the corporate directory. Ask the vendor or your own platform team which login paths still work if the primary identity provider is unavailable, and test that path before you rely on it. A runbook wiki that depends on the same single sign-on it documents will fail when you need it most.
Search, rendering and attachments must also work without external services. BookStack and XWiki both store content in their own database and file store, but features that call out to third parties, such as hosted diagram services, remote fonts, external scripts or cloud-based search, can fail silently. Check each page type you plan to use, including the diagrams.net integration BookStack offers, and confirm that the editor and viewer load from local assets. Keep a read-only copy of the most critical runbooks in a format that opens without the application, such as PDF or plain Markdown, and store it in a second location with its own access path. Confirm with the vendor how exports handle embedded diagrams and internal links, because a link that resolves inside the wiki may break in an exported file.
Upgrades are the final risk. A wiki update that changes the database schema, authentication settings or the attachment storage path can leave recovery pages unreadable at the moment a team needs them. Before any upgrade, test the restore procedure against a copy of the production database and files, and verify that the runbooks still render, search and export. Keep the previous release and its configuration available for rollback. Confirm the supported PHP, database and operating system versions for your chosen release line, and review the release notes for changes to login, permissions or file handling. The goal is a wiki that stays readable through an incident, which is a different target from one that merely stays current.
How the rollout moves a runbook wiki into production
The sequence starts from an inventory of what exists and who owns it, then builds a wiki that stays reachable when the main environment is down. Each phase closes with a concrete output the operations team can verify.
Inventory existing runbooks and owners
Collect every infrastructure document, on-call runbook and recovery procedure from wikis, shared drives, ticket notes and individual laptops. Record for each one the system it covers, the named owner, the last review date and where the only copy currently lives. The IT operations lead and service owners do this work, with the platform team confirming which systems are in scope. The step is done when every critical service has a listed runbook, an owner who has accepted it, and a short list of gaps where no procedure exists yet.
Decide the platform and design separate hosting
Choose the wiki platform against the requirements from the inventory, such as authentication options, export tooling and the license terms your operations team can live with. Then design where the wiki runs, deliberately outside the production cluster and its shared identity and DNS dependencies, with its own backup target and a documented path to restore it. Ask the implementation partner to show the failure modes they tested for this design. The step is done when the architecture diagram, hosting location and recovery path are signed off by the infrastructure and security leads.
Set up identity and break-glass access
Connect the wiki to your directory through the sign-in method your identity team supports, and map directory groups to editor, reader and administrator roles. Separately, create a small set of local break-glass accounts with strong credentials, stored in a sealed custody process, that work when the directory is unavailable. Test both paths from a network segment that mirrors how on-call staff connect during an incident. The step is done when an on-call engineer can sign in with the directory down and an administrator can confirm who holds break-glass credentials and when they were last rotated.
Migrate the highest-priority procedures first
Move the runbooks ranked highest in the inventory first, typically those for identity, networking, backup and the services that page people at night. Rewrite each procedure into a fixed template with prerequisites, exact commands, expected output, rollback steps and escalation contacts, and keep the original page history where the source supports it. A second engineer who did not write the procedure executes the steps in a non-production environment. The step is done when each priority runbook has passed that peer walk-through and carries a named owner.
Link runbooks from monitoring alerts
Add a stable URL for each runbook to the alert definitions in your monitoring and paging tools, so the on-call engineer reaches the procedure from the notification itself. Confirm that the links resolve from the paging device and from a network path that does not depend on the production cluster. Verify the mapping with the monitoring team, since alert rules and runbook names drift over time. The step is done when a test alert in each priority category opens the correct procedure from a phone or laptop without needing a search.
Recover a service using only the wiki and export
Run a planned exercise in which a team restores a non-critical service in a test environment, working only from the runbooks and an offline export of the wiki. Give the team no access to the live wiki during the exercise, and have an observer record every point where they needed information the documents did not contain. Use the export format and storage location documented in the hosting design so the exercise also checks that path. The step is done when the service is restored, the gaps are logged as corrections with owners, and the exercise record is stored with the runbook set.
Hand over with owners and review schedule
Transfer operation of the wiki to the internal platform team along with the runbook ownership model, including who approves changes, who can publish to recovery procedures and how stale pages are flagged. Agree a review cadence for each owner with the IT leadership, and set up notifications for pages that pass their review date. If a partner delivered the rollout, confirm in writing which upgrade, backup and support tasks it continues to own. The step is done when every runbook shows an owner and next review date, the operations team has run one backup and restore, and the handover document is accepted.
Questions to ask an implementation partner about runbook hosting
Start with placement. Ask the partner to show, in writing, where the wiki runs relative to the production cluster, which accounts or network segments it depends on, and what happens to its DNS name, certificates and database when the main cluster, its ingress or its identity provider is down. A runbook host that shares a control plane, storage class or backup job with the systems it documents will fail in the same incident. Ask for the dependency diagram and for the failure scenarios the partner has already tested against it. Confirm which BookStack or XWiki database engine is used, since the supported database versions are listed in the installation documentation for each platform, and ask who patches that database on the same schedule as the application.
Next, ask how exports are produced and proven to work. A readable copy of every runbook should exist outside the wiki's own database, on storage that on-call staff can open from a laptop with no login to the wiki. Ask the partner which export format is generated, how often, where it is written, and who restores it in a drill. Ask how break-glass access works when the primary identity provider is unavailable: which local account exists, where its credentials are stored, who can release them, how each use is logged and how the account is disabled afterward. Request the written procedure and the date of the last test. Verbal assurance on either point is not evidence.
Finally, ask for proof that alert links and recovery procedures survive upgrades and incidents. Monitoring rules should point to stable URLs or redirects that the partner keeps under change control, and the upgrade runbook should check that every link in the top alert set still resolves after each release. Ask how page history and access logs are retained, for how long, and whether they are shipped off the wiki host. Then ask for a recovery test in which an engineer rebuilds a failed service using only the wiki and the exported copy, with the time taken and the gaps found written up. Ask the partner to confirm which retention periods apply to your own regulation, since those are your decision and not a vendor setting.
Questions buyers ask before hiring help for IT runbooks
What drives the cost of a self-hosted IT documentation project?
The main drivers are the platform choice, how far the wiki is separated from the main cluster, how much identity integration is required, and how much content must be migrated. A wiki that runs on a standalone host with a single local account needs far less work than one that must sit on separate infrastructure, sign in through your directory, and carry years of exported pages. Cost has one-time parts (design, installation, integration, migration, exercise of recovery procedures) and recurring parts (hosting, patching, upgrades, support). Ask for a quote that lists each of these as a separate line tied to the written scope. DeployOpen does not publish a price list, so the quote follows from that scope.
Can our team set up a runbook wiki without outside help?
Yes, a small team with Linux and database experience can install BookStack or XWiki, but the hard parts are the ones around the install. BookStack's official installation scripts cover Ubuntu 26.04, 24.04 and 22.04, and it requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later. The work that usually needs experienced help is placing the wiki outside the main cluster, wiring its sign-in to your identity provider without locking out on-call staff, setting up backups that can be restored on a separate host, and proving that a recovery exercise works. Decide which of these your team can own before you start.
How long does a runbook wiki implementation take?
The timeline depends on scope, and the figure comes from the written scope agreed before work starts, not from a generic estimate. The main variables are the number of hosts and environments, whether identity integration is included, how many pages must be migrated and cleaned up, and how many exercises the team wants to run before go-live. A single-host wiki with local accounts and a short list of runbooks is a different project from a separated, SSO-enabled deployment with a Confluence import. Ask DeployOpen to break the timeline into phases with a named deliverable for each.
What does our team need to contribute to the project?
The project needs people from three groups, and their time should be planned in advance. Runbook owners must review and approve the procedures that will be migrated or written, because an outdated runbook is worse than none. Identity administrators must provide the directory groups, the sign-in protocol details and a break-glass account plan. Operations staff must schedule an exercise window in which on-call engineers follow the recovery steps on a clean environment and report what failed. Confirm the names and availability of these people during scoping, since delays usually come from review and access, not from installation.
Do we need XWiki Pro or a support plan for runbooks?
Not necessarily. XWiki Standard is the free open source version, and BookStack is MIT licensed with no paid edition required to run it. A paid plan becomes relevant when you need XWiki Pro applications, vendor support with response commitments, or consulting from XWiki SAS. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. Support tiers are Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). Confirm the current terms on XWiki's pricing page before comparing options, since vendor pricing can change.
What are the limits of migrating Confluence runbooks?
Migration preserves the content you export, but it does not preserve every feature exactly. XWiki's Confluence Migrator Pro moves spaces, pages, users, groups, permissions, attachments and metadata, and it keeps page history but not attachment history. Its trial is limited to 30 pages per migration, and the paid tool is priced from 2000 EUR according to XWiki's store listing. Macros, page links and permission models often need manual rework, and stale runbooks should be retired rather than carried over. Ask the partner to run a sample migration of your most critical procedures and check each one against the original before the cutover.
Is Outline a safe choice for an internal runbook wiki?
Check the license before you commit, because Outline is licensed under the Business Source License 1.1, not an open source license in the usual sense. Its additional use grant forbids using Outline to offer a commercial Document Service, so an internal wiki for your own staff is a different case from a hosted product sold to customers. Have your legal or licensing reviewer confirm how your use fits the grant, including any affiliates and contractors who will use it. If the answer is unclear, compare BookStack (MIT) or XWiki (LGPL-2.1-or-later) for the same workload.
How are upgrades and security patches handled after go-live?
Upgrades are a recurring responsibility, and the plan should be written down before launch. Each platform publishes its own release cadence: BookStack v26.09.1 was published on September 29, 2026, and XWiki publishes stable and LTS lines, with LTS tags such as 17.10.14 and 18.4.7 at the time of research. Choose a line that matches how often you can afford to test and restart, and keep a staging copy so you can rehearse upgrades. Ask the partner who performs patching, how backups are verified before each upgrade, and how a rollback is tested. Ongoing upgrades and testing can be covered by a retainer defined in writing.
How DeployOpen scopes and supports a runbook wiki
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, which is where a runbook wiki has to live if it is to stay reachable during an outage. The work starts with a written scope that defines which runbooks, hosting location and access paths are covered before any installation begins.
How we scope
- Inventory which infrastructure, on-call and recovery procedures must remain readable during a cluster or network failure.
- Define the hosting location outside the main cluster, along with its network path, backup target and administrator accounts.
- Agree in writing which alert links, export formats, identity integrations and content migrations are included, since engagements are fixed-scope.
How we build
- Install the chosen wiki platform on separate infrastructure, with its database, storage and backups documented as their own components.
- Configure sign-in for on-call staff through the client's identity provider, with a tested break-glass access path that does not depend on the main cluster.
- Set up page structure, permissions and templates for runbooks, then test that alert links resolve and that exports open without the wiki running.
How we hand over
- Document the architecture, failure scenarios, restore steps and the owner for each runbook section in the handover pack.
- Run a recovery exercise with the client's operators to confirm that the runbooks can be reached and read during a simulated outage.
- Provide a schedule of scheduled exports and access reviews that the client's own team can continue to run after handover.
How we support
- Apply platform upgrades and security updates on a schedule agreed in the retainer, with test results recorded before each change.
- Repeat the recovery exercise after significant changes to the cluster, identity provider or alerting tools.
- Keep the documentation of the setup current, so that retained runbook evidence stays accurate for internal and external reviewers.
