Knowledge base in air-gapped networks

Images reach the wiki through an internal container registry mirror that your team fills from an approved transfer path. Kubernetes clusters can be built without internet access: kubeadm config images list and kubeadm config images pull fetch the control plane images ahead of time, and the --image-repository flag points kubeadm init at a private registry. The wiki's own images, such as XWiki or BookStack, need the same treatment, so every tag is copied, scanned and pinned by digest before it enters the enclave. Confirm which registry product is approved, who signs off on each import, and how image versions are recorded for later rollback.

Extensions, themes and plugins must be downloaded outside the enclave, checked, and carried in as versioned packages. Many wikis install add-ons from public repositories at runtime, so the offline build has to be a fixed set of artifacts with recorded checksums. Confirm which extensions the business needs, their licenses, whether they run server-side code, and who approves a new package. For XWiki, the OIDC authenticator is maintained in the xwiki-contrib organization, so check its release and license before importing it. Plan for a documented update path that repeats the same review each time an extension changes.

The wiki should authenticate against the identity provider already inside the enclave, usually through SAML, OIDC or LDAP. Because the identity service sits in the same network, no external sign-in service is needed, but the wiki must reach it on the correct internal hostnames and certificates. Confirm which protocol your identity platform offers, how the trusted certificate authority is distributed to the wiki server, how directory groups map to wiki roles, and what happens to access when the identity service is down. Also confirm whether break-glass local accounts are allowed and who controls them.

The database, attachments and backups should all stay inside the enclave, and backup copies should follow the same retention and transfer rules as the wiki itself. XWiki's official Docker images come in MySQL, PostgreSQL and MariaDB variants, so the database engine choice affects which backup tools and restore steps you need. Confirm the backup schedule, where backups are stored, whether a second enclave or site holds an encrypted copy, and how restores are tested. Ask who performs restores and whether the restore procedure has been rehearsed on a non-production copy.

On-call and recovery staff need a read-only copy of critical runbooks and procedures that does not depend on the main wiki cluster. Typical options are a scheduled export to a static format, a separate read-only instance on different hardware, or printed copies kept at the site. Keep the copy small, versioned and reviewed, and make sure it can be opened without the wiki's database. Confirm which pages belong in the recovery set, how often the export is refreshed, who can access it during an outage, and how the team proves the copy is current. The same design also keeps runbooks readable when the identity service is unavailable.

Logs from the wiki, its database, the identity integration and the host should be forwarded to a log platform inside the enclave, so that access and change events remain available for review. Audit controls matter for regulated workloads: the HIPAA Security Rule at 45 CFR 164.312(b) calls for audit controls that record and examine activity in systems containing ePHI. Confirm which events the wiki logs, such as page views, permission changes and login failures, how long they are kept, where they are stored, and who reviews them. Also confirm whether monitoring alerts reach staff through a path that works when the wiki is down.

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an isolated wiki, that work covers the registry and image path, extension packaging, identity integration, database and backup design, the recovery copy, and log export. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for a written list of integration points, the environment assumptions behind them, and the acceptance tests that will show each one works.

The software license is often the smallest line item, because BookStack is MIT licensed and XWiki Standard is free open source. The cost comes from who does the work: consulting days, migration tooling, support subscriptions, hosting inside your network and staff time to run it. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. Confluence Migrator Pro is priced from 2000 EUR and has a trial limited to 30 pages per migration. Ask any partner for a quote that separates one-time work (design, installation, migration, hardening) from recurring work (support, upgrades, backups, monitoring), and state which license tier each line depends on.

The duration depends on scope, not on the platform alone. The main variables are how many spaces and pages you are migrating, whether you need Confluence history and attachments, how many identity sources must be connected, and how many approval steps your change process requires inside a restricted network. Because transfer media, package review and maintenance windows all add time, ask for a written timeline tied to named milestones and to the systems the team must provide. Treat any duration given without a stated scope as a sales estimate, not a commitment.

Three groups of people carry most of the work. Identity administrators provide the directory connection, group mappings and the single sign-on configuration, which is the step most likely to stall in an isolated network. Content owners decide which spaces are migrated, archived or rewritten, and they approve permissions for each space. Network staff own the transfer path across the gap, including media handling, checksum verification of every package and any firewall or proxy exceptions. Name a person in each group before the statement of work is signed, because delays usually come from unavailable approvers rather than from the software.

Yes, if you have people who can operate a Java or PHP web application, a relational database, a reverse proxy and a backup process, and who can carry out offline upgrades. BookStack and XWiki both publish installation paths that can be followed without internet access, but offline install, extension handling and search configuration still need hands-on testing in your environment. A partner is most useful for the parts that are hard to repeat: a tested transfer procedure, hardening, migration and documentation of the runbook. Whichever path you choose, confirm the vendor's current offline install steps with your own test environment before you rely on them.

Air-gapped deployment is often reserved for paid editions, so check the tier before you choose the platform. Mattermost lists air-gapped deployment in its Enterprise Advanced plan, Rocket.Chat excludes it from the free Starter plan, and Metabase offers it only on its Enterprise plan. Element Server Suite has a free AGPL Community edition, a Pro edition and a Sovereign edition for air-gapped deployments. For wikis, XWiki Pro and its support subscriptions add business applications, connectors and SAML or OIDC-related features, and XWiki SAS states that cloud and on-premises pricing is the same. Ask each vendor in writing which features and update channels your tier includes while disconnected.

Upgrades arrive as a verified package set that is downloaded outside the isolated network, scanned, checksummed and moved through an approved transfer path. The set should include the application release, the matching extension versions, container or package images and the database migration notes. Test every set on a staging copy that mirrors production before it enters the protected network, and keep the previous release available for rollback. Supply chain requirements such as NERC CIP-013-2 expect you to verify software integrity and authenticity for vendor software and patches, so record who approved each transfer. Confirm with the vendor whether a given release supports offline upgrades and how security fixes are published.

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so independent auditors remain responsible for those.