What Collabora Online customization covers
Customization for Collabora Online means changing how the editor looks and behaves for your organization, or connecting it to systems you run. It is separate from configuration. Configuration covers the settings the product exposes for normal operation, such as which file formats are enabled, how the server is addressed and which hosts may call it. Customization goes further: it changes branding and themes, adds custom fonts and document templates, alters editor behavior through WOPI CheckFileInfo properties that the host returns for each file, and builds integration work between the editor and your own document platform. Each of these needs a written design, testing against real documents and a plan for upgrades, because changes made against one release can need rework at the next.
The usual triggers are a rebrand that must carry through the editor's interface, a regulated document standard that requires specific fonts, headers or restrictions on what users can do with a file, a home-grown document system that stores files and must hand them to the editor through WOPI, and a template library that must render the same way in every session. Each trigger maps to a different body of work. Branding and fonts are mostly front-end and file-level changes. CheckFileInfo properties are set by the WOPI host, so the host team has to own them. Integration with a home-grown system is software work on both sides of the WOPI interface.
Decide early whether this work stays in-house or goes to a partner. In-house teams are a good fit when they already run the WOPI host and can own upgrades of every custom element. A partner is more useful when the scope spans the host and the editor, or when a fixed-scope delivery with written acceptance tests matters. Collabora's pricing page lists customization services under its Enterprise plan. Confirm with Collabora exactly which changes that plan covers, whether branding, fonts, host integration or code changes to the server, and whether covered work is supported through future releases.
What the work includes
Customization changes how Collabora Online looks, which fonts and templates users get, and how the editor behaves inside your WOPI host. Each package below ends in a written deliverable, and the exact scope is agreed in writing before work starts.
Visual branding and themes
Branding covers logos, colors, and interface elements in the editor, applied through a theme package that is versioned and tested against the Collabora Online release you run. The deliverable is a tested theme package with install and rollback steps. Check that the theme survives point releases, since interface markup can change between branches.
Font installation and licensing checks
Fonts affect how documents render, so the team confirms which typefaces your users rely on, installs them on every coolwsd server, and checks each font's license for server-side use. The deliverable is a font inventory listing source, license terms and install location. Confirm font rendering on a sample of your real documents before cutover.
Template and default document setup
Templates and default settings decide what a new document looks like and which file format a user gets when creating one. The work covers document templates, default styles and the format used for new files. The deliverable is a configuration record that names each template, its owner and the settings it depends on.
CheckFileInfo property decisions
The WOPI CheckFileInfo response carries properties such as edit, view, download and save permissions, and each choice changes what users can do in the editor. The team maps each property to a business rule, tests it for editing, viewing, saving and downloading, and documents the result. The deliverable is a property decision table with test results for each role.
Custom WOPI host integration
When your document platform is not Nextcloud or another listed host, the integration covers WOPI endpoints, file access tokens, and how the host passes the WOPISrc parameter to Collabora Online. Confirm the host's WOPI implementation against the Collabora Online version you run. The deliverable is an integration test report covering open, edit, save and lock behavior.
What drives cost and effort
Each row names one factor that moves customization effort, explains why it matters and gives one practical way to keep it under control.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Host platforms and WOPI hosts | Each host has its own WOPI endpoint, allow list and test cycle, so effort grows with every platform added. | Start with one host and one shared branding package, then add hosts after the first passes acceptance. |
| Depth of branding | CSS, logo and UI text changes are small and repeatable. Changes to core editor interface code need retesting with every release. | Limit changes to CSS, logos and UI strings, and keep them in a versioned theme folder. |
| Custom fonts | Each font needs a license that allows server-side use and embedding, plus rendering checks across every supported format. | Inventory fonts first and confirm each license in writing before adding any font to the server. |
| Templates and document types | Every template and file type, such as docx, xlsx, pptx or Visio, needs its own rendering and save check. | Limit the first release to the templates and formats users open most, and schedule the rest as later phases. |
| WOPI behavior change | Changing CheckFileInfo properties alters editor behavior for every file, so each change needs regression testing in the host. | Keep the property set minimal, document each change and test view, edit and save paths for each host. |
| Integration surface with your document platform | Sign-in, file locking, versioning and permission mapping each need work on the host side and the editor side. | Reuse the host's own access model and avoid building a second permission layer inside the editor. |
| Number of environments | Test, staging and production each need the same customizations applied and a repeatable way to deploy them. | Package customizations as one build artifact and promote that same artifact through each environment. |
| Compliance evidence | Assessors may ask for change records, test results and configuration evidence, which adds documentation to each change. DeployOpen prepares evidence; auditors assess it. | Agree the evidence list before the build starts and capture records during normal testing. |
| Edition in use | CODE is free but not recommended for production. Business adds an SLA and signed security updates; Enterprise adds customization services. | Confirm the edition and its support terms in writing before scoping, and ask which customization services are included. |
Project phases and outputs
The sequence moves from a documented inventory and requirements set through design, a non-production build and testing with real documents, to a controlled rollout and handover, with the exact order and depth shaped by the written scope.
Run discovery and requirements
We inventory the WOPI hosts, document types, fonts, brand assets and editor behaviors that need to change, and confirm which users and groups will edit and which will only view. The output is a signed requirements register that lists each customization, its owner and the acceptance check that closes it.
Design the theme, templates and WOPI properties
We produce a theme and template plan, an integration design covering how the WOPI host and Collabora Online exchange requests, and a WOPI property decision record that states which CheckFileInfo properties are set, why, and what each setting changes for users. Your team reviews and approves the record before any build starts.
Build in a non-production environment
We build the branding, fonts, templates and integration changes in a non-production environment that mirrors your WOPI host and network path. Each change is recorded in version control so it can be reviewed, reproduced and rolled back. The step closes when the build deploys cleanly from the recorded steps.
Test with real documents and users
We test with representative files in each supported format, including docx, xlsx, pptx, PDF and OpenDocument, using documents supplied from your own estate and a group of your users. Results are logged against the requirements register, and defects are fixed and retested until every acceptance check passes or is formally deferred.
Roll out in controlled stages
We move the approved configuration to production in stages agreed in the scope, with a defined group of users first and a documented rollback path. The step closes when the agreed stage has run without open blocking defects and your owner has signed off the cutover.
Hand over with documentation
We deliver the runbooks, configuration records, the WOPI property decision record in its final form, test evidence and the procedure for applying future Collabora Online updates to your customizations. The handover closes when your operations team has walked through the runbooks and accepted the documentation.
Which parts to keep in-house and which to outsource
This table shows which Collabora Online customization tasks your team usually owns, which ones a partner commonly takes, and the skills each task requires, so you can match work to people before you request a quote.
| Work item | Usually owned by | Skills required |
|---|---|---|
| Brand decisions | In-house: brand owner and marketing lead | Brand and content design for logo, colors, tone and editor labels |
| Template content | In-house: document owners and department leads | Brand and content design, plain-language writing for template text and boilerplate |
| Document owner sign-off | In-house: records, legal or compliance owner | Knowledge of your approval process and record retention rules for each template |
| Business rules for editing rights | In-house: IT governance, working with the WOPI host administrator | Understanding of how the host maps groups to view and edit rights, and who approves changes |
| Theme and CSS build | Partner builds, in-house reviews the result | Web front-end skills, CSS and build tooling, browser testing across supported clients |
| Font packaging | Partner packages, in-house confirms font licenses | Typography, font licensing review, and container packaging so fonts load in every server build |
| WOPI behavior analysis | Partner analyzes, in-house supplies host context | WOPI and HTTP protocol knowledge, mapping CheckFileInfo properties to editor behavior, request tracing |
| Integration code | Partner builds, in-house owns the host platform | WOPI and HTTP protocol knowledge, host platform APIs, container packaging for deployment |
| Regression testing across updates | Partner runs tests, in-house signs off on results | Test automation, scripted editing scenarios for docx, xlsx and pptx, and review of release notes before each upgrade |
What usually goes wrong
Most problems in Collabora Online customization come from changes that look small on their own. Each risk below has a prevention step to agree on before the build starts.
Customizations that break on point releases
Custom CSS, patched scripts and edited configuration are often tied to one release line, and a point release can silently remove them. Pin a tested version, keep customizations in a separate build layer, and rebuild from that layer for each update. Run a regression set of documents before every update.
Fonts without server-side rights
Fonts used for server-side rendering, PDF export or embedding must be licensed for those uses, and many font licenses do not allow redistribution inside a container image. Record each font's license terms, confirm server-side rendering and embedding rights in writing, and keep a bill of materials for the fonts in every build.
CheckFileInfo changes that alter rights
The WOPI host returns CheckFileInfo properties that decide whether a user can edit, print, copy, export or download a file. A small change in host logic can flip these flags for an entire group. Document the expected values for each role, test each flag with viewer, editor and anonymous accounts, and review every change before release.
Templates that miss real file formats
A branded template built for one format may not match the docx, xlsx and pptx files users receive from other systems. Inventory the file types in circulation, test each template against representative documents, and check whether fonts, styles, page setup and table layouts carry over correctly.
Integration code tied to one host version
Code that calls the WOPI host's APIs or hooks often depends on one host version's endpoints and behavior. A host upgrade can break the integration while the editor keeps running. Test the integration against each host release you run, and write down which host versions it supports before any upgrade is scheduled.
MPL-2.0 obligations for modified builds
The Collabora Online server code is licensed under MPL-2.0, and distributing modified builds can bring notice and source availability obligations for changed files. Have your legal team review the license before any modified build leaves your organization, and record the decision alongside the build version.
How the work changes by starting point
Nextcloud is the most common starting point. The Nextcloud administration settings and the Collabora server URL decide most of what is possible, so the work centers on configuration and network controls more than on new code.
- Work changes: Editor behavior is set through Nextcloud Office settings, while custom fonts and templates are added to the Collabora server image or package.
- Server URL: Use the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS.
- Allow list: Restrict WOPI requests to the IP addresses of the Collabora servers, as the Nextcloud administration manual recommends.
- Access groups: Decide which groups can open the editor and which groups can edit, and which can only view.
Confirm first: the Nextcloud version, whether the built-in CODE server or a dedicated Collabora server will be used, and who holds the Nextcloud administrator account.
Hosts such as ownCloud, Seafile or a custom platform use the WOPI protocol, but the host side is a separate build. Collabora lists these integrations on its product page, which confirms the protocol path but not the amount of work on your side. Most of the effort sits in the host.
- Host code: Authentication, file lookup, permission mapping and the WOPI endpoints are written or configured by your host team.
- Document lifecycle: Save, lock and version behavior must be tested with live edits, including conflicting edits from two users.
- Branding and templates: These are applied on the Collabora server, but the host must send the right parameters for them to take effect.
- Format and permission tests: Check docx, xlsx and pptx handling, and check edit and view rights for each user role.
Confirm first: the host version and its WOPI support, whether a maintained connector already exists, and who will maintain any custom code after go-live.
Docker and system package installs give the most direct control over the server image or package. Branding and font changes are applied at build time, so each upgrade must reapply them and be checked again.
- Image build: Start from the collabora/code image for a CODE deployment or from the Collabora Online packages for a subscription deployment, then layer fonts, themes and templates on top.
- Upgrades: Rebuild the image or repackage on each point release, and recheck branding and fonts after each rebuild.
- Package signing: Verify RPM and DEB signatures before installing, because Collabora updated the package signing keys for these users in its 25.04 release notes.
- Configuration control: Keep the coolwsd configuration under version control so that every change can be repeated and reviewed.
Confirm first: whether the free CODE edition fits your environment (Collabora describes it as not recommended for production), and whether the image architecture (x86-64, ppc64 or arm64 for collabora/code) matches your hosts.
The official Helm chart is the starting point for Kubernetes. Custom images and replica settings interact with each other, so they must be tested together before release.
- Replicas: The chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set manually and must be tested at the chosen count.
- Routing: The load balancer must route by the WOPISrc parameter so that all users editing one document reach the same pod.
- Custom images: A branded image must be tagged, pinned and deployed with the same replica and ingress settings used in testing.
- Resources: The chart's production guidance is 8 CPU cores and 8000 MiB of memory per pod as limits, with requests of 4 cores and 6000 MiB. Check these against your node sizes and expected concurrency.
- Ingress: Nginx, HAProxy and OpenShift Router are supported, so the cluster's ingress controller shapes the routing setup.
Confirm first: the chart version, the ingress controller in use, and how sticky routing will be verified before users go live.
Air-gapped networks change the supply chain more than the code. Fonts, packages, images and updates must be brought in by hand, checked and recorded before they reach the server.
- Transfer: Move fonts, system packages, container images and point releases through an approved media process, keeping a record of each file.
- Verification: Check package signatures and image digests against the vendor's published keys and hashes before import, and apply the updated RPM and DEB signing keys in the offline mirror too.
- Internal mirrors: Confirm whether your package repositories and container registry can host the Collabora packages and their dependencies.
- Updates: Plan how security advisories reach the offline environment and how they move through your change approval process.
- Outbound features: Confirm which features make outbound requests. The optional AI assistant in 26.04 is off by default, and its provider can be hosted on your own infrastructure.
Confirm first: whether internal-only traffic between Nextcloud or another WOPI host and the Collabora server is permitted, who approves media transfers, and how quickly security updates can be applied.
What you need to provide
Customization work moves at the pace of the decisions and files you supply, so gather these inputs before the written scope is signed. Name one business owner who can make brand and template decisions without waiting for committee sign-off. Provide your brand assets and any style guide, plus a list of every font used in your documents with the license record for each one. Supply sample documents from each department, since templates and font checks are only as good as the files they are tested against.
Describe your WOPI host and its exact version, because CheckFileInfo properties and host-side behavior depend on both. Confirm that the team can reach a non-production Collabora Online server and a non-production host environment, and that it can change settings in both. Also nominate a test group of users from several departments who will open branded templates and edit sample files before anything reaches production.
Decide who can edit, view and download before the build starts. Name one owner who approves every change to editing and download behavior. Settle which groups may edit, which may only view, and which may download, because host-side group rules and CheckFileInfo settings both depend on those answers. Late decisions here cause most of the rework, since a template, watermark or download setting tested against the wrong permissions has to be rebuilt and retested. Write the permission matrix down and sign it off first.
Frequently asked questions
What drives the cost of Collabora Online customization work?
The main drivers are how many changes you need, whether they only change appearance or also change how the editor behaves, and how much they touch your own document platform. Branding, themes, fonts and templates are usually the smallest items. Changes to WOPI CheckFileInfo properties, and integrations with your document platform, need more design and testing. Build work is one-time, while retesting after each Collabora update recurs. Ask any quote to itemize build, testing, documentation and handover separately, so you can see what recurs.
How long does Collabora Online customization take to deliver?
The duration depends on scope, so no single timeline applies to every project. A logo and colour change on one host differs greatly from editor behavior changes wired into several integrations. The main factors are the number of customizations, the number of document types and templates in use, the number of WOPI hosts, and how many approval rounds your brand and security teams require. Most engagements are fixed-scope, so ask for the timeline and milestones in writing before work starts.
Can our internal team customize Collabora Online without an outside partner?
Often yes, if the team has skills in Linux server administration, WOPI, coolwsd configuration, web front-end styling and font licensing. The work is mainly about careful change control and testing. Collabora's CODE edition is described as suited to testing, home use or small teams and is not recommended for production, so plan your production environment on the edition you have licensed. Collabora's Enterprise plan lists customization services, so ask Collabora whether those services fit your needs before deciding.
Can Business plan customers buy customization work for Collabora Online?
Collabora's pricing page lists customization services under the Enterprise plan, which is for 100 or more users. The Business plan, at 3 euros per user per month for up to 99 users, includes long term support, a service level agreement, signed security updates and customer portal access, but that page does not list customization services. Confirm in writing with Collabora whether Business customers can buy customization. Separately, DeployOpen's scope and fees are agreed in writing with you, and you should confirm whether any part of the work depends on your Collabora subscription terms.
Do custom Collabora Online changes survive new releases?
Not automatically, so plan for retesting. Keep customizations in version-controlled files separate from the stock installation where possible, and record every change so it can be reapplied. Collabora maintains release branches, such as 25.04, which still received point releases into 2026, so test each point release against your customizations before rollout. Confirm with Collabora which customization points it supports across major release branches, and make that a written requirement in your scope.
What must our team provide, and what do we receive at the end?
Your team typically provides brand assets, font files with licenses, template documents, a staging WOPI host for testing, and named approvers for design and security decisions. You receive the configuration and theme packages, the documentation of each change, test results, and a handover to your operations team. The exact list of inputs and deliverables is set out in the written scope, so ask for it to be itemized before you compare quotes.
How DeployOpen delivers this service
DeployOpen plans, customizes, tests, documents and supports Collabora Online inside your own infrastructure, so branding, templates and WOPI behavior changes are scoped in writing before any build starts. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Written scope lists each branding, theme, font, template or WOPI property change you request
- We record which WOPI host and document types each customization must work with
- We confirm which Collabora Online edition and version your customizations will target
- We agree the test cases and acceptance criteria before development begins
How we build
- Customizations are built against your chosen Collabora Online version and kept under version control
- Custom fonts and templates are checked for every format in scope, including docx, xlsx and pptx
- WOPI CheckFileInfo property changes are tested with each host and each permission group you use
- Integration work with your document platform is tested in a staging environment matching production
How we hand over
- You receive the source, configuration and build steps needed to reproduce each customization
- Documentation covers how each change was applied, tested and how to roll it back
- Upgrade notes describe which customizations need review when a new Collabora Online release arrives
- Handover includes a walkthrough with your administrators before the engagement closes
How we support
- Ongoing support can be arranged as a retainer covering reviews of customizations after updates
- Point releases and security advisories are assessed against your customized components
- Customizations are retested when your WOPI host or Collabora Online version changes
- Support scope, response expectations and exclusions are written into the retainer agreement
