Document editing requirements checklist for self-hosted teams

How to use this document editing requirements checklist

A team that must offer browser editing of Office files on infrastructure it controls should write its requirements before it compares Collabora Online and ONLYOFFICE Docs. The checklist that follows answers one question: what must the editing service do, for which users, on which network, before any platform is shortlisted. Each item asks for a decision you can record, such as the file formats your staff exchange, the number of people who will edit at the same time, the file platform the editor must plug into, and whether an AI assistant is permitted at all. Work through the items in order, because the answer to the file platform question changes how WOPI traffic is secured and routed.

The checklist is meant to be filled in with your own documents, user counts and network rules, not with generic values. Pull a sample of the templates, contracts and spreadsheets your teams actually edit and test them against candidate editors later, since fidelity depends on your files. Export your directory group memberships and your planned number of editors per document, and map which networks may reach the document server. Several items are anchored by facts you can check directly: both editors are open source with AGPL-3.0 (ONLYOFFICE Docs) and MPL-2.0 (Collabora Online) licensing, Collabora's Helm chart requires routing by the WOPISrc parameter and disables autoscaling, and the two vendors sell different support and edition terms. Confirm each of these against the current license files and vendor documentation before you rely on them.

This section does not estimate any price. Licensing cost depends on user counts, edition, support level and whether you embed the editor in your own product, and the vendors publish their terms on their own pricing and edition pages. Record the user count and support expectations here so that a later quote can be built from written scope. Ask any implementation partner to price against the same checklist answers so that the comparison stays like for like.

Functional requirements for document editing: formats, fidelity and concurrent editors

This table lists the functional requirements that decide whether a self-hosted editor fits your documents and your peak usage, with a verification method for each. Read each row as a question to answer before shortlisting Collabora Online or ONLYOFFICE Docs. The main takeaway is that format and concurrency claims are only proven by tests on your own files and your own user pattern.

Requirement	Why it matters	How to verify
Native Office Open XML support (.docx, .xlsx, .pptx)	ONLYOFFICE Docs treats .docx, .xlsx and .pptx as its native formats, while Collabora Online edits through the LibreOffice engine, so fidelity can differ by file type.	Open a sample set of your own templates in each candidate editor and compare layout, styles, tracked changes and charts against the original in desktop Office.
Conversion of legacy and OpenDocument formats	Older .doc, .xls and .ppt files and OpenDocument files (.odt, .ods, .odp) appear in most archives, and conversion changes the stored file unless you keep originals.	Convert a representative archive sample, confirm which formats are edited versus converted, and confirm whether the original is kept after save.
PDF editing needs	Some teams only need to view PDFs, while others need text edits, page manipulation, annotations or form filling, which narrows the candidate list.	Define the PDF tasks in writing, then test each task on real forms and signed or scanned files in the chosen editor.
Font and character set coverage	Missing fonts change pagination and line breaks, which breaks signed contracts and regulated forms.	Confirm the font set installed on the document server, then compare rendering of templates that use your corporate and regional fonts.
Concurrent editors per document	Co-editing needs differ between a few reviewers and dozens of simultaneous editors, and the answer changes server sizing and routing.	Set a named target (for example, the number of editors on your largest shared document) and run a scripted load test that opens and edits the document from that many sessions.
Concurrent editors per server	Peak sessions across all documents determine how many document server nodes you run and how much memory each needs.	Model peak hour sessions from your identity or file platform logs, then load test one node and confirm the vendor's limits for your edition.
Co-editing required or view and edit only	If co-editing is not needed, routing and locking requirements are simpler and the support scope may be smaller.	Document the editing roles per team, then test that edit-only and view-only permissions behave as specified for each group.
Vendor edition and user count	Feature limits, support levels and scaling rights differ between community and paid editions, so the edition must match your user count.	Ask the vendor in writing which edition covers your user count, which features are included, and what the support terms say.

Which platform the editor plugs into through WOPI

The editor does not store your files or manage your users. It attaches to a file platform that acts as the WOPI host, so the file platform, its connector and its version set the boundary for every editing session. Confirm each of these pieces before choosing an editor, because compatibility is per component and per release.

Identify the file platform

Name the system that holds the documents: Nextcloud, Seafile, a document management system or a custom application. This decides whether a tested connector already exists or whether your team must write and maintain one. Record the exact product version in use, since connector support is tied to specific releases of both the file platform and the editor. Ask each editor vendor to confirm compatibility with your version in writing rather than assuming it from the product list.

Map the WOPI host role

In WOPI, the file platform is the WOPI host: it authenticates users, decides who may view or edit a file, and serves the document to the editor. The editor is the WOPI client and renders the document in the browser. Document the trust relationship, the access tokens the host issues and which endpoints the editor must reach. Those answers feed directly into the security review of WOPI traffic and the network rules around it.

Check Collabora's listed integrations

Collabora lists WOPI integrations with Nextcloud, ownCloud, Seafile, WordPress, Alfresco, Mattermost, Nuxeo, OpenText and xWiki, among others. A listing shows that the protocol is supported, not that your version, your storage backend and your permission model have been tested together. Use the list to shortlist platforms, then run a pilot with your own folder structure, sharing rules and file sizes before committing.

Check ONLYOFFICE's listed integrations

ONLYOFFICE Docs lists integrations with Nextcloud, ownCloud, Seafile, Moodle, Odoo and other WOPI-compatible platforms. Where the file platform has a published ONLYOFFICE connector, confirm which connector version pairs with your file platform release and with the Document Server version you plan to run. Ask whether the connector is maintained by the file platform vendor, by ONLYOFFICE or by the community, because that answer determines who fixes a broken upgrade.

Confirm connector status for custom platforms

If the documents live in a custom application or a platform without a tested connector, the integration becomes a development project. Your team or a partner must implement the WOPI host endpoints, token handling, locking and file version behavior, then test them against the editor release you select. Ask for the list of WOPI operations implemented, the test evidence for co-authoring and locking, and the process for re-testing after each editor update.

Confirm version compatibility per release

Editors, file platforms, databases and PHP runtimes each publish their own compatibility matrix, and those matrices change between releases. Confirm the pairing for the exact file platform release, editor release and connector release you intend to deploy, and repeat the check before every upgrade. Assumed compatibility is the most common reason a working pilot fails at go-live, so treat the written matrix from each vendor as an acceptance criterion.

Licensing, editions and user counts that decide the platform

Start with the edition, not the feature list. The license and the edition you buy decide who supports the server, who ships security fixes and which admin features you can use, and those answers change with your user count. ONLYOFFICE Docs Community Edition is licensed under AGPL-3.0, and its edition comparison places admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support in the Enterprise Edition, with Community support through GitHub, the forum and configuration files only. Collabora Online's server code is under the Mozilla Public License 2.0, which governs code you modify and distribute, but it does not decide support. For Collabora, the free CODE build is described as suited to testing, home use or small teams and not recommended for production, so a production deployment needs a paid plan.

Collabora's pricing page states that the Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan, for 100 or more users, is quoted with volume discounts and adds integration support, customization services and roadmap input. Confirm in writing which plan covers your exact user count, whether signed security updates reach every server you run (including staging and disaster recovery), and what the support response obligations are. Where you embed the editors in a product you sell, ask whether the ONLYOFFICE Developer Edition, which ONLYOFFICE sells under a commercial license for software vendors, is the right route instead of the Community license.

Security of WOPI traffic and document access

WOPI connects the file platform to the document server, and every editing session passes tokens, file requests and saved changes between them. The cards below cover the controls a buyer should specify and verify before the design is approved. Each one maps to a decision about who may reach the editor, how traffic is protected, and what evidence the platform keeps.

Restrict WOPI traffic to known hosts

Only the file platform should be able to call the editor's WOPI endpoints, and only the editor should be able to call back into the file platform. Document both directions in the design: which hostnames, IP ranges or service identities are allowed, and which ones are blocked. Ask the vendor or integrator to show the allow-list configuration and a test that proves an unlisted host is refused. Confirm how the file platform's WOPI host address is set, because a wrong address breaks sessions or leaves an opening.

TLS between every component

Browser sessions, the file platform, the document server and any storage backend should each run over encrypted connections, including traffic between internal services. The HIPAA Security Rule's transmission security standard, 45 CFR 164.312(e)(1), is a useful reference point for regulated buyers asking how ePHI is protected in transit. Ask who issues and rotates certificates, whether internal certificates are trusted by every component, and how a certificate expiry is detected before editing stops.

Token lifetime and authentication handling

WOPI access tokens grant a session the right to open and change a specific file, so their lifetime, scope and revocation rules matter. Confirm that tokens expire after a short period, are bound to one document and user, and cannot be reused after a session ends. Ask how the file platform signs or validates tokens, where the shared secret is stored, and how it is rotated without a full outage. Check that single sign-on and directory users cannot bypass the token check.

Least-privilege edit and view rights

Many documents need readers, not editors, and the platform should enforce that split at the file level rather than rely on users to behave. Map each share type to view, comment or edit permissions, and confirm that a view-only link cannot be upgraded through the editor. Test that restrictions on download, print and copy are applied by the document server, not only hidden in the interface. Review group membership for editors on sensitive folders at least on a schedule your policy sets.

Audit logging of access and edits

Regulated buyers ask who opened, edited and shared a document, and when. The HIPAA audit controls standard, 45 CFR 164.312(b), requires mechanisms that record and examine activity in systems containing ePHI, which is a useful reference for what to ask for. Confirm that the file platform logs open, edit, share and permission events, that logs are forwarded to a store the editing team cannot alter, and that retention matches your records policy. Ask which events the editor itself records and which must come from the file platform.

Signed and controlled update channels

Editor images, packages and patches are part of the attack surface, so the update path needs the same scrutiny as the runtime. Ask whether releases are signed, whether the integrator verifies signatures before deployment, and how security patches reach an offline or restricted environment. Confirm the target release and support status before you commit, since upstream versions change often. Require a written rollback procedure and a record of which version runs in each environment.

Why scaling and load balancing for editing differ from file storage

Browser editing is stateful in a way file storage is not. When a user opens a document in an editor, the editing session, the in-progress changes and the co-authoring state live on a specific document server, so every editor of the same document must reach that same server. A file sync platform can spread requests across any node that can read the file from shared storage, but an editing session cannot be split that way. Before you size anything, confirm with your vendor or partner how the chosen editor keeps co-authoring state, and where that state sits when a pod or container restarts. The routing rule is the first design decision, and it changes the load balancer, the replica count and your failure plan.

Collabora's official Helm chart makes the constraint explicit. Its README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set manually. It also says load balancers must route by the WOPISrc parameter so that all users editing one document reach the same pod. The chart supports Nginx, HAProxy and OpenShift Router as ingress controllers. Ask your platform team which of these you already operate, confirm that the ingress can hash or route on the WOPISrc value, and test that two users opening one file land on the same pod. Plan replica counts from your peak concurrency, not from average load, and treat any scale-down event as a planned change window.

The same README lists production resource limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as reference points to verify against your own document mix, macro-heavy templates and concurrent session counts, not as sizing answers. On the ONLYOFFICE side, version 9.4, released May 19, 2026, removed the 20 simultaneous connection limit from the Community Edition and consolidated the server into a single process without RabbitMQ or database dependencies. Scaling for thousands of users is listed among the Enterprise Edition features in ONLYOFFICE's edition comparison, so confirm with ONLYOFFICE which capabilities your chosen edition includes, how it clusters, and whether the support plan covers the scaling design you need.

Operational requirements to verify before go-live

How long is each Nextcloud major version supported?

Each Nextcloud major version receives monthly maintenance releases for one year, and Nextcloud publishes a new major version every four months. Per Nextcloud's maintenance and release schedule, Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026 with end of life in September 2027, Nextcloud 34 is supported until June 2027, and Nextcloud 33 until February 2027. Nextcloud 36 (Hub 27 Winter) is scheduled for 17 February 2027. Confirm the support window of the exact version you deploy, and plan the next upgrade against the published dates. If you use Collabora or ONLYOFFICE, also confirm which connector version pairs with your Nextcloud release, since the editor server and the file platform upgrade on separate cycles.

How do we upgrade one major version at a time safely?

Nextcloud does not allow skipping major releases, so each upgrade moves one major version forward. Before every step, take a full backup of the database, the data directory and the configuration, disable third-party apps, and confirm each app's compatibility with the target version. Run the upgrade in a staging copy of production first, then repeat the sequence for each intermediate version. Test that the editor connector still opens, saves and co-edits documents after each step, not only that the login page loads. Ask your implementation partner to document the rollback path and the time each step took in staging, so the production window is planned from measured data.

How should we test fonts and Office formats before go-live?

Test with your own templates, not with sample files. Collect the .docx, .xlsx and .pptx files that matter most, including ones with custom fonts, tracked changes, embedded charts, complex tables and form fields, and open them in the candidate editor and in desktop Office. ONLYOFFICE treats .docx, .xlsx and .pptx as native formats, while Collabora builds on LibreOffice technology, so fidelity differs by file type. Install the same fonts on the document server that your users have on their desktops, and check that missing fonts do not reflow pages. Record which files need manual correction and decide whether those cases are acceptable. Repeat the test after each editor version upgrade.

How do we back up and restore document storage and the document server?

Back up two things separately: the document storage held by the file platform (files, versions, metadata and database) and the document server configuration, including its secret keys, certificates, custom fonts and any integration settings. Editor containers are usually rebuilt from images, but confirm that the restored setup reconnects to the file platform and that open sessions recover cleanly. Schedule a full restore test into an isolated environment at least once before go-live, then measure how long the restore took and whether every document opened with its version history intact. Nextcloud documents backup as a required step before each upgrade, which gives you a natural point to rehearse the procedure.

What should we monitor on the editing stack?

Monitor the health of each layer: the file platform, the editor server, the reverse proxy or load balancer, and the database. For the editor, watch CPU and memory per pod or container against the limits you set, the number of active editing sessions, and failed document opens or saves. For Collabora on Kubernetes, the official Helm chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, and the chart disables autoscaling, so alerts must trigger a manual replica change. Confirm with the vendor which metrics and health endpoints each editor exposes, and test that alerts fire during a simulated overload.

How do we run a patch process for the editor and its dependencies?

Define who receives vendor security notices, how fast critical fixes are tested, and who approves production rollout. Collabora's free CODE build is a rolling release described as not recommended for production, while the paid Collabora Online adds tested updates, security fixes and support, so confirm which edition gives you signed security updates before you commit. ONLYOFFICE Community support runs through GitHub and the forum, and its Enterprise Edition adds support tiers, so confirm the response commitments in writing. Include the operating system, database, PHP or runtime and container base images in the same cycle, and keep a record of which version runs where for audit evidence.

Can we run the editor from images carried into a restricted network?

Confirm that every image, package and font can be pulled once, verified, and carried across the boundary by your approved transfer process. Collabora publishes Docker images, including the free CODE image collabora/code for x86-64, ppc64 and arm64, and supports deployment from system packages or Kubernetes. ONLYOFFICE recommends Docker as its installation method. Test an offline install on a machine with no outbound access, including the dependent services, font packages and any update channel you disable. Ask the vendor whether the chosen edition supports offline license checks and whether it needs external calls for telemetry or updates, and document the answers in your change record.

Who pays for operational support, and what does it cover?

Cost falls into three groups: the software subscription or support plan, the internal staff time for upgrades and monitoring, and any partner retainer for ongoing operations. Subscriptions recur and vary by edition. Collabora's published Business plan lists 3 euros per user per month for up to 99 users with long term support and an SLA, and Nextcloud Enterprise lists its Standard tier from 71.29 euros per user per year for 100 or more users. Ask each vendor for a written quote tied to your user count and support hours, and ask a partner whether upgrades, backups and testing are included in a fixed-scope engagement or a retainer. DeployOpen does not publish a price list; a quote follows from written scope.

Deciding whether an AI assistant is allowed in the editor

Some organizations decide that no AI assistant may run inside the document editor, for example because documents carry regulated personal data, deal terms or controlled information that must not leave a defined boundary. This position is the simplest to audit, but it has to be enforced in configuration, not just in policy. The assistant is an optional feature, so the reader should confirm that it is disabled at every layer of the deployment rather than assuming it is absent.

Verify the default state: Collabora Online 26.04 describes its AI assistant as optional and off by default, but confirm the setting in your own build and container configuration after each upgrade.
Block outbound AI calls: Restrict egress from the document server so that no assistant endpoint can be reached, even if a feature is enabled by mistake.
Document the decision: Record the prohibition in the data classification and acceptable use standards so auditors can trace it to a control.
Restrict administrative changes: Limit who can change editor settings and log those changes, since a single configuration edit can switch a feature on.
Review on each release: Add the assistant setting to the change review checklist for every editor upgrade.

Before approving this position, confirm with your vendor which AI-related settings exist in the edition you deploy and how each is turned off.

What buyers ask before hiring a partner for document editing

What drives the cost of self-hosted document editing?

The main drivers are the editor edition, the number of users, the number of document servers, the integration work and the support plan. Collabora's public pricing page lists its Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access, according to the Collabora Online pricing page. Nextcloud Enterprise list prices, according to the Nextcloud pricing page, start at 71.29 euros, 104.99 euros and 204.75 euros per user per year for Standard, Premium and Ultimate tiers at 100 or more users. Recurring subscription fees sit alongside one-time costs for setup, fidelity testing and integration, which DeployOpen scopes and quotes in writing.

How long does a document editing implementation take?

The timeline depends on the scope, so it should be agreed in writing before work starts rather than assumed from a generic estimate. The main variables are the number of document servers, how many file platform instances need connecting, how much fidelity testing your own templates need, and whether identity, network and DNS changes are required. Ask the partner to break the schedule into phases with named deliverables and client-side dependencies, so you can see where your team's availability affects the date. Most engagements are fixed-scope, which makes the timeline part of the signed agreement.

What do we need to provide for a document editing project?

Expect to supply four groups of input. First, administrators of the file platform, such as Nextcloud or Seafile, who can enable the WOPI connection and confirm versions and storage. Second, network and DNS owners who can publish the editor hostname, set up TLS certificates and allow traffic between the file platform and the document server. Third, identity owners who can connect Active Directory, LDAP, OpenID Connect or SAML where single sign-on is required. Fourth, a set of representative test documents, including your most complex .docx, .xlsx and .pptx files, so fidelity can be checked before rollout.

Can our own team deploy and run document editing without a partner?

Small teams can start with free community builds, and that is a reasonable way to learn the stack. Collabora describes its free CODE edition as suited to testing, home use or small teams but not recommended for production, according to the CODE page. For production, the questions change: who applies security updates and how quickly, who tests upgrades against your file platform, who restores service if an editor pod fails, and who answers support tickets. ONLYOFFICE's edition comparison lists Community support as GitHub and forum based, while Enterprise Edition adds an admin panel and Basic, Plus or Premium support. Decide who owns each of these tasks before choosing between in-house and partner-run operation.

Which editor edition does a production deployment need?

The right edition depends on your user count, support expectations and whether you embed the editors in your own product. For Collabora, the paid Collabora Online adds tested updates, security fixes and support, and its Enterprise plan for 100 or more users is quoted with volume discounts, according to the Collabora Online pricing page. For ONLYOFFICE, the Community Edition is AGPL-3.0 licensed, while features such as the admin panel and white labeling belong to the Enterprise Edition, per the edition comparison. ONLYOFFICE's Developer Edition is a separate commercial license for software vendors that embed the editors. Confirm the edition, license terms and support tier in writing with the vendor and your partner.

What does fidelity testing cost us in time and effort?

Fidelity testing is the work of opening your own templates, contracts, financial models and presentations in the chosen editor and comparing layout, fonts, tables, macros and tracked changes against the original. Its effort depends on the number of document families, how many have complex formatting, and how many people must sign off on the results. Ask the partner to list the test set, the comparison method and the acceptance criteria in the scope, and to state which fonts are installed on the document server. Plan for this work to be done before the production cutover, not after users report problems.

How do we request a quote from a document editing partner?

Send the partner a written requirements list that covers file formats and fidelity needs, expected concurrent editors, the file platform and its version, the user count and edition, hosting location, identity source, and whether an AI assistant is permitted. A quote should follow from that written scope, and DeployOpen does not publish a price list. Ask for the scope, deliverables, client responsibilities, exclusions, acceptance criteria, support terms and the recurring costs separately from one-time work. Compare quotes on the same scope so the differences reflect the work, not missing assumptions.

Which costs recur after the first rollout?

Recurring costs usually include the per-user subscription or support plan, server capacity for the document servers, backups and monitoring, and periodic upgrades to new editor and file platform versions. Nextcloud, for example, publishes a new major version every four months and supports each one for a year, so the upgrade cadence should be budgeted. Ask whether the support plan covers signed security updates, long term support windows and upgrade assistance, and whether a retainer is needed for ongoing maintenance after the initial project closes.

Turning the checklist into a selection decision

This sequence turns the requirements checklist into a written platform choice, edition decision and tested architecture. Each step ends with a named artifact that the next step depends on, so procurement signs off on evidence rather than preference.

Confirm formats and run fidelity tests
Collect a representative set of your own .docx, .xlsx, .pptx and PDF files, including templates, tracked changes, comments, macros you rely on, embedded fonts and complex tables. The document owner and a power user from each team that produces these files run them through both candidate editors and log what changes on opening, editing and saving. The step is done when you have a written fidelity log with each defect rated by business impact, and any file type that fails is either accepted as an exception or excluded from browser editing.
Fix user and concurrency numbers
The business owner and IT agree a named user count, the share of users who will edit rather than only view, and the expected number of people co-editing the same document at peak. Ask each candidate vendor how its edition handles simultaneous connections and scaling for your count, and do not rely on a generic figure. The output is a signed sizing sheet that states user count by edition tier, peak concurrency and the assumptions behind them, which feeds the edition and support decision later.
Choose the file platform and WOPI host
Identify the file platform that stores the documents, such as Nextcloud, Seafile or a document management system, and confirm that it can act as a WOPI host with the editor you are considering. The enterprise architect and the file platform owner check the integration path, authentication method and whether directory identities flow through to the editor. The step is done when a written integration statement names the WOPI host, the editor, the supported authentication model and the internal hostnames that must be reachable, which becomes the basis for the traffic policy.
Decide the edition and support plan
Compare community and paid editions against the sizing sheet, the support expectations of your security and operations teams, and the licensing terms that apply to your use, including whether you only consume the editor or embed it in a product you provide to others. Procurement and the CISO review the support levels, security update commitments and upgrade process. The output is a shortlist with one selected edition, the licensed user count, the support tier and a list of items to confirm in writing, such as signed security updates and end-of-life dates.
Set the traffic and AI policy
The security architect defines which networks may reach the document server, how WOPI traffic is restricted to known hosts, whether TLS is terminated and re-encrypted internally, and what audit events are logged for document access and editing. The same owner decides whether an AI assistant is permitted at all, and if so, that it stays off by default and points only to an endpoint you control. The step is done when a signed policy lists allowed hosts, logging scope and AI status, and this policy is passed to the implementation partner as a design input.
Run a proof of concept with real documents
Deploy the chosen editor and file platform in a non-production environment that mirrors your network and identity setup, then have named pilot users open, co-edit, comment and save the documents from your fidelity set. Record the results against the fidelity log and the sizing sheet, including failed file types, latency and login behavior. The proof of concept is complete when the document owner accepts the outcomes in writing, and any open defects have an owner and a remediation or exception decision.
Load test before procurement
Run a load test that reproduces your peak concurrency, including multiple users editing one document, and measure response times, error rates and resource use on the editor servers. Confirm that routing keeps all editors of one document on the same backend where the vendor requires it. The security and platform leads review the results against the sizing sheet, and procurement issues the purchase only after the test report shows the target load is met or the required server count and sizing are documented.

How DeployOpen scopes, delivers and supports document editing requirements

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the requirements in this checklist become a written scope before any work starts. Engagements are typically fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers.

How we scope

We record which file formats must open, edit and save without loss, and which need only viewing or conversion.
We confirm the file platform, identity source and WOPI hosts that the editor must connect to.
We agree in writing the concurrent editor profile, user counts and whether an AI assistant is permitted.

How we build

We deploy the chosen editor in your cloud account, data center or air-gapped network, with WOPI traffic restricted to known hosts.
We configure document routing so every editor of one document reaches the same server, and set resource limits per node.
We test fidelity on your own sample templates, including fonts, tables, macros and forms, before go-live.

How we hand over

You receive architecture diagrams, configuration records, the test results and an edition and license record for your files.
We document backup, restore, upgrade and update-signing steps so your team can run the platform after handover.
Controls and evidence are prepared for your compliance assessors, who issue any audit reports or certifications.

How we support

Support, upgrades and version tracking can be covered by a retainer agreed alongside the original scope.
Security testing of the editor, its document server and its WOPI endpoints can be run on a recurring schedule.
Changes to formats, editions, integrations or AI settings are assessed and scoped in writing before they are applied.

Document editing requirements checklist