Why a self-hosted knowledge base for manufacturing differs from office wikis
A self-hosted knowledge base for manufacturing has to make sure that the person at the line sees the approved version of a work instruction, and that nobody else can quietly use an old one. In most plants, SOPs live in shared drives, printed binders and laminated cards, and the operations manager cannot easily prove which revision is in front of an operator. The hard parts are version approval, shop-floor access, OT network segmentation and translations, and none of them is solved by picking a wiki product. The wiki is the easy part. The design decisions are who approves a revision, how a superseded procedure is withdrawn from every station, which devices can read the library, and how a German, Polish or Mandarin translation is tied to the English source it came from.
On the platform side, XWiki is the stronger fit where approval workflows, structured page applications and multi-department permissions matter, because it is built around structured content and offers the most room to model controlled documents. BookStack suits plants that need a simpler procedure library with clear books and chapters and less administrative overhead. Outline should be considered only where its Business Source License 1.1 fits the intended use. Its additional use grant forbids offering a commercial Document Service, so legal review is needed before a plant or an integrator relies on it. Confirm the chosen platform's approval and revision features against your own document control procedure before committing, because feature sets change between releases.
Which requirements shape a manufacturing wiki build
This table maps each regulation or standard that touches plant documentation to what it means for the wiki itself. Read each row as a question to answer before design: which source applies to your plant, and what must the wiki record, segment or keep available. The main takeaway is that the wiki is an information system beside the control network, not part of it.
| Requirement source | What it asks of the wiki | Evidence to keep or confirm |
|---|---|---|
| NIS2 Annex II (manufacturing scope) | Manufacturing in NACE Rev. 2 divisions 26 to 30 is a critical sector. If in scope, incidents affecting the wiki must follow the 24-hour early warning, 72-hour notification and one-month final report clock. | Incident runbook naming the wiki as a service, reporting owner, and contact path. Confirm entity classification with counsel. |
| Machinery Regulation (EU) 2023/1230, Annex III 1.1.9 | Applies from 14 January 2027. Machinery must resist hazardous outcomes when another or remote device connects. A wiki that pushes content to machines or HMIs must not create that connection path. | Interface inventory showing the wiki has no write path to machine controls. Confirm with the machinery manufacturer or notified body. |
| ISA/IEC 62443 series (asset owner requirements) | ANSI/ISA-62443-2-1-2024 expects asset owners to manage the security program around IACS. Treat the wiki as a supporting IT zone with its own conduit rules, separate from control zones. | Zone and conduit diagram, asset inventory entry for the wiki, and documented boundary rules. Confirm zone placement with your 62443 practitioner. |
| NIST SP 800-82 Rev. 3 (OT security) | Covers OT performance, reliability and safety. Plant documents must stay readable during network isolation, so the wiki needs offline copies and no runtime dependency on OT systems. | Offline export schedule, restore test log, and documented behavior when the plant network is segmented. |
| ISA-62443-3-3 and MITRE ATT&CK for ICS (threat context) | Segmentation and access controls around IACS protect the wiki from becoming a pivot point. Limit read access from shop-floor devices and log administrative actions. | Firewall rules between IT and OT, role-based access list, and audit log of edits and logins. |
| 21 CFR Part 11 (regulated product records) | Where SOPs support regulated records, the wiki needs controlled versions, a traceable audit trail of who changed what and when, and electronic signature controls where approval is required. | Version approval workflow, audit trail sample, and signature policy. Confirm whether your wiki features meet your validation plan. |
| Retention and recordkeeping (e.g., SEC 17a-4 or sector rules) | Retention depends on the sector and product. Keep superseded SOP versions for the period your regulator or quality system requires, and do not rely on the wiki alone for legal holds. | Retention schedule per document class, backup restore evidence, and confirmation of the period from your quality or legal lead. |
Which wiki fits which plant scenario
Plants with many related SOP families, multiple sites and formal approval steps usually need a wiki that models structure in data, not just in pages. XWiki fits this pattern because it supports structured applications, fine-grained rights and multi-space layouts, so a single SOP template can serve several lines or plants while each site keeps its own owners. Its Pro edition adds business applications and directory connectors such as Active Directory and Azure Active Directory SSO, and the Confluence Migrator Pro extension from XWiki SAS is priced from 2000 EUR with a trial limited to 30 pages per migration, which matters if you are leaving Confluence.
- Multi-plant spaces: Separate spaces per plant with shared templates and controlled cross-links.
- Pro features: Directory SSO and connectors are listed on the XWiki Pro page, so confirm which ones your identity provider needs.
- Migration cost: Confluence Migrator Pro is priced from 2000 EUR, and its trial covers only 30 pages per migration, so budget a test run on real SOPs.
- Migration limits: The tool keeps page history but not attachment history, which affects controlled revisions of drawings and forms.
- Support scope: XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise plans, and training at 1500 EUR per day.
Before committing, confirm with the vendor which features your approval workflow and directory setup require, and whether attachment history must be preserved for your quality records.
Smaller plants or single lines often need a simple, readable library of work instructions with a clear shelf and book hierarchy and minimal administration. BookStack is licensed under MIT and its shelves, books and chapters map directly to how operators look for instructions, which keeps training on the platform short. Its low structural overhead also means fewer moving parts to maintain, but it offers less built-in data modeling than XWiki for controlled SOP families.
- Simple hierarchy: Shelves for areas, books for lines, pages for individual instructions.
- License freedom: MIT terms allow internal use and modification without a commercial service restriction.
- Current release: BookStack v26.09.1 was published on September 29, 2026, so check the release notes before pinning a version.
- Structure limits: If you need structured approval states across many SOP families, plan that process outside the wiki or choose XWiki.
- Operator access: Confirm that shop-floor browsers and kiosks render pages acceptably on the devices you plan to use.
Before choosing BookStack, check whether your review cycles can be enforced by process alone, since the platform will not impose them for you.
Some organizations consider Outline for its editing experience, but its license needs a careful reading. Outline is licensed under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. For an internal plant wiki, that restriction usually does not apply, but a manufacturer that hosts documentation for customers, suppliers or contract partners as a service should have counsel confirm the boundary before adopting it. Outline 1.11.0 was published on October 12, 2026.
- Internal use: Confirm with counsel that the plant wiki is an internal business use and not a commercial Document Service.
- Customer-facing manuals: Publishing service documentation to external parties may fall outside the grant.
- Version pinning: Outline 1.11.0 was published on October 12, 2026, so record the version you validate.
- Integration review: Check authentication and storage requirements against your identity and quality system design.
- Exit planning: Document how you would move content to another platform if the license position changes.
Before selecting Outline, obtain a written license opinion for your exact use, including any supplier or contractor access to the wiki.
XWiki's official Docker images are a practical starting point for plants that run containers, and they come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Plants that avoid frequent upgrades usually choose a long term support line, because XWiki publishes a stable line, an LTS line and an intermediate LTS line. The official Docker images are maintained by the XWiki Core Dev Team and licensed under LGPL 2.1. At research time the tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS.
- Database choice: Pick MySQL, PostgreSQL or MariaDB based on your existing database standards and backup tooling.
- Architecture: amd64 and arm64v8 builds allow deployment on common server and edge hardware.
- LTS lines: The LTS tag suits plants that schedule upgrades once in a longer cycle, but confirm its support end date with XWiki.
- Stable line: The stable tag brings newer features and a shorter upgrade cycle, which requires a regular test plan.
- Image pinning: Pin the exact tag and document it in change control.
Before deploying, confirm the tag your plant will run, its support window and the upgrade path to the next line.
How controlled SOP versions and approvals work in a wiki
A plant needs every SOP to move through draft, review, approve, publish and retire, with exactly one effective revision visible to operators at any time and a full, unaltered history kept for audit. A wiki can support this pattern, but only if the team configures it deliberately. Start by mapping each state to a place in the platform: drafts live in a restricted space or as unpublished pages, reviews are assigned to named subject-matter experts, approval is recorded by a role that is separate from the author, and publishing moves the page into the shop-floor space that operators read. Retirement should archive the page and keep it searchable for auditors rather than delete it.
Page history gives you the revision trail, but it does not enforce document control on its own. Use a template with fields for the document number, revision, effective date, owner, approver and change summary, and make those fields mandatory before publication. Page locking or a review step prevents an edit from going live without sign-off, and you should test whether a locked page can still be edited by administrators, since that is a finding an auditor will ask about. Where the platform has no native approval workflow, plan for an extension or a manual sign-off record. Ask each candidate partner to demonstrate the full lifecycle on a sample SOP, including who can approve, how an effective date is enforced and how history is exported.
Wikis fall short of a document management system in several areas: formal approval routing with signatures, controlled printing and distribution of uncontrolled copies, training acknowledgment tracking, and electronic signature evidence that meets rules such as 21 CFR Part 11 for regulated plants. Confirm with each vendor which approval workflow is native and which depends on an extension, and whether that extension is maintained for the version you plan to run. If a plant needs signed records or audit-grade approval trails, plan a document management layer or a validated process around the wiki instead of assuming the wiki covers it.
How a plant wiki rollout runs in phases
A plant wiki rollout moves from document inventory to a tested, offline-capable and translated library handed over with runbooks, so each phase produces a artifact the next one depends on. The sequence keeps shop-floor access and controlled versions in view from the start rather than adding them at the end.
Scope the plant and inventory documents
Agree which sites, lines and departments are in scope, then build a document register listing every work instruction and SOP with its owner, current revision, language, approval status and the quality or maintenance system it references. Plant leads, quality and document control staff do this work with DeployOpen, and the register is the baseline for every later step. It is done when the owners have confirmed the register and the out-of-scope items are recorded in writing.
Design taxonomy and approved templates
Define the space and page structure by line, area or product family, along with naming rules, revision identifiers, approval roles and the template set for work instructions and SOPs. Document control and quality define the approval workflow, and DeployOpen builds the templates in the chosen wiki. The output is an approved template set and a taxonomy document that document control signs off before any content is moved.
Integrate identity with plant and corporate directories
Connect the wiki to the corporate directory and confirm how plant-floor accounts, shared kiosk logins and contractor identities are created, grouped and removed. Groups map to read and edit roles per space, so operators can read approved instructions while only document owners can publish. The output is a tested group-to-permission mapping and a short list of confirmed identity provider settings that the client's directory team has reviewed.
Pilot in one line or cell
Load the approved documents for a single production line or cell, then have operators, supervisors and a document controller use them during real shifts. The pilot checks search on the terms operators actually use, page readability on plant screens, and the approval path for a revised instruction. The pilot closes when the issues log is triaged and the team agrees the template and taxonomy changes needed for wider rollout.
Test shop-floor device and kiosk access
Test the wiki on the devices the floor uses, such as fixed kiosks, shared terminals, tablets and browsers locked down by IT, and confirm which of them can reach the wiki from each network segment. Test a read-only kiosk session, the behavior when a session times out and what happens when a document is revoked while open. The output is a signed-off access matrix covering devices, networks, roles and tested outcomes, plus a tested offline copy of the approved library if the plant network requires one.
Set up the translation workflow
Decide which languages each line needs, who translates and who verifies, and how a translated page stays linked to the approved source revision. The workflow must flag when a source instruction changes so that a translated copy cannot silently drift from the approved English or native-language text. The output is a documented translation process, a list of language owners and a test showing that a source revision change marks the translated pages for review.
Migrate content and cut over
Import the approved documents, preserve their revision history where the source system allows it, and verify that page counts, attachments, permissions and links match the register. Run a reconciliation against the document register, then switch users to the new wiki and retire or lock the old source with a dated notice. The output is a migration reconciliation report and a cutover record that document control approves.
Hand over with runbooks and training
Deliver runbooks for backup and restore, upgrades, identity changes, offline copy refresh and incident response, and train the internal administrators and document controllers who will run the platform after the engagement. DeployOpen documents the configuration and the test results so the client can operate the wiki on its own or through a support retainer. The handover is complete when the client's administrators have restored a backup and published a change in the training environment without assistance.
Integration points and segmented plant deployment
A plant wiki works only if the business zone and the plant zone agree on who can reach what, and through which path. The six components below define the conduits, identity links and data paths that connect a wiki in the business zone to shop-floor users, quality systems and recovery infrastructure.
Directory integration for single sign-on
Map wiki roles to directory groups for plant supervisors, quality staff, maintenance and contractors, so access follows the same joiner and leaver process as the rest of the company. Plant users should authenticate against a directory copy the business zone controls, not a local account list on the wiki. Check how the wiki handles group changes, what happens when the directory is unreachable, and whether shared shop-floor logins are blocked.
Reverse proxy in a DMZ
Publish the wiki through a reverse proxy in a demilitarized zone so that plant clients never open a direct session to the application server. The proxy terminates TLS, enforces authentication before traffic reaches the wiki and logs requests for review. Confirm which hostnames, ports and source networks are allowed, and whether the proxy can be patched and monitored by the same team that owns the wiki.
Isolated plant instance or read-only export
Where the plant network cannot reach the business zone, choose between a second wiki instance inside the plant zone and a read-only export of approved procedures. An isolated instance keeps working during a business network outage but adds a second system to patch and back up. An export is simpler but needs a defined publish step, a version stamp and a rule that the plant copy is never edited directly. Ask the partner how each option handles search and images.
Links to quality and ERP by reference
Store a reference to the controlled record in the quality management system or ERP, such as a document number, work order or nonconformance identifier, rather than copying the record into the wiki. The reference resolves to the source system, which remains the authority for status and approval. Define which system owns each identifier, how broken links are detected, and what a reader sees when the target system is offline.
Backup and restore on a separate host
Keep wiki backups, database dumps and attachment stores on a host that is not part of the wiki's own failure domain, so a ransomware event or a faulty upgrade cannot remove both the live system and its copies. Test restores into a clean environment on a schedule and record the results. Confirm where backups are stored, who holds the keys, how long they are retained and how a plant can obtain procedures if the wiki is down.
Translation workflow for plant content
Set up a controlled process in which each translated procedure is linked to the approved source version it reflects, is reviewed by a qualified local reader and is flagged when the source changes. Without this link, a translated work instruction can drift from the English original and still look current. Ask the partner how the wiki represents language versions, how reviewers are assigned and whether translated pages can be published to a plant before approval.
Keeping multilingual work instructions aligned to one revision
The main risk in multilingual work instructions is translated SOPs drifting from the source revision. A plant revises a torque value, a lockout step or a changeover sequence in the English master, but the German, Polish or Mandarin copy on the line still shows the previous figure. Operators follow the copy in front of them, so the error is invisible until a deviation or audit finds it. Before you build anything, decide which revision is authoritative (normally the approved source document), and write down how a translation is linked to that revision, who approves it and what happens when the source changes.
On the platform side, the control you need is a link between each translated page and its source page, plus a visible flag when the source has moved on and the translation has not caught up. BookStack, XWiki and Outline differ in how much of this they provide natively, so confirm in a proof of concept whether the chosen platform can show a translation as stale, record the source revision it was based on, and list all translations of a procedure from the source. If a native feature is missing, a documented manual process with a register of translations and their source revision dates is the fallback, and it must be tested with the plant's document controller. Translation quality and sign-off belong to the plant's own process owners and qualified translators, not to the wiki administrator, and the wiki should record who signed off each language.
Language-specific shelves or spaces change permissions more than most teams expect. If each language lives in its own shelf or space, a contractor who can read only the Polish space may never see a revision update posted in the English one, and a reader who searches in one language may miss a procedure filed under another. Test the permission model with real roles: operators who read one language, supervisors who read all, and external maintenance staff with restricted access. Confirm that the platform's search returns cross-language results for the roles that need them, and that revoking a language from a user does not leave the cached or exported copies of old revisions readable.
Evidence auditors and regulators ask for from the wiki
This table lists the evidence a plant quality or compliance reviewer is likely to request from a self-hosted wiki holding work instructions and SOPs, and the component or log that produces each item. Read each row as a question to ask your wiki design: if the component cannot produce the item, the gap needs a procedural or integration control. The main takeaway is that the wiki supplies most of the record, but the approval workflow and quality system links must be designed on purpose.
| Evidence item | What it shows | Where it comes from | Where it usually falls short |
|---|---|---|---|
| Approved revision history | Each SOP version, its author, editor and approval state over time | Page revision history in the wiki, plus an approval step or reviewer sign-off recorded in the page or linked change record | Edits made without approval, or drafts that stay visible to shop-floor readers |
| Access logs for SOP reads | Which user or device opened which work instruction, and when | Wiki audit or activity log, forwarded to a central log store (confirm which events the chosen wiki records) | Anonymous or shared shop-floor logins that hide the individual reader |
| Change records tied to quality events | Why an instruction changed, such as a nonconformance, deviation or corrective action | Reference ID in the page change note linked to the quality management system record | Changes made for undocumented reasons, or links that break after the QMS is upgraded |
| Retention settings | How long superseded versions and attachments are kept and how they are removed | Wiki configuration and backup policy, documented against the site record retention schedule | Default settings that purge history, or backups that do not match the stated retention period |
| Restore test results | That a backup of the wiki and its attachments can be restored and the SOPs are readable afterward | Dated restore test records from the backup tooling and a test on a separate environment | Backups that are taken but never restored, or restores that omit attachments or search indexes |
| Electronic signature controls | Who approved an SOP, with an identity, a time and a meaning for the signature | Signature workflow in the wiki or a connected system, with identity provider evidence | Typed names or shared approvals; required only where electronic records and signatures apply under 21 CFR Part 11 |
| Translation version control | That each language version matches the approved source revision | Page links between language versions and a review record for each translation | Translated pages left at an older revision after the source is approved |
| Offline or segmented copy records | Which controlled copies were distributed to a plant network and when they were refreshed | Export or sync logs from the transfer process, with a distribution list maintained by document control | Printed or cached copies on the floor with no record of withdrawal |
What manufacturers ask before building a plant wiki
What does a plant wiki cost to build, and what drives the price?
The software itself has no license fee on the open-source side, so the cost is the work around it: planning, configuration, migration, integrations, hosting and translation. XWiki publishes its own pricing tiers for Pro and support subscriptions (Starter for up to 25 users on XWiki Cloud only, Basic for up to 1,000 users, Business for up to 10,000 users and Enterprise for unlimited users), 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. Migration tooling is priced separately: Confluence Migrator Pro starts at 2000 EUR. The main cost drivers are the number of users and editors, the volume of SOPs to migrate, the number of systems to connect to, whether the plant network needs segmented hosting, and how many languages the content must be published in. DeployOpen does not publish a price list, so ask for a quote built from a written scope.
How long does a pilot take, and what must the plant supply?
The length of a pilot depends on the number of areas in scope and how quickly decisions are made, so the timeline should appear in the written scope rather than in a generic estimate. The plant needs to supply process owners who approve content for each area, an inventory of current work instructions and SOPs with their owners and revision status, and a set of access decisions: which roles can read, edit and approve each space, which shop-floor devices need access, and which areas are restricted. Quality representatives should confirm which controlled-document rules apply, for example under 21 CFR Part 11 if the plant supports regulated products, and IT should confirm the network zones the wiki must reach. A pilot usually works best on one line or one product family.
Can our internal IT team run the wiki after handover?
Often yes, if the team has Linux, database and web server skills and a clear operations runbook. Running the platform includes applying updates, backing up the database and attachments, monitoring, managing user accounts and directory groups, and testing restores. Content governance also stays with the plant: someone must own review cycles and retirement of superseded SOPs. Ask the partner which parts of the handover are documentation, which are hands-on training and which are supported by a retainer. Retainers for ongoing support, upgrades and testing are available from DeployOpen, and they can be scoped to match what your team keeps in-house. Confirm the target skill set with your IT lead before the handover is scoped.
Do we need XWiki Pro for SSO and connectors on the plant wiki?
Not necessarily. XWiki Standard is the free open-source version, and the XWiki Pro page lists Active Directory and Azure Active Directory SSO applications along with connectors for Google Apps, Office365 and OnlyOffice. If your plant needs one of these features, a Pro subscription or equivalent support plan is the natural path, and XWiki Pro subscriptions come in the tiers described above. If you use a different identity provider or only need standard OpenID Connect or SAML integration, check whether the feature is covered by the community extensions or needs custom work. Confirm the exact features you need against the current XWiki Pro page before you choose a tier, because feature lists change.
How are Confluence spaces or file-share SOPs migrated, and what is lost?
Confluence content can be moved with Confluence Migrator Pro, which XWiki SAS sells. It migrates spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history but not attachment history. Its trial is limited to 30 pages per migration, so test with a representative sample before buying. File-share SOPs usually need more work: documents must be converted to pages or linked as attachments, owners and revision dates must be captured, and obsolete versions must be separated from current ones. In either case, plan to verify that permissions match the intended access model after migration and that superseded versions are marked clearly so shop-floor users do not follow them. Ask the partner for a written list of what is preserved, what is lost and what is rebuilt manually.
Does a plant wiki need to work offline or on a segmented network?
It can, and the design should be settled before hosting is chosen. A plant wiki often sits in a segmented OT or DMZ zone, with read access from shop-floor devices and tightly controlled write access from engineering and quality. Standards such as the ISA/IEC 62443 series describe security programs and zone-and-conduit thinking for industrial automation environments, and NIST SP 800-82 Rev. 3 covers OT security for these networks. Confirm which zones the wiki must reach, whether shop-floor terminals can reach the server directly or through a reverse proxy, and what happens to read access during network outages. Offline copies or exported PDFs may be needed for emergency procedures.
How do we keep multilingual SOPs accurate across languages?
Translation effort is one of the largest cost drivers, and it recurs whenever a source SOP changes. Decide first whether each language gets its own page with a link to the controlled source, or whether translations are attached as separate revisions. Each translation needs a named reviewer who is qualified in both the language and the process, and the wiki should show the source revision a translation was made from. Ask the partner how page structure supports language variants, and budget for the translation vendor or internal linguists separately from the platform work.
Questions to ask an implementation partner for a plant wiki
Start with the question that decides whether the project fits your plant: what IACS and OT zoning experience does the partner bring, and can they show how a wiki server sits outside the control network? Ask for named engagements in which they placed a documentation platform in a zone or conduit model aligned with the ISA/IEC 62443 series, and ask which zone the wiki sits in, what traffic crosses the boundary, and who approves each firewall rule. Ask how they map the design to the security program requirements in ANSI/ISA-62443-2-1-2024 and the zone and conduit risk assessment in ANSI/ISA-62443-3-2-2020. Confirm whether they will document the design against NIST SP 800-82 Rev. 3, which covers industrial control systems, building automation and physical access control systems. Ask who on their team has worked on plant networks, not only on corporate IT.
Next, ask how the offline and segmented copies are produced, transferred and refreshed. A good answer names the export path, such as a scheduled, one-way export from the corporate instance to a plant instance, the transfer medium, the checksum or signing step, and the import process that a plant administrator runs. Ask how the partner handles attachments, search indexes and user accounts in the plant copy, and how they prevent a plant user from editing a document that exists only as a read-only mirror. Ask for the refresh frequency they recommend for SOPs and how a stale copy is detected and flagged on the shop floor. Confirm that every step in the transfer is recorded, because the plant will need that record during an audit.
Then test the SOP lifecycle itself. Ask how draft, review, approval and effective-date states are configured, which role approves a change and whether the platform can block publication until that role signs off. Ask how the partner tests this with real documents from your plant, including a rejected revision, a superseded revision and an emergency change. For translations, ask how each translated page is linked to the source revision it was written from, and how a translator is alerted when the source changes. Finally, ask about upgrades across the air gap: how a new platform release or security fix is evaluated, packaged, carried across the gap, tested on a staging copy and rolled back. Ask which license terms apply to the platform they propose. XWiki is licensed under the LGPL 2.1, BookStack under MIT, and Outline under the Business Source License 1.1, whose additional use grant forbids offering a commercial Document Service, so ask the partner to confirm in writing how each term applies to your plant, your suppliers and any contractors who read or edit the wiki.
How DeployOpen scopes and supports a plant knowledge base
DeployOpen works through fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts. The cards below follow one engagement from zone design and build through migration, testing and long-term support, so plant, quality and IT owners can see where their decisions sit.
Requirements and zone design
The first phase maps which work instructions and SOPs are controlled, who edits them, and which shop-floor devices and plant networks need to reach them. The output is a zone design that places the wiki in the correct network segment, with explicit rules for what crosses from the office network into a plant zone. Ask who owns the zone model, how document classes are defined, and whether the design is reviewed against your OT security program before build begins.
Platform build and hardening
DeployOpen installs the chosen wiki in your own cloud account, data center or isolated network, then hardens the web tier, database, backups and administrative access. Hardening covers the settings that matter for controlled content, such as disabling anonymous reads and restricting editor roles. Confirm which hardening baseline applies, who holds administrator credentials, and how the build is documented so your team can repeat it.
Directory and quality system integration
The wiki needs to authenticate users against your directory and reference records in the quality system, such as deviation numbers, equipment IDs or batch records. DeployOpen configures single sign-on and group mapping so that plant roles drive page access, and sets up documented links to quality references rather than copying records into the wiki. Confirm which identity provider is authoritative, how leavers lose access, and which quality records must be linked by identifier.
Migration from existing document stores
Many plants hold SOPs in shared drives, legacy intranets or a previous wiki. The migration phase inventories source content, maps document owners and approval status, and imports content with its history where the source allows it. Expect some metadata, attachments or approval records to need manual handling. Ask which fields survive the move, how superseded versions are marked, and how the cutover from the old repository is controlled.
Security testing of the publishing path
Testing focuses on how content moves from an author's workstation to the wiki and then to a shop-floor terminal. It covers the web application, the API, file upload handling for drawings and PDFs, session management on shared terminals, and the segmentation rules between zones. Ask for the test scope in writing, the retest process for findings, and whether testing can run against a staging copy that mirrors the plant configuration.
Upgrades, backups and support retainers
After go-live, the platform needs patching, version upgrades, tested restores and a named route for incidents. DeployOpen offers retainers that cover these recurring tasks, which are separate from the one-time build. Confirm the response expectations in the retainer, how upgrades are staged through a test environment before a plant zone receives them, and how restore tests are recorded as evidence.
How DeployOpen builds and supports this function for manufacturers
DeployOpen plans, implements, hardens, documents and supports self-hosted knowledge bases inside the client's own infrastructure, including plant networks and segmented zones where the client allows it. For manufacturers, the work starts with how work instructions and SOPs are controlled, approved and reached from the shop floor.
How we scope
- Written scope lists the plants, document classes, approval workflows and quality system links in the first phase.
- Scope records which network zones the wiki will reach and which devices need read access.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We install the chosen wiki in the client's environment, configuring page revisions and approval-based access for controlled SOPs.
- We set up SSO, directory group mapping and per-space permissions so plant operators see only their approved content.
- We test shop-floor device access, search, multilingual page structures and backup and restore before go-live.
How we hand over
- Handover includes architecture notes, configuration records, permission matrices and runbooks for the client's administrators.
- Document control procedures for revision, review and withdrawal of SOPs are written with the client's quality team.
- Training covers editors, approvers and plant administrators, with the client confirming acceptance against the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Upgrades are planned against the vendor's current release line, with a rollback path and a test copy of the content.
- Clients should confirm response expectations, maintenance windows and escalation paths in the retainer agreement.
