Self-hosted document editing for the public sector

Why self-hosted document editing for the public sector is different

A government body moving off Microsoft 365 web apps usually needs a browser editor that runs inside its own hosting, is backed by a supported edition, and meets accessibility obligations for the interface staff use every day. The practical answer is a self-hosted editor such as Collabora Online deployed inside a controlled stack like openDesk, where the editor, document storage and identity sit under the agency's own administration. The constraints driving this choice come mainly from sovereignty, records and accessibility rules rather than from feature lists, so the decision has to be tested against those obligations first.

Three checks shape the design. First, confirm where editing traffic and document content travel, since WOPI calls between the file platform and the editor must stay on hosts the agency controls. Second, confirm the support model: openDesk documentation separates the open-source core from Enterprise Edition support and patches, and Collabora's CODE build is described as not recommended for production, so the agency should decide which edition carries signed security updates before rollout. Third, check the interface against WCAG 2.1 Level A and AA, since the ADA Title II rule applies to state and local government web content and to services provided through contracts, with compliance dates in 2027 and 2028 depending on population served. Ask the vendor or partner to document how the editor's accessibility is tested with the assistive technologies your staff use.

The editor choice itself depends on two inputs the agency must establish early: the Office file formats in circulation and the suite already in use. Collabora's LibreOffice engine and ONLYOFFICE's Office Open XML core handle formatting differently, so test real templates from your records before committing. If the agency already runs Nextcloud or openDesk, Collabora integrates through WOPI and is the web office component in openDesk, which narrows the decision. If the agency has no such suite, the editor becomes one component of a larger identity and file platform, and that platform, not the editor alone, determines the records and access controls an auditor will examine.

Which public sector requirements shape the editing build

This table maps each public sector requirement to its source and to the editing build decision it affects, including hosting location, key length, scanning cadence, access control and editor accessibility. Read each row against your own legal regime, because a federal, justice, defense, state or EU public body each triggers a different set of obligations, and you should confirm with your legal and compliance leads which ones apply to you.

Requirement	What it asks for	What it means for the editing build
NIST SP 800-53 baselines and FISMA (federal bodies)	Low, moderate and high control baselines under SP 800-53B select 149, 287 and 370 controls and enhancements respectively; FISMA makes Inspectors General assess system security.	Expect the document server, storage and WOPI connections to be inside the authorization boundary with access control and audit evidence mapped to the selected baseline. Confirm the baseline with your authorizing official.
FedRAMP scope (cloud-hosted services)	Applies to cloud products that create, collect, process, store or maintain federal information on behalf of an agency; single-agency systems not offered as a shared service are out of scope.	If the editor runs in a cloud account serving several agencies, FedRAMP may apply to that service. A self-hosted editor operated only for one agency may fall outside scope. Confirm with your agency's FedRAMP contact before choosing a hosting model.
FBI CJIS Security Policy v6.1 (justice agencies)	Version 6.1 took effect 26 June 2026 and requires FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations.	Choose TLS and storage encryption that meet 256-bit AES and FIPS 140-3 requirements, and confirm the editor's crypto libraries and container base images can be configured that way. Verify against the Requirements Companion Document.
CJIS v6.1 vulnerability scanning	Vulnerability scanning at least monthly under the RA-5 control family referenced in the 2026 bulletin.	Schedule scans of the document server, load balancer and storage hosts at least monthly, and plan patch cycles for Collabora or ONLYOFFICE images, since editor updates are part of the scanned surface.
32 CFR 2002.14(h)(2) (CUI on non-federal systems)	Federal agencies must use NIST SP 800-171 when setting requirements to protect CUI on non-federal systems, unless the CUI category prescribes other safeguards.	When contractors or partner agencies edit CUI in a browser, the editor, WOPI endpoints and file store inherit NIST SP 800-171 access control and audit expectations. Keep editing traffic inside the defined boundary.
ADA Title II WCAG 2.1 Level A and AA (state and local government)	Web content and mobile apps, including those provided through contracts or licenses, must meet WCAG 2.1 A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts.	Test the editor interface itself, including keyboard navigation, focus order, screen reader labels and contrast, not only your portal pages. Ask your editor vendor for its accessibility conformance documentation and test with your own assistive technology users.
NIS2 scope (EU public administration)	Central government entities are covered regardless of size and public administration is a high-criticality sector; Member States may extend coverage to local administration, and national security, defense and law enforcement are excluded.	Document editing and its hosting become part of the entity's supply chain and incident management obligations. Confirm national transposition, and record who operates the editor, where it runs and how security updates are sourced.
Supported editions and signed updates	Public bodies typically need a documented support lifecycle and security patches for the editor, which the open-source community build may not provide for production.	Ask whether the Collabora Business or Enterprise tier, or an openDesk Enterprise Edition, matches the support and signed patch evidence your authority requires. Confirm it in writing.

How OpenDocument and Office format obligations affect the editor choice

Public bodies often have to keep records readable for years, which pushes them toward open document formats, while citizens, suppliers and other agencies keep sending Office Open XML files (.docx, .xlsx, .pptx). The editor you choose has to handle both sides without forcing staff into desktop Office for routine work. ONLYOFFICE Docs is described as compatible with Office Open XML formats, and Collabora Online is built on LibreOffice technology, which has long supported OpenDocument natively. Those are starting points, not proof. Before you decide, take a set of your own templates, forms, budget workbooks and correspondence letters, round-trip them through each candidate, and compare layout, tables, tracked changes, comments, fonts and macros against the originals.

The format policy itself is not set by the editor vendor. It comes from your body's own records rules, from national or regional digital standards, and sometimes from procurement terms that specify the formats a contractor must accept and return. Confirm in writing which formats must be stored as the official record, which may be kept only as working copies, and whether the body must preserve the original file alongside any converted version. Also confirm whether the rule covers files opened in the browser, saved from it, or exported from it, because a format a browser editor can open is not always one it can save with full fidelity.

Treat the format rules as a test plan rather than a feature checklist. Ask your legal or records team which formats are mandatory, then assign each one a pass criteria owned by a named reviewer. Record the editor version you tested, since fidelity changes between releases, and retest after every upgrade. If a template fails on one editor but passes on the other, that result is more useful to your decision than any published compatibility claim. Note also that conversion between formats can be logged by the platform, so ask your implementation partner how conversion events are captured for the audit trail.

Which editing platform fits which public sector setting

When a ministry or national administration adopts openDesk, the web office is not a separate purchase. openDesk bundles Collabora as its web office alongside Nextcloud for files, OX App Suite for groupware, Element for chat and Nubus for portal and identity. The deployment is Kubernetes-based, so Collabora is delivered as part of that stack rather than selected on its own. Collabora Online's source code is licensed under MPL-2.0, while each bundled component keeps its own license, which the operator should map before going live.

Collabora's role: Collabora provides the browser editing for documents, spreadsheets and presentations inside the openDesk file and groupware experience.
License mapping: openDesk's deployment automation is Apache-2.0, while Collabora's code is MPL-2.0 and Nextcloud and Nubus are AGPL-3.0. Legal review should cover each component.
Enterprise support: ZenDiS recommends openDesk Enterprise Edition for production. Enterprise-only features include Collabora branding and automatic load scaling.
Collabora plans: Standalone Business or Enterprise Collabora plans apply only where a body runs Collabora outside the openDesk support path. Confirm with ZenDiS which support path covers the bundled Collabora.
CODE edition: Collabora describes its free CODE edition as suited to testing, home use or small teams and not recommended for production, so it should not be used for a national rollout.

Before committing, confirm which openDesk release line and Collabora version the support contract covers, and who issues security patches for the editor.

How a public body rolls out self-hosted document editing

The sequence moves from a legal and format baseline to a tested production build inside the approved boundary, then to a supported operating model. Each phase closes with a written output the agency can review before the next phase starts.

Set the requirements and legal baseline
The agency's records, legal, accessibility and security leads agree which document formats must be created, edited and returned, which data classifications the editor will handle, and which sovereignty rules apply to hosting and support. DeployOpen maps these decisions to the controls the agency must evidence, including the FedRAMP, CJIS or CUI rules where they apply. The step closes with a signed requirements register that names the in-scope document types, the classification ceiling, the hosting jurisdiction and the accessibility target, so later design choices can be checked against it.
Prove fidelity on real templates
The team collects a representative set of the agency's own .docx, .xlsx and .pptx templates, forms and macro-free working files, then opens and edits them in candidate editors inside a test environment. Reviewers record layout, tables, fonts, tracked changes and comments against the originals, and note anything that needs a fallback to desktop Office. The output is a fidelity report listing passing templates, known defects and the editor and edition chosen, which the agency signs off before any production design begins.
Design hosting and identity inside the boundary
Architects place the document server, the file platform and the identity provider inside the approved network or cloud boundary and confirm where logs, temporary files and fonts are stored. They define how users sign in, which groups may edit rather than only view, and which hosts may call the WOPI endpoints. If the agency plans openDesk, the Kubernetes prerequisites and the Collabora component are checked against this design. The step closes with an approved architecture diagram, a data flow map and an access matrix that the security authority accepts in writing.
Build production with WOPI routing by WOPISrc
Engineers deploy the editor from the agreed packages or Helm chart, connect it to the file platform through WOPI, and configure the ingress or load balancer to route every session for one document to the same editor pod by the WOPISrc parameter. Replica counts are set manually where the vendor guidance disables autoscaling, and resource limits are sized from the vendor's published figures and the agency's measured concurrency. The step closes with a test record showing that concurrent editors of one file land on the same pod, that TLS and host restrictions work, and that the build can be rebuilt from versioned configuration.
Test accessibility against WCAG 2.1 AA
Testers, including people who use screen readers and keyboard-only navigation, work through the editing interface, menus, dialogs and common tasks such as inserting tables, reviewing comments and exporting. Findings are logged against WCAG 2.1 success criteria at Level A and AA, and the agency's accessibility lead decides which gaps are fixed, documented as known issues or handled through an alternative process. The output is an accessibility conformance record for the editor and the wrapping pages, which supports the agency's own statement and remediation plan under the ADA Title II web rule.
Hand over and operate under a supported edition
The production system is handed over with runbooks for patching, backup and restore, monitoring, and user support. The agency's operations team applies signed updates on the schedule set in the support contract, tests each release on a staging copy against the template set from the proof of concept, and keeps a record of each change. Where the chosen vendor offers a supported edition with long-term support and signed security updates, the contract and the update process are checked against the agency's procurement rules. The step closes with a documented operating model, a tested restore and a support agreement that names response expectations in writing.

How openDesk, Collabora and the file platform connect

A public sector editing deployment is a chain of components that must be owned, sized and secured together. The cards below cover the openDesk cluster, the Collabora editor pods, the file platform that acts as WOPI host, and the identity layer that decides who can open a document.

openDesk Kubernetes foundation

openDesk is deployed with Helmfile and Helm onto a Kubernetes cluster, and it expects the cluster to provide an ingress controller, cert-manager and an RWO volume provisioner. The stack requires Kubernetes v1.33 or later and is tested on kubespray clusters, not OpenShift, so an agency running OpenShift should confirm support with ZenDiS before committing. Confirm who operates the cluster and its upgrade path.

External production data services

openDesk does not run production databases inside the cluster by default. It expects external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each service needs its own backup, patch and availability owner, and the public sector team should decide early whether these sit in the same government cloud or a separate data center.

Collabora pods and manual replicas

Collabora Online runs as stateful editing pods, and its Helm chart disables horizontal autoscaling because scaling breaks collaborative editing and copy and paste. Replica counts are set by hand from measured peak use, and the chart's recommended production limits are 8 CPU cores and 8000 MiB of memory per pod. Ask the implementer how peak load will be measured and who changes replica counts during a surge.

WOPISrc-based load balancing

Every user editing the same document must reach the same Collabora pod, so the ingress must route by the WOPISrc parameter rather than by client address alone. Test this routing with two browsers editing one file during a failover drill, and confirm the ingress choice (Nginx, HAProxy or OpenShift Router) is supported by the chosen Collabora release.

File platform as WOPI host

The file platform, typically Nextcloud or the Nextcloud component in openDesk, acts as the WOPI host. It issues the access tokens that let Collabora open a document and decides which users may edit or only view. Confirm that the WOPI discovery URL and the allowed hosts are restricted to the internal names of the editor pods, and that document versions stay in the file platform's audit trail.

Identity federation to an external IdP

openDesk ships with Nubus for portal and identity, but agencies usually need users to sign in through their own identity provider. The openDesk federation documentation describes connecting an external IdP so that one set of accounts, groups and multi-factor rules governs the editor, the file platform and the rest of the suite. Confirm how group membership maps to edit rights before rollout, since that mapping controls who can change official records.

What do public bodies ask before hiring help for document editing?

What actually drives the cost of a public sector document editing project?

The cost is driven by four components: the editing suite and its support edition, the number of Kubernetes nodes and pods needed for concurrent editing, the integration work with your file platform and identity layer, and accessibility and fidelity testing. The editor itself can be free under a community license, but production use usually means paying for a supported edition. Collabora's published Business plan lists 3 euros per user per month for up to 99 users, with long term support, an SLA and signed security updates (source: Collabora Online pricing page). Ask the partner to price each component separately in the written scope so you can see which lines recur.

Which costs are one-time and which recur every year?

One-time costs usually include planning, deployment, integration with your file platform and identity provider, hardening, accessibility and format testing, and knowledge transfer to your staff. Recurring costs include subscription or support fees for the editor edition, the Kubernetes and database infrastructure you run, upgrades, and any retainer for monitoring and patching. Openness of the software does not remove these recurring lines. For openDesk, ZenDiS recommends the Enterprise Edition for production, which is sold as SaaS or for on-premises installation with SLA-backed support (source: openDesk Enterprise Edition docs). Ask whether the quote separates these two categories.

How long does a public sector document editing rollout take?

The schedule follows the written scope, not a standard duration. The main variables are the number of users, the number of integrations with your file and identity systems, how many document formats must be tested against real templates, and how many approval gates your hosting and security authorities require. Your partner should give milestones tied to deliverables and name the inputs they need from you before each one. If the scope includes an openDesk-based suite, the platform's own requirements affect timing, including a CNCF-certified Kubernetes cluster at v1.33 or later (source: openDesk requirements docs). Do not accept a timeline that is not linked to a signed scope.

What must the public body provide before the work starts?

Most delays come from inputs the body controls. Expect to supply four things: the identity provider and directory that staff will sign in with, written approval of the hosting location and network design, a set of representative format samples (such as .docx, .xlsx and .pptx files your staff actually use), and named testers from business units who can check fidelity and accessibility. You will also need an owner who can make decisions on edition choice and scope changes. Confirm these inputs in the statement of work so they are not assumed.

What hardware does an evaluation deployment need before production sizing?

An evaluation deployment is a different exercise from production. For openDesk, the documented minimum for an evaluation is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not supported yet (source: openDesk requirements docs). Production expects external services such as PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server (source: openDesk requirements docs). For the Collabora Helm chart, the README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB (source: Collabora Online Helm chart README). Ask the partner to size from your concurrent editor count, not from these minimums alone.

Can our own IT team run document editing without outside help?

Often yes for routine operation, but a first build usually needs skills that few teams hold at once: Kubernetes operations, WOPI integration, reverse proxy routing, accessibility testing against WCAG 2.1 AA, and format fidelity testing. Collabora's Helm chart notes that horizontal autoscaling is disabled because scaling breaks collaborative editing, and that load balancers must route by the WOPISrc parameter (source: Collabora Online Helm chart README). Assess your team against that list. A common split is outside help for design, build and hardening, with internal staff taking over operations after handover. DeployOpen implements, hardens, documents and supports self-hosted platforms in your own infrastructure, under fixed-scope agreements.

Does a fixed-scope project or a retainer fit a public body better?

Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. That suits the build phase, where the body needs a clear acceptance point. A retainer suits the period after go-live, when the body needs ongoing support, upgrades and testing. openDesk releases follow a cadence in which only the latest minor version is supported and in-place upgrades between majors are not guaranteed (source: openDesk release management docs), so budget for upgrade work in either model. Ask for both options priced separately so the decision is made on written terms.

What compliance evidence should the body expect from the partner?

Expect the partner to prepare systems, controls and evidence for your assessment, such as configuration records, access control settings, logging, patch records and accessibility test results. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. Accessibility obligations are concrete: for state and local government, the ADA Title II web rule requires WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (source: eCFR 28 CFR 35.200). Confirm with your legal and compliance teams which deadline applies to your body.

Evidence auditors and oversight bodies ask for

This table maps each piece of evidence that public sector assessors commonly request for a browser editing deployment to the component that produces it and the question it answers. Read it as a preparation list: DeployOpen can prepare the records, but independent auditors and certification bodies issue any assessment or certification.

Evidence item	Component that produces it	What the assessor is checking
Approved architecture diagram	Agreed design document covering the editor, document server, file platform and identity layer	Where editing traffic flows, which zones hold document content and which external services are excluded
WOPI traffic restricted to known hosts	Collabora Online WOPI host allow list and reverse proxy or ingress rules	That only the file platform can open editing sessions and that no unknown host receives document links
Access and audit logs for document access	File platform audit log, Collabora Online server logs and central log store	Who opened, edited or shared a document, when, and whether logs are retained and protected from change
Signed update records	Change records for each Collabora Online or openDesk release, including package signatures and deployment tickets	That updates come from a trusted source, were tested first and were applied in a traceable way
Monthly vulnerability scan results	Scanner output for the editor, document server, operating system and container images	That scanning runs at least monthly for CJIS scope, with findings tracked to remediation
WCAG 2.1 AA accessibility test report	Accessibility test results for the editing interface, produced with assistive technology and automated checks	Whether the editing interface meets WCAG 2.1 Level A and AA before the applicable ADA Title II deadline
Supported-edition contract	Vendor or partner agreement that names the edition, support level and patch commitment	That security fixes and long-term support continue for the life of the deployment, not only during the initial build

Questions to ask an implementation partner for public sector editing

Start by asking how many public bodies the partner has run openDesk or Nextcloud estates for, and which of those were in production rather than evaluation. Ask them to describe the deployment model they would use: whether they run openDesk on a CNCF-certified Kubernetes cluster at v1.33 or later, how they handle the external production services openDesk expects (PostgreSQL, MariaDB, Redis, an SMTP relay, ClamAV over ICAP, object storage and a TURN server), and whether they recommend the Enterprise Edition for production and why. Ask for the Collabora replica count they plan to set by hand and the WOPISrc routing rule they will use, then ask how they prove that every editor of one document lands on the same pod. A partner who cannot show a test with several concurrent editors on one file has not tested sticky routing.

Ask how accessibility of the editor interface is tested and reported. The useful answer names the WCAG 2.1 Level A and AA criteria in scope, the assistive technologies and browsers used, keyboard-only and screen reader passes on the editing toolbar and dialogs, and the written report format. Ask how fonts and Office formats are validated, including which sample templates from your own estate they will open, save and compare, and how they handle missing fonts in the container image. Ask how signed updates are verified before they are applied, who holds the signing keys, and whether updates for Collabora Online and openDesk components are applied through a staging environment first.

Ask whether the partner will document the system boundary in writing before design starts. Your scope depends on your own classification: whether the editing service is a cloud service offering under FedRAMP, whether criminal justice information under the CJIS Security Policy passes through it, or whether controlled unclassified information is involved and NIST SP 800-171 applies. Ask for the data flow diagram that shows where the editor, the document server and the storage sit, and which of those components fall inside the assessed scope. Finally, ask how they will handle openDesk upgrades given that only the latest minor version is supported, in-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps. Ask for the upgrade runbook, the test environment they will use, and the rollback plan.

How DeployOpen scopes and supports public sector editing

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the agency's own cloud accounts, data centers or air-gapped networks. For public sector document editing, that means starting from the formats, accessibility obligations and hosting constraints the agency must meet, then building and handing over an editing service it can run and evidence itself.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which editor, edition and file formats the agency needs to support.
Scope also covers the file platform, identity integration and the hosting boundary for editing traffic.
Confirm which federal, state or EU baselines apply, since they determine hosting and evidence needs.

How we build

Deploy the document server and file integration inside the agency's own infrastructure.
Test fidelity on the agency's own templates, forms and accessibility-sensitive documents.
Configure WOPI access so only approved file hosts can reach the document server.
Run security testing on the editing stack and document the results against the agreed scope.

How we hand over

Deliver architecture, configuration and runbooks that the agency's own staff can operate.
Document control mappings and evidence packs for assessors, without issuing any certification.
Agree how updates are obtained, reviewed and applied in the agency's change process.
Confirm the supported edition and its support terms with the vendor before handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover patching, backups, version upgrades and re-testing after configuration changes.
Support scope is defined in writing, so the agency knows who responds to what and when.
Quotes follow from the written scope, so ask for the scope and assumptions behind each line.