Self-hosted document editing for teams that cannot send files to a public cloud
Staff edit Word, Excel and PowerPoint files every day, and many of those files hold regulated or confidential content that should not leave the organization's own environment. The usual open-source path is to run ONLYOFFICE Docs or Collabora Online as the editing engine, integrated with a self-hosted file sharing platform such as Nextcloud, so that documents stay on servers you control and users edit them in the browser. ONLYOFFICE Docs is licensed under AGPL-3.0 and is compatible with Office Open XML formats. Collabora Online's source code is licensed under the Mozilla Public License 2.0. Both are used in this role, but they differ in format handling, collaboration features, and the way their editions and connectors are packaged, so neither should be assumed to match Microsoft 365 feature for feature.
The choice depends on who needs the service and what they open most often. Teams that exchange heavily formatted Office files, forms or spreadsheets with complex macros and charts should test those exact files in each editor before committing, since rendering differences are the most common source of user complaints. Teams whose work is mostly text documents and whose license posture favors MPL-2.0 may find Collabora Online a closer fit. Confirm with each vendor which editions include co-authoring, how concurrent connection limits are counted, and which integration connector your file sharing platform supports. Treat the pilot as a format test: take a sample of real files from each department, open and co-edit them, and record what breaks.
Plan the rollout around three decisions: where the editing server runs and how it is reached from the file sharing platform, which user groups get access first, and how legacy files are handled. Editing traffic and document conversions need enough CPU and memory to serve peak co-editing sessions, and the sizing should come from a test with your own document mix rather than from a generic figure. Restrict who can start a session through the file sharing platform's permissions, keep the editing server on an internal network segment, and make sure audit logging captures document access, since frameworks such as the HIPAA Security Rule expect audit controls over systems containing ePHI. Ask any implementation partner to deliver a written scope that covers sizing, connector configuration, backup of the document store, and a user communication plan.
What to agree on before choosing a document editing platform
Most editing projects stall because the decisions below were never made explicitly. Format fidelity, concurrency, sharing, identity, residency and operations each change which editor fits and how it is sized. Settle them in writing first, then test the candidates against them.
Office formats that must round-trip
List the DOCX, XLSX, PPTX and PDF files your users open daily, including macros, tracked changes, comments, embedded charts and fonts. Both ONLYOFFICE Docs and Collabora Online can open and save these formats, but fidelity varies by feature and by file. Ask each vendor for a test run against a sample of your own documents, and decide who signs off on acceptable differences.
Expected concurrent editors
Estimate how many people edit the same document at once, not how many accounts exist. Peak concurrency, document size and the number of open sessions drive server load and any connection limits in the licensing you choose. Confirm the connection terms of your chosen edition in writing before sizing hardware.
File sharing platform already in use
Decide whether the editor will sit inside Nextcloud, Seafile or another sharing system, or run as a standalone service. Integration determines how permissions, versioning, locking and external links behave. Confirm which connector your sharing platform supports and who maintains it after go-live.
Identity and single sign-on
Define how users authenticate to the editor and whether document access follows the same groups and roles as file sharing. Check whether the editor accepts the identity provider you run and how session lifetime is enforced. Mismatched identity models are the most common cause of documents that open for some staff and not for others.
Data residency and network isolation
Document contents, previews and temporary conversion files all need a known location. Decide which regions, data centers or air-gapped segments may hold them, and whether the editing service may reach external font or update servers. Ask the vendor to document every outbound connection the service makes so your firewall rules match reality.
Who operates the service
Assign named owners for patching, backups, certificate renewal, capacity reviews and incident response before selecting a product. Decide whether internal staff, a partner under a written support agreement or a mix will run it. Ask any implementation partner which tasks are included at go-live and which recur under a retainer.
ONLYOFFICE Docs or Collabora Online: which open-source option fits
This table compares ONLYOFFICE Docs and Collabora Online on the factors that decide the choice: license obligations, format fidelity, connector support, limits and operating effort. Read each row as a question to put to the vendor and your own test team before you commit. The main takeaway is that the license, the file platform you already run, and the Office formats your users rely on matter more than feature lists.
| Decision factor | ONLYOFFICE Docs | Collabora Online |
|---|---|---|
| License | AGPL-3.0 for the server code. Review what network use of a modified version requires from your legal team. | Mozilla Public License 2.0 for the source code. Confirm file-level obligations for your modifications with counsel. |
| Format compatibility | States compatibility with Office Open XML formats. Test your own .docx, .xlsx and .pptx files, including macros and complex layouts. | Built on LibreOffice technology. Test Office files in your own corpus, since rendering differences in complex documents are common. |
| Current release reference | v10.0.0, published October 12, 2026 (ONLYOFFICE DocumentServer repository). | Confirm the current release and its changelog with Collabora before planning the pilot. |
| File platform connectors | Confirm the connector version for Nextcloud Server (AGPL-3.0, v33.0.10) or Seafile (GPLv2 with OpenSSL exception) in your environment. | Confirm the integration path for Nextcloud or Seafile, including WOPI behavior and version support, with the vendor. |
| Connection and licensing limits | Ask the vendor for concurrent connection limits and whether any commercial edition changes them. | Ask the vendor for concurrent session limits and how the chosen support tier affects them. |
| Sizing driver | Concurrent editors, document size and conversion load. Ask for memory and CPU guidance per concurrent session. | Concurrent editors, document size and conversion load. Ask for memory and CPU guidance per concurrent session. |
| Operating effort | Document Server is a separate service with its own updates, JWT secret and certificate handling. Plan for patch cadence. | Separate service with its own updates and TLS configuration. Plan for patch cadence and monitoring of conversion workers. |
| Best fit | Teams that need strong Office fidelity and a documented connector to their file platform. | Teams that prefer MPL-2.0 terms and accept testing for fidelity on complex Office files. |
How AGPL and MPL terms affect your deployment
The license question for self-hosted document editing is less about whether you can run the software and more about what you owe when you change it or open it to users. ONLYOFFICE Docs is licensed under AGPL-3.0, and the AGPL's network-use clause is the part that matters most here. In plain terms, if you modify the editor and let people use the modified version over a network, the AGPL can require you to make the corresponding source of those modifications available to those users. Simply running the unmodified editor for your own staff, behind your file sharing platform, is a different situation from patching the editor, embedding it in a customer portal, or offering it as a service to third parties. Have counsel confirm the obligations for your specific modifications and distribution model before go-live, and record the version and any patches you apply so the answer can be checked later.
Collabora Online's source code is licensed under the Mozilla Public License 2.0, which works differently. MPL 2.0 is a file-level copyleft: changes to MPL-covered files must stay under MPL when you distribute them, but code you write in separate files that merely interacts with the editor is not pulled into the same obligation, and MPL 2.0 has no network-use trigger comparable to the AGPL's. That makes the MPL path easier to reason about for integrations, though it still does not replace a legal review of your own modifications. Whichever editor you choose, list every component in the stack and its license, including the file sharing platform it connects to, such as Nextcloud Server under AGPL-3.0, so that your license inventory matches what is deployed.
Format compatibility is a testing task, not a vendor promise. Build a sample corpus from your own documents: files with macros, tracked changes and comments, embedded objects such as charts and spreadsheets, complex tables with merged cells, and the fonts your organization actually uses. Open each file in the editor, edit it through two or more accounts, and compare the rendering and saved output against the desktop Office originals. Record every difference in pagination, table layout, and macro behavior, and decide which ones block adoption. Macros in particular often need a separate decision, since the browser editor may not run them the way desktop Office does. Confirm the supported formats for your chosen editor against its current documentation and keep the corpus as a regression set for every upgrade.
Reference architecture components and how they connect
A self-hosted editing deployment is a chain: users reach the file sharing front end, which hands documents to a separate editing server through the reverse proxy. Each link needs its own sizing, hardening and recovery plan, because a weak point in any one of them exposes the whole chain.
File sharing front end
The file sharing platform, such as Nextcloud Server (AGPL-3.0) or Seafile (GPLv2 with an OpenSSL linking permission), holds the files, permissions and sync clients, and calls the editor when a user opens a document. Confirm that the connector for your chosen editor supports your file sharing version and that the document server URL and JWT secret are configured consistently on both sides. Check how external shares interact with editing rights before opening links to outside users.
Document editing server
ONLYOFFICE Docs (AGPL-3.0) or Collabora Online (MPL 2.0) runs the real-time editing sessions. Size it for concurrent editing sessions, memory per session and CPU for rendering, and confirm the connection limits and any licensing conditions for the edition you plan to run. Test the formats your users rely on, including macros, complex spreadsheets and legacy .doc files, before you commit.
Document conversion service
The conversion service renders and converts documents for viewing, previews and format changes, and it is often the most resource-hungry part of the stack under load. Run it on its own host or container group when volume grows, and set limits on file size, page count and conversion time so one large file cannot starve interactive editing. Confirm how the service handles queued jobs and failed conversions in your chosen product's documentation.
Reverse proxy and TLS
A reverse proxy terminates TLS for both the file sharing platform and the editor, and must pass WebSocket connections that real-time co-authoring depends on. Use valid certificates, enforce modern TLS settings, and set request body and timeout limits that match your largest documents. Route the editor's internal service endpoints so they are not reachable from the public internet, and log access for audit review.
Storage and database
Files live on the file sharing platform's primary storage, while its database holds metadata, shares, locks and version history, and the editor keeps short-lived session data. Size storage for file versions and trash retention, not only current content, and choose a database engine your team can back up and restore. Confirm where temporary editing files are written and cleaned up, because stale copies are a common source of storage growth and data exposure.
Identity federation and audit
Users should sign in through your existing identity provider using SAML or OpenID Connect, with group membership controlling who can edit and who can only view. Confirm which federation options your file sharing version supports, and make sure audit logs record document opens, edits, shares and downloads with user and time. Keep those logs in a location separate from the application servers.
In-house, partner or SaaS: who carries the document editing workload
This table compares building document editing in-house on ONLYOFFICE Docs or Collabora Online, working with an implementation partner, and buying a commercial SaaS suite. Read each row as a question to answer for your own organization, and use the last row to see what every quote should spell out before you compare totals.
| Decision factor | In-house on open source | Open source with a partner | Commercial SaaS |
|---|---|---|---|
| Data location | Documents and editing sessions stay in your own data center or cloud accounts, under your control | Hosted in your infrastructure, with the partner working inside your environment under agreed access terms | Documents are processed in the vendor's environment, so confirm region, subprocessors and where editing sessions run |
| Internal skills needed | Staff for Linux, container or service operations, reverse proxy and TLS, storage integration, upgrades and monitoring | Smaller internal team to own requirements, access approvals and user support, with the partner covering build and runbooks | Mainly administration of tenants, licenses and user policies, with platform operations handled by the vendor |
| One-time setup | Internal engineering time for design, integration with file sharing, hardening and testing | Fixed-scope implementation defined in writing, covering integration, hardening, documentation and rollout | Tenant configuration, identity integration and migration of existing files, usually with less build work |
| Recurring cost | Staff time for patching, capacity growth, backups and incident response, plus any licensing for editions you choose | Support or retainer fees for upgrades and monitoring, plus internal staff time and any commercial license terms | Subscription fees per user or tenant, often with add-ons, and recurring cost tied to plan limits |
| Licensing and connection limits | Confirm the license terms of the chosen editor and the connection or user limits of the edition you deploy | Partner should confirm license terms and connection limits in the written scope before sizing | Limits are set by the plan, so confirm concurrency, storage and feature caps in the contract |
| Exit options | Full control of data and configuration, with migration effort depending on how well the setup is documented | Documentation, runbooks and knowledge transfer should be defined as deliverables so you can move operations in-house | Exit depends on export formats, data return terms and the contract notice period, so review them before signing |
| What the quote must include | Internal estimate covering design, build, test, staffing and recurring operations | Scope, deliverables, environment list, support boundaries, handover items and any third-party license costs | Per-user and add-on pricing, data residency terms, support levels and export or termination terms |
How a document editing rollout runs, phase by phase
The sequence moves from a tested inventory of your real documents to a supported service that users adopt in stages, with each phase producing a signed-off output before the next one starts. Timing for each phase should be agreed in the written scope rather than assumed.
Run discovery and format corpus testing
Your team and DeployOpen inventory the document types in use, the Office versions and macros people rely on, the fonts and templates that must render correctly, and the peak number of people who edit at the same time. DeployOpen then opens a representative sample of files in ONLYOFFICE Docs or Collabora Online and records where layout, tracked changes, comments, spreadsheet formulas or embedded objects differ from the original. The output is a signed format compatibility report with a list of accepted gaps and the workarounds for each one. The phase is done when the business owners accept that list in writing.
Design the architecture and size the deployment
DeployOpen drafts the reference design: the document server, the file sharing platform that calls it, the database, storage, load balancing and the network path between them. Sizing follows from the concurrency and file profile found in discovery, and the design records the connection limits and licensing terms that apply to the chosen editor. The output is an architecture decision record and a sizing worksheet that your infrastructure and security teams review. The phase is done when both teams approve the design and the capacity assumptions are written down.
Pilot with a single department
One department that uses Office files daily is moved onto the platform in a controlled pilot, with its usual file shares and external collaborators included. DeployOpen supports the pilot group, logs editing errors and performance issues, and tunes the configuration based on what users actually encounter. The output is a pilot report listing defects found, fixes made and open items with owners. The phase is done when the pilot group confirms the editing experience meets the requirements from discovery.
Integrate identity and file sharing
The editor is connected to the file sharing platform so that opening, co-editing and saving run through the same permissions your users already have. Single sign-on, group mapping, sharing rules and the handling of editor sessions are configured and tested against your identity provider. The output is a test record that shows permission enforcement, session expiry and save behavior for each role. The phase is done when your identity team has verified that a user without access cannot open or edit a file through any path.
Harden the stack and test backups
DeployOpen applies the hardening baseline agreed in the design, covering transport encryption between components, restricted service accounts, logging, and patching procedures. Backup and restore are tested by restoring files and their document server dependencies into a separate environment and checking that co-authored documents open correctly. The output is a hardening record mapped to your control framework and a restore test report with measured results. The phase is done when a restore test has succeeded and the results are accepted by your operations team.
Migrate users in stages
Remaining departments are onboarded in waves, each with a short briefing, guidance on known format differences, and a named contact for questions. Users are informed which file types open in the editor and which still need a desktop application. The output is a wave log showing the groups moved, the support tickets raised and the issues closed. The phase is done when each wave closes with no open blocking defects and the support load has settled to an expected level.
Hand over with runbooks and training
DeployOpen delivers the operational documentation: runbooks for restarts, scaling, certificate renewal, backup and restore, upgrades and incident response, along with administrator training for your team. The handover also confirms who owns each component after the project ends and whether ongoing support or upgrades are covered by a retainer. The output is an accepted runbook set, a training record and a responsibility matrix. The phase is done when your named operators can execute the core runbooks without DeployOpen present.
Systems the editing service must connect to
A document editing service is only as useful as its connections. The editor must work through the file sharing platform, sign users in through the corporate identity provider, sit behind a managed reverse proxy, store and back up documents, and feed its activity into security monitoring. Each connection has a different owner, so agree on those owners before the first user opens a file.
File sharing connector setup
The editor does not store your files. The file sharing platform hands each document to the editor through a connector, and the connector must match the versions of both products. Confirm which connector your file sharing platform supports for the editor you choose, and test it with the file types your users rely on most, including macro-free spreadsheets and PDF forms. Ask the implementation partner who maintains the connector after upgrades, because a mismatch often appears only when one side is updated.
SSO through the identity provider
Users should open documents without a second login. The file sharing platform and the editor both need to trust the same identity provider, usually through SAML or OpenID Connect, and the editor must accept the session the file sharing platform issues. Decide who can open, edit and share documents by group, and confirm that disabling a user in the directory also removes their access to open documents already in the editor. The identity team typically owns the trust configuration, and the platform team owns the connector settings.
Reverse proxy and certificates
The editor runs its own web service that must be reachable from users' browsers and from the file sharing platform on the internal network. A reverse proxy handles TLS termination, WebSocket traffic for co-authoring, and upload size limits, and the certificates must cover every hostname the two services use. Check that the proxy passes the headers the editor needs to validate requests, and set a renewal process with a named owner, since an expired certificate stops editing for all users at once. The network or infrastructure team usually owns this layer.
Storage and backup
Document content lives in the file sharing platform's storage, but the editor keeps temporary working copies and its own configuration, database and cache. Back up both the file sharing data and the editor's state together, and test a restore that brings back a document and its edit history consistently. Confirm the retention period for document versions with records managers, because version retention and backup retention are separate settings. The infrastructure team owns the backup jobs, and the application owner signs off on restore tests.
Audit forwarding to the SIEM
Open, edit, share and download events should reach your security monitoring platform, not only the local logs of each service. Forward logs from the file sharing platform, the editor and the reverse proxy with consistent timestamps, and map each event to a user identity. This matters for regulated records, since the HIPAA Security Rule expects audit controls that record and examine activity in systems holding ePHI. Ask the SOC which events they need, how long logs are kept, and who reviews alerts.
Email notifications
Sharing invitations, mention alerts and review requests usually leave the file sharing platform as email. Those messages need a sending account, SPF, DKIM and DMARC records for the sending domain, and a relay that your mail platform accepts. Without this setup, notifications often land in spam, and users stop trusting them. Confirm which team operates the mail relay and whether notifications should be disabled for externally shared documents.
Questions to ask an implementation partner before signing
Ask these questions before the scope is signed, and require the answers in writing so they become part of the agreed deliverables. Start with format testing: ask which Office Open XML and legacy formats the partner will test, whether the test corpus includes documents from your own departments (macros, tracked changes, embedded charts, complex tables), and how results are recorded. Ask who performs the tests on ONLYOFFICE Docs or Collabora Online and whether the editor's own behavior is compared with the desktop Office files your users actually open.
Next, connection limits and sizing. Ask how many concurrent editing sessions the partner will load test, what user profile the test simulates (simultaneous co-editing on one document versus many users on separate files), and which assumptions drive the sizing for memory, CPU and document server nodes. Ask the partner to show the assumptions in writing so you can challenge them. Also ask how license obligations will be documented: which license applies to each component you deploy (the editor, the file platform, any connectors), whether the partner will produce a bill of materials with license identifiers, and who reviews it with your legal team. Confirm the license terms yourself from the upstream repositories, since a partner's summary is not a substitute for them.
Finally, operations. Ask for a backup and restore test with a recorded restore time against an agreed data set, not just a backup job that reports success. Ask how upgrades to the editor and to the file platform are sequenced, who tests compatibility first, and how a failed upgrade is rolled back. Confirm support hours, response expectations and whether the partner or your team owns each runbook after handover. Request a written list of which runbooks are delivered, who maintains them, and how they are tested.
What buyers ask about self-hosted document editing
What drives the cost of self-hosted document editing?
Cost is driven by who does the work and how many concurrent editing sessions the platform must serve. Software licensing is only one line item: the editing server (ONLYOFFICE Docs or Collabora Online) is typically free to download under its open-source license, but you pay for the infrastructure that runs it, the integration with your file sharing platform, the project work to plan and test it, and the staff time to operate it afterward. ONLYOFFICE Docs is licensed under AGPL-3.0 and Collabora Online source code is under the Mozilla Public License 2.0, so the license terms differ in ways your counsel should review, especially if you modify the code or offer it to third parties. Ask any implementation partner for a written scope that separates one-time setup from recurring support, upgrades and hosting, and state the expected number of concurrent editors so the quote reflects real load.
How long does a self-hosted document editing rollout take?
The timing depends on the integration path, the size of the user base and how much existing content must be tested. The main variables are the file sharing platform you connect to, whether you need single sign-on and document permissions mapped from your directory, the number of document formats your users rely on, and the change management needed for training. Timelines are agreed in the written scope before work starts, so ask for phases with clear acceptance criteria rather than a single end date. A pilot group using real documents usually surfaces the issues that determine the rest of the schedule, so plan for that step explicitly.
What does the work need from our IT and security teams?
Your IT and security teams own the decisions that the editing service depends on: where it runs, how it is reached, and who can access what. Expect to provide hosting capacity in your own cloud account, data center or air-gapped network, DNS and TLS certificates, network rules between the file sharing server and the editing server, and identity configuration. Security reviewers will want to confirm how documents are encrypted in transit, how access is logged, and how the service is patched. The HIPAA Security Rule at 45 CFR 164.312 describes technical safeguards for ePHI transmitted over electronic networks and audit controls for systems that hold it, so healthcare organizations should map those requirements to the editing architecture with their compliance lead.
Can our own staff run self-hosted document editing after go-live?
Your staff can run it if they have Linux, container and web server operations skills, a monitoring process and a defined upgrade routine. Day-to-day tasks include watching service health, managing certificates, reviewing logs, applying security updates and restoring from backup. Teams without that capacity often choose a retainer for upgrades, testing and support instead of building the skills in house. Ask a partner to document the runbook, hand over administration access, and run a restore test with your staff present so ownership is confirmed in practice rather than on paper.
How do you test that Office files keep their formatting?
Format fidelity is tested with a representative sample of your own documents, not vendor demo files. ONLYOFFICE Docs is described as compatible with Office Open XML formats, but compatibility should be verified against the templates, macros, fonts, tracked changes, comments and embedded objects your organization actually uses. A practical test set includes documents created in several Office versions, files that come from external partners, and spreadsheets with complex formulas. Record which files open, edit and save without changes, and which need manual rework. Agree the acceptance threshold in writing before testing starts, and retest after every platform upgrade.
How do connection limits affect sizing for document editing?
Connection limits determine how many people can edit simultaneously, and they set the capacity you need on the editing server and the network path to it. Each open document session consumes server resources and a persistent connection, so peak concurrent editors matter more than total headcount. Start by measuring usage in your current file sharing platform, then ask the vendor and your partner to confirm the documented concurrent connection limits for the specific editing server version you plan to run. Load test with realistic document sizes, and size for peak periods such as month-end reporting rather than average days.
What happens to the editing service during an upgrade?
An upgrade touches the editing server, the file sharing integration and, often, the document format handling, so each component needs its own test. Plan for a staging copy of the environment, a documented rollback path and a backup taken before the change. Release notes and version numbers change frequently, so confirm the target version and its compatibility with your file sharing server before scheduling the window. Ask your partner whether upgrades are included in a support retainer, how regression tests will be run against your sample documents, and who approves production changes.
How DeployOpen scopes, builds and supports document editing
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For document editing, that means agreeing the editor, file sharing integration and sizing in writing before any build work starts.
How we scope
- Inventory the Office formats, macros and templates your teams actually open, edit and share today
- Agree the editor choice between ONLYOFFICE Docs and Collabora Online against your license review and feature needs
- Size concurrent editing sessions, document server nodes and storage based on your user profile and peak hours
- Put scope, deliverables and timelines in writing; most engagements are fixed-scope
How we build
- Deploy the document server and connect it to your file sharing platform with secure JWT-based integration settings
- Configure access controls, external sharing limits and audit logging so editing activity can be reviewed
- Test format round trips, co-authoring, locking and conflict handling with a representative document set
- Document configuration, network paths and the sizing assumptions behind each decision
How we hand over
- Deliver runbooks for restarts, certificate renewal, scaling the document server and clearing stale sessions
- Walk your administrators through user onboarding, template management and troubleshooting common format issues
- Provide a rollout plan with pilot groups, communication templates and a feedback loop for editing problems
- Hand over backup procedures and restore tests covering both document storage and editor configuration
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Apply editor and file sharing updates in a tested order, with a rollback path for each change
- Re-run format and co-authoring checks after upgrades and before enabling new user groups
- Provide documentation updates and evidence packs for compliance reviews, without issuing audit opinions
