Self-Hosting Turns Your Team Into the Knowledge Base’s Service Provider

A company self-hosts its knowledge base because policy documents cannot leave its network. Once the migration is finished, the location question has a clean answer. The harder questions arrive later.

An employee moves to another team but keeps access to the old space. A policy is revised, and six months later someone needs the wording that was approved before the change. Then a storage failure leaves the Wiki running without its attachments. None of these problems is fixed by knowing which server holds the data.

After self-hosting, the permission review and the restore rehearsal both land in the organization’s operating queue.

Access keeps changing after the deployment is finished

Permissions are correct only for a moment. People change roles, temporary reviewers finish their work, and pages move inside the knowledge base.

Take a policy page shared with an external auditor. View-only access may be appropriate during the review. When the review ends, nothing about the self-hosted network removes that permission. Someone needs to close it as part of the work, just as they would close an account during offboarding.

The page tree can complicate the review. A shared parent may expose its subpages; moving a page under a different parent can put it under another set of rules. View and edit access therefore need another look when the structure changes.

This is ordinary administration, but it is easy to miss because the server is behaving normally. The mistake appears only when the wrong person opens the right page.

A policy review needs the old page

Suppose a security policy was updated in May. During a later review, the useful question is not “who used the admin console?” It is “what did this page say before the May release?”

That answer should come from the page itself. A useful version history lets the reviewer open an earlier release and compare it with the current one. Chat messages may explain why an edit happened, but they are a poor substitute for the actual text that was in force.

For this review, page history is the relevant record. Each released version is saved, two versions can be compared, and an editor can return to an earlier one. That is enough to answer a page-level change question without exporting unrelated logs.

Reversion solves a content mistake. It does not help when the service has lost the stored page altogether.

The first real backup test starts with a restore

A green backup status shows that a scheduled job finished. It says little about what happens when the team has to rebuild the service.

Knowledge bases often keep different parts of the service in different places. The application and its database may be covered by one procedure while uploaded files live in external object storage. Restoring only the first part can bring back page records whose attachments no longer open.

The recovery runbook needs to follow the data across that split, and the team needs to practice it before production. When attachments sit in external storage, their backup and recovery remain with the team operating that storage.

A rehearsal is where missing credentials, an undocumented storage step, or an incomplete set of files becomes visible. Waiting for an outage to discover those gaps turns a backup configuration problem into lost access to the knowledge base.

What this boundary looks like in one product

An ONES air-gapped deployment keeps the service inside the organization’s infrastructure. Wiki-space permissions and page history remain available inside that boundary, while the deployment documentation distinguishes between built-in storage recovery and storage supplied by the customer.

Return to the auditor’s policy page. Its version history preserves the old wording, and its permissions enforce the access an administrator selected. When the engagement ends, however, the system does not know that the account should be removed. If the page refers to files in external storage, the deployment team also needs that storage in its recovery procedure.

If the auditor account is still open or the restored page has no attachments, the deployment is not finished just because the application is back online.