How Collabora Online editing connects to Seafile
If you run self-hosted Seafile and want to edit documents in the browser without sending files to a public cloud, the connection is a WOPI-based online office integration in which Seahub, your Collabora Online server and the user's browser each have a distinct job. Seafile documents this integration in its admin manual, and it is the only supported way to add browser editing to Seafile for this purpose. Seahub, the Seafile web interface, handles authentication, file permissions and the decision to open a document. When a user clicks to edit an Office or OpenDocument file, Seahub gives the browser a WOPI session that points at your Collabora server, and the browser then loads the editor directly from that server.
The Collabora server does the document rendering and editing work, and it calls back to Seahub to read and save the file. That means the browser needs network access to the Collabora server, and the Collabora server needs network access to Seahub. Before you plan hosts, confirm the exact addresses and ports each direction needs in your environment. The Seafile manual requires HTTPS on the Seafile server before you integrate Collabora Online, and it sets the office server type in seahub_settings.py, so this is the first configuration check to make. Treat the Docker path as a same-host option: the supported Docker steps in the manual run Collabora as another container on the same machine as Seafile. If you place Collabora on a separate host, the manual refers you to Collabora's own documentation and asks you to confirm that host has enough cores and memory. Plan that host, its network path and its sizing as a separate piece of work.
What a Seafile and Collabora Online setup needs before go-live
Six items decide whether Seafile can hand documents to Collabora Online without errors. Confirm each one in your own environment before you change any Seafile configuration, because several of them block the others.
HTTPS on the Seafile server
The Seafile admin manual requires HTTPS on the Seafile server before you integrate Collabora Online. Treat this as a hard gate, not a later hardening step. Confirm that the Seafile site loads over HTTPS with a certificate your users' browsers trust, and that the same hostname is used everywhere Seafile is referenced. Plain HTTP will not work as a base for the integration.
Seafile version and edition
Record the Seafile server version and edition you run, including whether it is Community or Professional Edition. Confirm the Collabora settings against the manual for that exact release, since option names and steps can change between versions. Professional Edition can run without a license file for up to 3 users, so check your user count against that limit before you plan the rollout.
Collabora Online version and method
Decide whether you run the Collabora Online server from Docker, system packages or Kubernetes, and pin the version you will test. The Seafile Docker steps only cover Collabora as another container on the same host, so a separate Collabora server needs its own install plan. Confirm the current supported branch with Collabora before go-live, and do not rely on the free CODE edition for production without checking its stated suitability.
DNS and certificates for both hostnames
Plan one hostname for Seafile and a separate hostname for the Collabora Online server, each with a valid certificate. The browser must reach the Collabora hostname directly, so the discovery URL it uses has to resolve from client networks. Confirm that certificate chains are complete and that renewal runs for both names. Mismatched or self-signed certificates are a common cause of editor failures that look like application bugs.
Network reachability between the three parties
Three parties must reach each other: the user's browser must reach Seafile and Collabora, and Seafile must reach the Collabora server. Map each path, including firewall rules, reverse proxies and any internal DNS split views. Confirm that the Collabora server can reach Seafile back for file access, since WOPI requires that round trip. Document the ports in use so the security team can review them.
Cores and RAM for the Collabora host
The Seafile manual asks administrators to confirm that a separate Collabora host has sufficient cores and RAM. Size it from your expected number of concurrent editing sessions, not total user count, and test with real documents. The Helm chart README recommends 8 CPU cores and 8000 MiB of memory per pod for production, with requests of 4 cores and 6000 MiB, which gives a reference point but not a sizing answer for your site.
Configure Seafile to point at the Collabora discovery URL
This sequence connects a self-hosted Seafile server to a Collabora Online server over HTTPS so that users can open and edit office files in the browser. Each step ends with a check you can run before moving on.
Confirm HTTPS on the Seafile server
The Seafile admin manual requires HTTPS on the Seafile server before Collabora Online can be integrated. Your team confirms that the Seafile URL resolves with a valid certificate and that the site loads over HTTPS in a browser without warnings. Record the exact scheme and hostname, because the Collabora settings in later steps must use the same protocol. The step is done when a browser loads the Seafile login page over HTTPS with no certificate errors and the hostname matches the one in your Seafile configuration.
Choose the same-host or separate-host Collabora layout
Decide where Collabora Online runs before you install anything. The Seafile manual's Docker steps cover running Collabora as another container on the same host as Seafile. For Collabora on another host, the manual refers you to the Collabora documentation and asks you to confirm that the host has sufficient cores and RAM. Ask your Collabora provider or the Collabora documentation for the sizing guidance that matches your expected number of concurrent editors, and document the decision. The step is done when you have a written layout with the hostname that will serve Collabora and a confirmed resource plan for that host.
Deploy Collabora Online and confirm its discovery endpoint
Install Collabora Online using the Docker steps for the same-host layout, or the Collabora documentation for a separate server. Confirm that the Collabora service is reachable from the Seafile server over the network, and that its certificate is valid for the hostname you chose. Then open the Collabora discovery URL in a browser or with a command-line HTTP client from a machine that can reach it. The step is done when the discovery document loads over HTTPS and the browser shows no certificate warnings. If the discovery URL does not load, fix routing and TLS before changing Seafile.
Set OFFICE_SERVER_TYPE in seahub_settings.py
Open the seahub_settings.py file in your Seafile configuration directory and set OFFICE_SERVER_TYPE to 'CollaboraOffice', as the Seafile admin manual specifies. Add the Collabora discovery URL setting described in the Seafile manual's Collabora Online integration page, using the protocol and hostname you confirmed in the first step. Keep the protocol identical to the Seafile URL. Save the file and check its syntax before restarting. The step is done when the file contains the single office server type setting and the discovery URL, and a syntax check of the Python file passes.
Restart Seafile and Collabora services
Restart the Seafile services so that Seahub reads the new settings, and restart the Collabora container or service if you changed its configuration. Restart in the order your deployment method documents, and wait until the Seafile web interface responds again. Check the service logs for errors about the office server or the discovery URL. The step is done when Seahub loads normally after the restart and the logs show no errors that refer to the office server or to fetching the Collabora discovery document.
Open a test document in each file type
Sign in to Seafile as a test user and upload one sample file for each format you expect users to edit, such as docx, xlsx and pptx, plus an OpenDocument file and a PDF for viewing. Open each file from the Seafile web interface and confirm that it loads in the Collabora editor in edit mode, and that a second test user with edit rights can open the same file. Check that changes save back to the library. The step is done when every test file opens and saves in the browser, and the results are recorded against the formats your users need.
Confirm HTTPS consistency and access boundaries
Review the final configuration to confirm that the Seafile URL and the Collabora URL use the same protocol, as the Nextcloud administration manual recommends for a comparable WOPI setup, and that Collabora is reachable only from the networks you intend. Ask your security team to confirm which source addresses may reach Collabora and whether the WOPI host allow list in your Collabora configuration matches the Seafile server. The step is done when a written checklist records the protocol, hostnames, allowed sources and test results, and the team has signed off on it.
Same host Docker or a separate Collabora server
The Seafile admin manual documents one topology in full: running Collabora as another container on the same host as Seafile. For a separate host, the manual points to Collabora's own documentation and asks administrators to confirm that the host has enough cores and RAM. That split matters for planning, because the same-host path has written steps in the Seafile manual while the dedicated-server path depends on Collabora's guidance and your own configuration decisions.
- Same host: Seafile's Docker steps cover a Collabora container alongside Seafile on one machine.
- Separate host: the Seafile manual defers installation details to Collabora's documentation.
- Sizing: the manual asks you to confirm sufficient cores and RAM in both cases, without giving a figure.
- Prerequisites: HTTPS on the Seafile server applies to both topologies before you set
OFFICE_SERVER_TYPE = 'CollaboraOffice'inseahub_settings.py. - Gap to close: confirm current Collabora resource guidance and the exact discovery URL format with the vendor documentation before you build.
Before you pick a topology, read the current Seafile manual section for Collabora Online and the Collabora documentation it references, and confirm the version pairing you intend to run.
Collabora's editing process is the heavy component, not Seafile's file storage, so the topology decision is largely a capacity decision. On a shared host, Seafile, its database, the web tier and Collabora compete for the same cores and memory. A dedicated host gives the editor its own budget and makes it easier to scale or move later. The Collabora Helm chart documentation gives production resource figures for Kubernetes pods, which are a useful reference point for sizing, though a Docker host has different constraints.
- Shared host: one machine must cover Seafile services and every open editing session, so peak editing load can affect file sync.
- Dedicated host: the editor gets its own cores and memory, and you can size it independently of Seafile.
- Reference figures: the Collabora Helm chart README recommends 8 CPU cores and 8000 MiB of memory per pod for production, with requests of 4 cores and 6000 MiB. Treat these as a Kubernetes reference, not a Docker sizing rule.
- Concurrency: ask Collabora or your implementation partner how many simultaneous editing sessions your users will generate.
- Growth: a dedicated host is simpler to resize than a shared machine that also runs Seafile.
Once you have an expected concurrency figure, ask for a written sizing recommendation for both options so the comparison rests on your numbers rather than assumptions.
The Seafile manual requires HTTPS on the Seafile server before Collabora is integrated. Collabora's own endpoint also needs to be reachable and trusted by the browser and by Seafile. On the same host, one reverse proxy often terminates TLS for both services. With a separate Collabora server, you manage certificates on two endpoints, and the Collabora URL must be reachable from the browser as well as from the Seafile server. The Nextcloud manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. The same principle applies by analogy to Seafile.
- Same host: one proxy and one certificate chain can serve both the Seafile and Collabora endpoints.
- Separate host: issue and renew certificates for the Collabora hostname and confirm that the Seafile server trusts the issuing authority.
- Protocol consistency: serve both the Seafile and Collabora URLs over HTTPS, as the Nextcloud guidance suggests by analogy.
- Internal certificate authorities: confirm that browsers and the Seafile server both trust your internal CA when you use one.
- Renewal: add the Collabora certificate to your renewal process, so an expired certificate does not break editing.
Confirm with Seafile and Collabora documentation how the discovery URL and certificate trust should be configured for your chosen topology before you request certificates.
The network path between Seafile and Collabora is the main difference in firewall design. On the same host, traffic can stay on local interfaces, and you may only need to expose the Collabora endpoint through the proxy. With a separate host, you open a defined path from Seafile to Collabora and from users' browsers to Collabora, and you can restrict the WOPI requests Collabora accepts to known Seafile server addresses. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. Applying that idea to Seafile means defining the allowed host addresses explicitly, though you should confirm the exact configuration keys with Collabora's documentation.
- Same host: keep the Collabora container's management and internal ports off external interfaces.
- Separate host: allow only the required ports from Seafile and from user networks, and deny the rest by default.
- WOPI allow list: restrict requests to the Seafile server addresses, which you should document and review when addresses change.
- Address changes: a load balancer, NAT gateway or container network can change the source address Collabora sees, so test the path after each change.
- Verification: confirm the allow list with a test session from a real user browser after each firewall rule change.
Before go-live, document every allowed flow between Seafile, Collabora and user networks, and have your network team review it against the intended topology.
The right choice depends on your environment, capacity and operating model rather than a single rule. The same-host Docker path has the most direct documentation in the Seafile manual and the fewest network hops. A dedicated Collabora host adds network dependencies but separates failure domains and capacity. Your team's comfort with Docker, your change process and your audit scope all influence the choice. Start with a short written comparison and test both shapes against your expected user load before committing.
- Single small team: a same-host setup keeps the topology simple, if the host has enough capacity for peak editing.
- Growing or shared use: a dedicated host isolates editing load and gives you room to resize.
- Operational ownership: decide who patches Collabora, who watches its logs and who owns the firewall rules for each option.
- Migration path: a separate host is easier to move later if you plan to scale, though it adds a network dependency to plan for.
- Test before commit: run a pilot with real documents and representative concurrency on the topology you are considering.
Ask your implementation partner to document the chosen topology, its resource reservations, its allowed network flows and the certificate renewal owner, so the decision can be audited later.
How to size the Collabora host for Seafile users
The Seafile manual asks administrators to make sure a separate Collabora host has sufficient cores and RAM, but it does not publish figures. Sizing therefore has to come from your own usage: the number of concurrent editing sessions, the size and complexity of the documents people open (large spreadsheets and image-heavy presentations cost more memory than short letters), and how many people co-edit the same file at once. Start by estimating your peak simultaneous sessions during business hours, then confirm the figures with Collabora or your implementation partner before buying hardware. Ask for the sizing basis in writing, not a single core count.
The Collabora Helm chart is the only source in this topic that publishes concrete resource numbers. Its README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as a reference for that chart's deployment model, not as a sizing rule for a Docker container or package install on a Seafile host. The same README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set by hand. If you run more than one replica, your load balancer must route by the WOPISrc parameter so every user editing a document reaches the same pod.
Before go-live, load test with documents and users that resemble yours. Simulate your peak session count, include a set of large files and several users co-editing one document, and watch CPU, memory and response times on the Collabora host while Seafile is also serving sync traffic. Repeat the test after any change to the document mix or user count. Confirm with your Collabora deployment method which limits and restart behavior apply to your container or service. The results, not the reference figures, should decide whether one host is enough or whether you need a separate server with routing in front of it.
How Seafile libraries, users and permissions map to editing rights
This table compares how Seafile library permissions, user identity sources and file types affect whether a person can open, view or edit a document in Collabora Online. Read each row as a question to answer in your own Seafile version and test with a pilot account before rollout. The main takeaway is that read-only sharing, identity source and encryption each change editing rights, and none of them should be assumed without a test.
| Factor | What it controls | What to verify in your environment |
|---|---|---|
| Read-only library share | Whether a user who can see a file is limited to viewing it in the editor | Open a document as a read-only sharee and confirm the editor blocks changes; confirm the behavior in your Seafile version |
| Read-write library share | Whether a user can open the file in the editor and save changes back to the library | Test with a read-write user from a second account; confirm saved edits appear in the library and version history |
| LDAP or Active Directory user | Which directory account maps to the Seafile user who opens the editor | Confirm the same username resolves to one Seafile account after sync, and that disabled directory accounts lose editing access |
| SSO-authenticated user | Whether the identity seen by Seahub matches the user that Collabora receives for the session | Sign in through SSO, open a document, and check the user name shown in the editor against the Seafile account |
| Docx, xlsx and pptx | Microsoft formats that Collabora Online supports for editing | Open representative files from your own libraries and check layout, tables and charts after a save |
| ODF, PDF, RTF, CSV and Visio | OpenDocument and other formats Collabora Online lists as supported; PDF and Visio may open for viewing only | Test each format your users rely on; confirm which types open for editing rather than viewing in your build |
| Encrypted libraries | Libraries protected by a user-chosen password may not be openable in the editor | Open a test file from an encrypted library before promising editor access; confirm current behavior in your Seafile version |
Securing the Seafile to Collabora connection
The connection between Seafile and Collabora Online carries document content and sign-in context between two servers, so its controls matter as much as the editor itself. The cards below cover transport, network restriction, patch currency, key management and user access, in the order most teams should review them.
Match HTTPS on both sides
Seafile requires HTTPS on its own server before Collabora Online is integrated, and the Collabora server URL should use the same protocol as the Seafile installation, preferably HTTPS. Check that the discovery URL configured in seahub_settings.py, the Collabora hostname and the certificates on both servers agree. A mismatch is a common cause of editing failures and an avoidable source of mixed-content exposure. Confirm certificate renewal for both hostnames before go-live.
Restrict WOPI traffic by address
The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. Apply the same principle to a Seafile deployment: allow only the Collabora server addresses to reach the WOPI endpoints that Seafile exposes, and confirm the list covers every egress path, including any load balancer or NAT in front of Collabora. Review the list whenever the Collabora host moves or scales out, because an outdated allow list either blocks editing or leaves gaps.
Track Collabora security advisories
Collabora publishes security advisories for Collabora Online. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Subscribe to the release notes, map each advisory to the branch you run, and schedule patch windows so the Collabora server stays on a supported point release. Ask your Seafile contact which Collabora versions they have tested with your Seafile release before you move.
Rotate signing keys on package installs
Collabora updated package signing keys for RPM and DEB users in the 25.04 release cycle. If your Collabora server came from system packages, update the repository signing key on every host and confirm that package verification passes before applying updates. Stale keys can block upgrades or, worse, lead administrators to disable signature checks. Record key fingerprints in your change process so each rotation is reviewed rather than accepted automatically.
Limit who can open and edit
Access to documents is decided by Seafile, and the editor only receives what Seafile allows. Review library sharing and permissions so that only intended users reach documents, and confirm that read-only sharing does not grant edit rights through the editor. Test with a read-only account and an editing account from each group. If your Seafile edition supports role-based permissions, use those roles to define who may edit, and confirm the exact behavior with your Seafile vendor.
Keep the Collabora server dedicated
Running Collabora as another container on the Seafile host, as the Docker steps in the Seafile manual describe, places document processing next to the file store and the web interface. A separate Collabora server, sized for the editing workload, lets you apply network rules and patch cycles to it independently. Decide which model fits your risk profile before you configure the discovery URL, because changing the host later means reissuing certificates and updating the allow list.
Why editing fails after the Seafile to Collabora setup
This table lists the failures teams most often see once Seafile is pointed at Collabora Online, with the likely cause and the first check for each. Work down the rows in order, since the HTTPS and discovery URL checks clear many symptoms before any server tuning is needed. For deeper diagnosis, use the Collabora operations and troubleshooting topic.
| Symptom | Likely cause | First check |
|---|---|---|
| Documents open read-only or not at all | Seahub is not passing the editor configuration correctly, or the Collabora server does not accept the Seafile host as a WOPI host | Confirm OFFICE_SERVER_TYPE = 'CollaboraOffice' is set in seahub_settings.py and that Seahub was restarted after the change |
| Editor frame blocked or mixed content warnings | Seafile is served over HTTPS but the Collabora URL is HTTP, or the reverse, so the browser blocks the embedded frame | Compare the scheme of the Seafile site URL and the Collabora discovery URL and make both HTTPS |
| Editor fails to load in the browser | The discovery URL is reachable from the Seafile server but not from user browsers, often because of an internal hostname or DNS split | Open the discovery URL from a client workstation outside the server network and confirm it returns the discovery document |
| WOPI requests rejected by Collabora | The WOPI allow list on the Collabora server does not include the Seafile host address, or a reverse proxy changes the host header | Check the Collabora server's WOPI host configuration and the source address Seafile uses to reach it, including any proxy in between |
| Browser reports certificate trust errors | The Collabora host uses a certificate issued by an internal CA that the user devices or the Seafile server do not trust | Test the certificate chain with a standard TLS client from the Seafile server and from a user device, then import the CA where needed |
| Sessions load slowly or drop during editing | The Collabora host lacks cores or memory for the number of concurrent sessions, or several Collabora processes compete with Seafile on one host | Check CPU and memory use on the Collabora host during an active session and compare it with the sizing guidance in the Seafile manual |
| Editing works for one user but not for others on the same document | Requests for one document are split across more than one Collabora instance behind a load balancer | Confirm the load balancer routes by the WOPISrc parameter, or run a single Collabora server until routing is in place |
| Office files show formatting or open errors | The file type is not supported by the configured editor, or the Collabora server cannot read the document from Seafile | Open the same file in a second format test and review the Collabora server log for the file request and error code |
Questions buyers ask before connecting Seafile to Collabora Online
What does it cost to connect Seafile to Collabora Online?
The cost has three parts: the servers that run Collabora, the Collabora support tier you choose, and the integration work. Infrastructure is the part you pay your cloud or data center for, and it recurs every month. The Seafile manual asks you to confirm that the host running Collabora has enough cores and RAM, so the size of your user base and concurrent editing sessions drives the server bill. Collabora's published pricing lists a Business plan at 3 euros per user per month for up to 99 users, with long term support, an SLA, signed security updates and customer portal access. Enterprise pricing for 100 or more users is quoted with volume discounts and adds integration support and customization services. Integration effort is usually a one-time fixed scope. Ask any partner for a written quote that separates these three lines and states which items recur.
How long does a Seafile and Collabora Online integration take?
Duration depends mainly on how much of the environment already exists and how many servers are involved. A single Seafile server with Collabora on the same host, using Docker, is the shortest path because the Seafile manual covers that setup directly. A separate Collabora server adds DNS records, certificates, firewall rules and sizing work. Other drivers include whether HTTPS is already working on the Seafile server, which the manual requires before integration, how many document types your users need to test, and how long your change process takes for production. Ask your team or a partner to list each task and its dependencies, and confirm the timeline against your own change calendar rather than a generic estimate.
What must our team provide before the integration starts?
Plan to supply several items before any configuration begins:
- A valid HTTPS certificate for the Seafile server, since the Seafile manual requires HTTPS before Collabora Online is integrated.
- A certificate and DNS name for the Collabora server, including records that resolve from users' browsers and from Seafile.
- Network access between Seafile and Collabora, and from user browsers to Collabora, through your firewalls and reverse proxies.
- Test documents in the formats your staff use, such as docx, xlsx and pptx, so fidelity can be checked.
- Named user groups that define who may open and who may edit documents.
- An owner who can approve the server sizing and the change window.
Confirm each item with your network, identity and security teams early, because certificate and firewall approvals often take the longest.
Can our internal team set up Seafile with Collabora Online alone?
Yes, a team with Linux, Docker and reverse proxy experience can follow the Seafile admin manual and the Collabora documentation for a single-host setup. The manual sets OFFICE_SERVER_TYPE to 'CollaboraOffice' in seahub_settings.py and covers running Collabora as another container on the same host. The harder parts are a separate Collabora server, TLS and proxy configuration, sizing for real concurrency, and testing that edits save correctly for every user group. Whether your team should do it alone depends on its skills, how much time it can give the work, and whether you need a repeatable runbook for later upgrades. Before deciding, have an engineer test the setup in a non-production environment and record each step.
Do we need a paid Collabora plan for production, or is CODE enough?
For production, plan on a supported Collabora subscription, not CODE. Collabora describes CODE (Collabora Online Development Edition) as a free, rolling release released on average once a month, suited to testing, home use or small teams, and not recommended for production. The Business plan includes long term support, an SLA, signed security updates and customer portal access, which matter when you need predictable patching. Collabora's security advisories, such as the fix for CVE-2026-23623 in the 25.04 branch, are a good example of why patch timing matters. Compare the plan terms against your own patch policy and availability requirements, and confirm with Collabora which tier matches your user count.
Which Seafile edition do we need before adding Collabora Online?
Collabora Online works with the Seafile features the admin manual documents for office integration, so the edition decision is mostly about what else you need. The Seafile download page says Professional Edition can run without a license file for up to 3 users. Professional features listed in the manual include SAML 2.0, cluster deployment, multi-tenancy, role-based permissions, ClamAV virus scanning and advanced file search. Confirm with Seafile which edition and license terms fit your user count before the integration, because changing editions later may need a new deployment plan.
What breaks most often when Seafile cannot open documents in Collabora?
The most common cause is a mismatch between HTTPS on Seafile and the Collabora address, because the manual requires HTTPS on the Seafile server. Other frequent causes are a DNS name that users' browsers cannot resolve, a firewall that blocks traffic between Seafile and Collabora, a certificate that does not match the hostname, and a seahub_settings.py entry that points to the wrong discovery URL. Insufficient cores or RAM on the Collabora host can cause slow or failed sessions. Keep test documents and a short checklist for each of these so your team can isolate the fault quickly.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Seafile and Collabora Online connection. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm the Seafile version, edition and deployment method, whether Docker single-node or binary installation.
- Decide whether Collabora Online runs on the same host or on a separate server with its own cores and memory.
- Record the public HTTPS hostnames for Seafile and Collabora, and the networks that must reach each service.
- Agree in writing the sizing inputs, expected concurrent editors and document types that the quote will cover.
How we build
- Enable HTTPS on the Seafile server first, since the Seafile manual requires it before Collabora Online is integrated.
- Set OFFICE_SERVER_TYPE to CollaboraOffice in seahub_settings.py and point the Collabora discovery URL at your server.
- Test in-browser opening, editing and saving with libraries that hold docx, xlsx, pptx, ODF and PDF files.
- Restrict which Collabora server addresses can reach Seafile where your network design allows it, and document the rules.
How we hand over
- Deliver a written configuration record covering hostnames, certificates, ports, settings files and container or package versions.
- Document the upgrade sequence for Seafile and Collabora Online, including how to test a new Collabora release before rollout.
- Walk your administrators through troubleshooting for connection errors and protocol mismatches, using your own environment.
- Provide test results and a list of open items, so your team knows what remains its responsibility after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainers can cover monitoring checks, security advisory review and patch testing for both Seafile and Collabora Online.
- Ask any partner, including DeployOpen, to state in the quote which systems, versions and response scope the retainer includes.
