How Collabora Online and Alfresco connect for browser editing
Collabora Online is connected to Alfresco through the WOPI protocol, using Jeci's Collabora Online connector for Alfresco Share and the Alfresco Content App. If your documents live in Alfresco Community and your users want to open and edit them in the browser without downloading a copy, this is the pattern to plan around. Collabora lists Alfresco among the WOPI integrations it documents for Collabora Online, but the connector itself is a third-party component maintained by Jeci, not a Collabora product. Before you plan anything, confirm with Jeci which connector release matches your Alfresco Community release, because the connector, the Alfresco version and the Collabora server version all have to line up.
In plain terms, the connector lets Alfresco act as the WOPI host. When a user chooses to edit a document, Alfresco gives the browser a link to the Collabora server with a WOPI source address that points back to that document. The Collabora server then calls Alfresco to fetch the file, renders the editing session in the browser, and writes changes back through Alfresco when the user saves. Alfresco stays the system of record for content, versions and permissions, and the Collabora server never needs its own copy of the repository. That division is what makes the Alfresco side of the design the part to review most closely.
Two consequences follow for the rollout. First, the Collabora server must be able to reach Alfresco over the network, and the browser must be able to reach the Collabora server, so network paths and TLS certificates for both hops need to be checked early. Second, every save depends on Alfresco accepting the write, so you should confirm how the connector handles locked documents, version creation and failed saves in your release. Ask Jeci and your Collabora support channel for a written description of the WOPI endpoints the connector implements and the Collabora versions it has been tested against.
What you need in place before installing the connector
The connector sits between Alfresco and a Collabora Online server, so both halves must be ready before anything is installed. The cards below cover the version pairing, the editor server and its subscription choice, the network paths in both directions, TLS, and the Alfresco identity the connector uses.
Alfresco Community version and connector release
Confirm which Alfresco Community version you run and which release of Jeci's Collabora Online connector supports it. Do not assume a newer connector works with an older Alfresco build. Ask Jeci for the exact version pair and the install steps for your Share or Content App setup, and record both versions in your change request before scheduling work.
Self-hosted Collabora Online server
Plan a Collabora Online server inside your own infrastructure that the connector can reach. The free CODE image is suitable for a test lab only, since Collabora does not recommend it for production. For production, plan for the Business or Enterprise subscription, which adds long term support and signed security updates. Confirm the subscription terms with Collabora before go-live.
Network reachability in both directions
Alfresco must reach the Collabora discovery endpoint to learn which file types it can open, and Collabora must reach Alfresco to fetch and save documents over WOPI. Map every hop, including reverse proxies, firewalls and any load balancer in front of the Collabora server, and test both directions from the actual hosts. Confirm exact ports with Jeci and Collabora.
Matching TLS certificates and protocol
Use the same protocol for the Alfresco URL and the Collabora server URL, and prefer HTTPS on both. Certificates must be trusted by the systems that call them, including the Collabora server's view of the Alfresco certificate chain. Mixed HTTP and HTTPS settings are a common cause of failed document opens, so verify each URL end to end before users test.
Alfresco service identity and permissions
Decide which Alfresco account or service identity the connector and WOPI calls will use, and what that identity may read and write. Document who can open a document in the editor and who can co-edit it, because Alfresco permissions will govern that access. Use a dedicated account with the least rights needed, and record its password rotation process.
Allow list and access restrictions
Decide which Alfresco hosts may send WOPI requests to Collabora and restrict the Collabora server to them where your network allows. The Nextcloud guidance on restricting WOPI requests to known server addresses is a useful model even though the platform differs. Agree the allow list with your network team and write down the addresses that will be permitted.
Configuration sequence for the Alfresco connector
This sequence takes a team from version checks to a verified, permission-restricted editing path between Alfresco Community and a self-hosted Collabora Online server. Each step ends with a check so that no later step starts on an unverified foundation.
Confirm versions and prerequisites with Jeci and Collabora
Before any installation, ask Jeci which Alfresco Community versions, Share and Content App builds, and connector releases are supported, and ask Collabora which Collabora Online branch and deployment method the connector expects. Record the Alfresco tier, operating system, network zones and the host name that users and Alfresco will each use to reach Collabora. Confirm that the vendor documentation for the connector matches the Collabora branch you plan to run, since the 25.04 and 26.04 branches are both in active use. You are done when the written compatibility answer from both parties is on file and signed off by the platform owner.
Deploy the Collabora server and check its discovery endpoint
Deploy Collabora Online on infrastructure you control using the method your team has chosen, and place it behind a TLS-terminating reverse proxy with a stable host name. Request the discovery endpoint from a machine on the Alfresco network and from a user workstation, using the HTTPS address. The check passes when both requests return an XML discovery document that lists the document types you intend to edit, with no certificate warnings. If the request fails from either location, fix routing or certificate trust before continuing, because the connector cannot negotiate a session without it.
Install the connector on the Alfresco tier that serves the client
Install Jeci's Collabora Online connector on the Alfresco tier that serves the interface your users actually open, either Alfresco Share or the Alfresco Content App, following the vendor instructions for that tier. Do not install it on both tiers unless the vendor documentation says the two are supported together. Restart the Alfresco services as the vendor directs and confirm in the logs that the module loaded without errors. The check is a clean startup and an edit action appearing for a supported file type in the chosen interface.
Set the Collabora URL and WOPI host address
In the connector configuration, enter the HTTPS URL of the Collabora server as its discovery address, and set the WOPI host address that Collabora will call back to reach Alfresco. Use the same protocol for both where the vendor allows it, and confirm that the WOPI host address is reachable from the Collabora server, not only from a browser. Restrict callbacks to the known network paths, since the Nextcloud administration manual recommends limiting WOPI requests to the Collabora server addresses, and an equivalent restriction should be considered here. The check is a successful test from Alfresco that reports the Collabora server as reachable in both directions.
Restrict which groups can open and edit
Create or select Alfresco groups for viewing and for editing, and map the connector's permissions to them so that only approved groups can open a document in the editor and only editing groups can change it. Keep the view group broader than the edit group, and avoid granting editing rights through a general group that contains every user. Test with one account from each group and confirm the results in the Alfresco audit or access logs. The check is that a view-only account sees a read-only session and an editing account can save a change, with no other path to edit.
Test with a single document in a non-production repository
Create a test folder in a non-production Alfresco repository and upload one document in each format you plan to support, such as docx, xlsx and pptx. Open each document first as a read-only user, then grant edit rights to a test account and confirm that changes save back to the same Alfresco node with a new version. Check formatting, embedded images and any macros against the originals, and confirm that a second user opening the same document sees the expected lock or co-editing behavior. The check is a written test record covering each format, each permission group and each save result, reviewed before any production repository is connected.
Share or Content App: which client to wire first
Alfresco Share is the classic web client that many long-standing Alfresco Community sites use for document libraries, site collections and workflow tasks. Users in this group are often records staff, departmental admins and power users who already work in folder trees and document lists. Before you commit to Share as the first client, confirm in the Jeci connector documentation which Share versions, site configuration steps and document library views it supports, because Share customization is where connectors most often differ.
- Who uses it: long-standing site members who work in document libraries and expect edit actions beside existing metadata.
- Where edit actions appear: confirm in the connector documentation whether the edit action is added to the document actions menu, the preview or both, and whether it appears in every library view.
- What to confirm: the supported Share version, the module installation steps, the WOPI host settings and any required changes to the Alfresco configuration files.
- What to test separately: permissions on sites with mixed roles, folders with inherited rights, and documents opened from search results.
- Upgrade risk: test again after any Share upgrade or custom theme change, since UI extensions can break silently.
Treat Share testing as its own track even if the Content App works, because the two clients render actions and permissions differently. Check that your first pilot site covers each role you plan to support.
The Alfresco Content App is the newer web client built on the Alfresco platform APIs. Its users tend to be people who work in a modern browser interface, including teams that do not need the full Share site model. Whether the Jeci connector supports this client, and how it is installed, is something to confirm in the connector documentation rather than assume from the name.
- Who uses it: users who work in a single modern interface and may not need Share-specific site features.
- Where edit actions appear: confirm in the connector documentation which views, toolbars or context menus expose the edit action, and whether it works in preview.
- What to confirm: the supported Content App version, the build or extension method, the required WOPI host configuration and whether the client needs its own deployment step.
- What to test separately: authentication flows through the Content App, token expiry during long sessions, and behavior when the user lacks write permission.
- Feature gaps: do not assume the same file types, co-editing behavior or metadata handling as Share until you have tested them.
Do not claim feature parity between the two clients unless the connector documentation confirms it. Use a short written test script for each client so that the results can be compared directly before you decide which one goes live first.
Choosing the first client is a scope decision, not a technical one. The right first step depends on which users must edit documents at launch, which client they already use, and how much change you can absorb in the first phase. Starting with one client narrows the test matrix and makes it easier to find problems in the WOPI path before they affect everyone.
- Start from users: list the groups that need to edit in the first phase and note which client each group uses today.
- Match the client to the pilot: pick the client that covers the pilot group completely, not the one that looks newer.
- Plan the second client: record the test results and open items for the other client so it can follow in a later phase.
- Agree the exit criteria: define in writing which document types, roles and sites must pass before the rollout is called complete.
- Ask the connector vendor: request the supported versions, the list of tested clients and any known limits for each one.
Record your decision and the reason for it in the change record, so that auditors and future operators can see why one client was wired first and what remains untested.
How Alfresco permissions and document data map to editor rights
This table compares how Alfresco identities, permissions, file types, versions and locks are handled on the Alfresco side and on the Collabora Online side. Read each row as a question to answer in your environment before rollout, since the Alfresco connector behavior must be confirmed with Jeci's documentation and tested with your own content.
| Item | Alfresco side | Collabora side | What to confirm |
|---|---|---|---|
| User identity passed to the editor | The Alfresco user session that opens the document from Share or the Content App | Collabora receives a WOPI request identifying the user for the session | Which user identifier the connector sends, and whether it matches your directory account names |
| Read versus edit rights | Alfresco read and write permissions on the node, including inherited permissions | View-only or edit mode chosen by the WOPI host for each session | Which Alfresco permission levels map to view and which to edit in the Jeci connector, with a test user for each level |
| File types the editor handles | Office, OpenDocument and PDF content stored as Alfresco nodes with their MIME types | OpenDocument, docx, xlsx, pptx, PDF, RTF, CSV and Visio files per Collabora's product page | Which extensions the connector offers for editing and which fall back to download or preview |
| Document versions and saves | Alfresco version history and how a save creates a new version or overwrites the current one | Each save returns a document to the WOPI host, which decides how it is stored | Whether each save creates a version, how minor and major versions are set, and how autosave interacts with version history |
| Locking or concurrent edit behavior | Alfresco check-out and lock state on the node, if the connector uses it | Collabora co-authoring when several users open the same document through the WOPI host | Whether Alfresco locks block co-editing, how conflicting saves are reported, and what users see when a lock is held |
| WOPI token lifetime | The token issued by the WOPI host when the editor session starts | Collabora uses the access token for the session and the host governs its expiry | The token lifetime configured in the connector, how long sessions stay open, and what happens to unsaved work when a token expires |
Security settings to lock down for this integration
The Alfresco connector puts an editor between your repository and your users, so the controls that matter sit on three edges: which hosts may talk over WOPI, how traffic is encrypted, and who is allowed to edit. Each card below is a setting or check to verify before production, along with the patch and support decisions that keep those settings valid over time.
Restrict WOPI requests to known addresses
Only your Alfresco servers should be able to call the Collabora Online server over WOPI, and only the Collabora servers should receive WOPI traffic from Alfresco. Confirm that the Collabora host allow list or network policy names the exact Alfresco addresses in use, including any reverse proxy or load balancer in front of Alfresco. Test from a host outside that list to confirm the request is refused. Re-check the list after any change to Alfresco or proxy addresses, since a stale entry either blocks editing or leaves a gap.
Use HTTPS on both ends
The Collabora Online URL and the Alfresco URL should use the same protocol, and HTTPS is the expected choice for both. Nextcloud's administration guidance makes the same point: match the protocol of the host application and the editor server. Check the protocol in the connector settings, in the Collabora discovery URL, and in any redirect rules at the proxy. A mismatch can produce mixed-content failures or editing sessions that quietly fall back to plain HTTP.
Limit edit rights to named groups
Viewing and editing are separate permissions, and the connector should not grant edit rights to everyone who can open a document. Map edit access to named Alfresco groups, and confirm with a test account from each group that view-only users cannot save changes. Review group membership on the same schedule as your other repository access reviews, because the editor inherits whatever the repository allows. Ask the connector maintainer how edit permission is checked on each save request.
Track Collabora security advisories
Collabora publishes security advisories for Collabora Online, and fixes arrive as point releases on each branch. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. Subscribe to the release notes, record which point release runs on each Collabora server, and verify package signatures when you install updates. A patch you cannot confirm is a gap you cannot prove closed.
Choose a supported plan for production
CODE, the free edition, is released as a rolling build and Collabora does not recommend it for production. For a production Alfresco deployment, confirm whether the Business plan or the Enterprise plan fits your user count and includes the long term support, service level agreement and signed security updates you need. Ask the vendor which branch will receive security fixes and for how long. Ask who in your organization or partner network will receive advisories and who approves an update.
Review the connector's code and update path
The Jeci connector is a third-party component between Alfresco and Collabora, so its code, dependencies and release cadence are part of your attack surface. Before production, ask the maintainer how security issues are reported and fixed, which Alfresco and Collabora versions are tested, and how upgrades are delivered. Review the source for how it stores WOPI tokens and checks user permissions. Agree on a process for applying connector updates alongside Collabora patches so the two stay compatible.
What to test before users see the editor
Start with a test repository in Alfresco that holds copies of the file types your users actually store, including Word, Excel and PowerPoint files, OpenDocument files, PDFs and large files at the upper end of your real sizes. Synthetic files are useful for smoke tests, but they rarely expose the layout, embedded object and macro problems that generate support tickets. Run the same set through both the Share integration and the Alfresco Content App. Test a matrix of user roles: a viewer who should open documents read-only, an editor who should save changes, and a user with no access who should be refused before the editor loads. Confirm the role mapping in Alfresco matches what the Collabora server receives, because a mismatch here is where unauthorized edits usually appear.
For every round trip, open a document, change a known piece of text, save, close, and then check three things in Alfresco: the change is visible in the document, a new version was created with the expected version label and author, and the previous version can still be restored. Record fidelity separately. Compare headings, tables, numbering, fonts, images, tracked changes and comments before and after the save, and log the result per file type and per client, Share and Content App separately. Set a written pass threshold for each file type, and do not extend access to a wider group until the results have been reviewed and signed off by the platform owner and the business owner of the content.
Include a concurrency test with two users editing the same document at the same time. Collabora's Kubernetes guidance says all users editing one document must reach the same server instance, which is enforced by load balancers routing on the WOPISrc parameter. If you run more than one Collabora server behind a load balancer, confirm that routing with a real session rather than assuming it, and ask your Alfresco integration owner to confirm which Collabora URL the connector sends to. Check what happens when one editor loses the connection, and confirm the save conflict behavior with your own team. Confirm these details against the connector's documentation for your version before go-live.
Common Alfresco and Collabora failures and how to fix them
This table pairs common symptoms in Alfresco and Collabora editing with their likely causes and the first checks to run. Read each row as a triage path: confirm the reachability and protocol first, then rights, callbacks, connector tier and routing. Exact error text should be matched against the Collabora server logs and the connector documentation.
| Symptom | Likely cause | Fix or check |
|---|---|---|
| Editor does not launch | Collabora URL unreachable from the browser or from Alfresco, or the server certificate does not match the host name Alfresco uses | Confirm the Collabora discovery URL resolves and answers over HTTPS from both the user network and the Alfresco server. Check that the certificate covers the exact host name in the configuration. |
| Editor does not launch | Protocol mismatch between Alfresco and Collabora, such as Alfresco on HTTPS with Collabora addressed over HTTP | Use the same scheme for the Alfresco and Collabora URLs where the connector allows it, and confirm the reverse proxy forwards the original protocol to Collabora. |
| Documents open read-only unexpectedly | Rights mapping between Alfresco permissions and the WOPI user is not granting write access | Test with a user who has Editor or Coordinator rights on the document in Alfresco. Compare the permissions shown in the file's properties with the connector's mapping rules, and confirm which permission the connector requires for write access. |
| Saves fail or do not reach Alfresco | WOPI callback from Collabora to Alfresco is blocked by a firewall, proxy or host allow list | Confirm Collabora can open a connection to the Alfresco host on the callback path. Check the allow list on the Collabora side and the firewall rules between the two servers, then review the Collabora logs for WOPI callback failures. |
| Saves fail or do not reach Alfresco | Alfresco content is locked or versioning rules reject the save | Check whether the document is checked out or locked by another user, and review the versioning settings the connector uses when it writes back. |
| Documents open in the wrong client or the button is missing | Connector configuration applied to the wrong tier, for example to the Alfresco Share web application when the Alfresco Content App is in use, or the reverse | Confirm which front end the users work in and check the connector documentation for the matching configuration. Verify the Collabora action appears for the file types you expect. |
| Documents open in the wrong client or the button is missing | File type is not mapped to the editor in the connector or Collabora does not support it | List the file extensions your users open and compare them with the formats Collabora supports. Test one file of each type after configuration. |
| Slow loads or lost edits when several users edit one document | More than one Collabora server behind a load balancer that does not route by the WOPISrc parameter, so users on the same document land on different pods | Route requests so every user editing one document reaches the same server, keyed to WOPISrc as the Collabora Helm chart guidance describes. Disable autoscaling for the editing tier and set the replica count manually. |
Questions buyers ask before outsourcing the Alfresco integration
Can our own team install and run the Alfresco connector without a partner?
Yes, a team with Alfresco administration experience and Linux skills can do this, provided it has time for testing. Most of the work is configuration: installing the Collabora Online server, pointing the connector at it, and setting up Alfresco so users can open documents from Share or the Alfresco Content App. Two areas need extra attention. First, confirm that the connector version you choose supports your Alfresco version and your Collabora Online branch. Second, TLS setup between Alfresco, the connector and Collabora is where many first installs stall, because certificates, hostnames and the URLs the browser sees must match. Ask whether your team has a test environment that mirrors production before you decide.
What drives the cost and effort of an Alfresco and Collabora integration?
Scope and testing are the main drivers. Scope includes how many Alfresco tiers and client interfaces are in use, such as Share, the Alfresco Content App or both, how many file types must open and save correctly, and how the identity and permission model maps to who can view or edit. Infrastructure drivers include the number of Collabora servers and the level of concurrent editing you expect. Testing volume grows quickly because format fidelity and permission cases multiply. The support level you choose after go-live is a recurring cost. When you request a quote, ask for each item listed separately, the party doing each task, and which costs are one-time and which recur.
Is the Collabora Online subscription price fixed?
The subscription is published for smaller deployments and quoted for larger ones. According to Collabora's pricing page, 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. The subscription is billed per user, so the total changes with your user count. Implementation work is priced separately and follows the written scope. Confirm with Collabora which plan fits your user count, and confirm with the connector's maintainer whether the connector carries any licensing terms of its own.
How long does an Alfresco and Collabora integration take?
The duration depends on scope, so it should be agreed in writing before work starts rather than assumed from a generic figure. The main variables are the number of Alfresco tiers and clients, the file types and permission cases to test, whether Collabora servers already exist or must be built, and how many rounds of acceptance testing you expect. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work begins. Ask for a schedule that ties each milestone to a testable output. Also ask which people on your side must be available for approvals and test sessions, because waiting on approvals is a common cause of delay.
What does our team need to provide before the work starts?
Plan to provide four things. The first is repository access, meaning administrator credentials or a service account for the Alfresco instance and permission to make configuration changes in a non-production tier first. The second is a test environment that matches production in versions, hostnames and network paths between Alfresco, the connector and Collabora. The third is named approvers who can sign off on security settings, permission mapping and acceptance tests, so decisions do not sit in a queue. The fourth is a document sample that includes production business files for each format you intend to support, with any known editing issues noted. Agree these items in the written scope so both sides know what is owed and by when.
Who patches the connector and Collabora Online after go-live?
Three components need ongoing patching: the Alfresco connector, the Collabora Online server and Alfresco itself. Collabora publishes security advisories and release notes for Collabora Online, and its 25.04 release notes, for example, record a security fix and package signing key updates. The Business and Enterprise plans include signed security updates and vendor support through the subscription, while Collabora describes CODE as not recommended for production. Confirm who monitors advisories, who tests each new Collabora branch against the connector, and how a patch moves to production. Ongoing support, upgrades and testing can be covered by a DeployOpen retainer, which is scoped and priced separately from the implementation.
What should we test before opening Collabora editing to all users?
Test permissions, file fidelity, connectivity and co-editing before wider access. For permissions, check that users who should only view cannot edit, and that people outside the intended groups cannot open documents at all. For file fidelity, test the Microsoft formats you use most, such as docx, xlsx and pptx, alongside PDF and any OpenDocument files, and compare layout, formulas and embedded objects with the originals. For connectivity, confirm that the WOPI host allow list and TLS settings match your hostnames, and that users reach the same Collabora server for a given document. For co-editing, have several testers edit one file at once. Record the connector and Collabora versions used in each test so that a later upgrade can be checked against the same cases.
How DeployOpen scopes and delivers the Alfresco integration
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 Collabora Online and Alfresco integration, that means agreeing the connector, the WOPI routing and the access rules in writing before any build starts, then delivering them with evidence your team can operate.
How we scope
- Confirm which Alfresco interface you use, Share or the Alfresco Content App, and the Alfresco version in your environment.
- Map which sites, document libraries and user groups may open documents and which may edit them.
- Agree the Collabora Online deployment model, network paths between Alfresco, Collabora and users, and TLS certificate ownership.
- Record scope, deliverables and timelines in a written fixed-scope agreement before work starts.
How we build
- Install and configure the Jeci connector and the Collabora Online server in your environment, following the connector's own documentation.
- Configure WOPI discovery, host allow lists and proof key settings so only your Alfresco host can reach the editor.
- Test opening, editing and saving for each supported document type your teams use, including Office and OpenDocument files.
- Validate routing for concurrent co-editing, so all users working on one document reach the same Collabora instance.
How we hand over
- Deliver configuration records, network diagrams and a access-rule matrix that show who can view and who can edit.
- Document the test cases, results and known fidelity gaps for your document formats.
- Provide an operations runbook covering updates, certificate renewal, logging and the steps for rolling back the connector.
- Walk your platform, security and support staff through the setup and the handover material.
How we support
- Support is available as a retainer for patching Collabora Online, Alfresco and the connector after the handover.
- Retainers can include periodic re-testing of document fidelity after Collabora or Alfresco upgrades.
- Security testing of the integrated path can be scoped separately if your compliance program requires it.
- Ask any provider to confirm the connector's support status and release cadence before you commit to a rollout.
