Why teams move Collabora Online from collabora/code to a production container
Move from the free collabora/code image to a supported production container when real users need browser editing on infrastructure you control, and do it before the test environment becomes the production environment by accident. The CODE image is a reasonable way to prove that Collabora Online can talk to your WOPI host, but Collabora describes CODE as suited to testing, home use or small teams and not recommended for production. CODE is also a rolling release, published on average once a month, so the build you tested last month may not be the build you run next quarter. A production deployment needs a versioned image from a subscription source, an explicit configuration and a repeatable way to upgrade.
The gap between a working test and a production service is mostly configuration. A test container often runs with permissive settings that nobody revisited: the WOPI host allow list may be broad, TLS may be terminated somewhere undocumented, and the container may have been started with capabilities copied from a forum post. In production, you need to decide which WOPI hosts are allowed, how the Collabora server URL uses HTTPS, and which container capabilities are truly required. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using the same protocol, preferably HTTPS, for the Collabora server URL as for the Nextcloud installation. Write those decisions down before the first user logs in.
Before cutover, ask your vendor or partner which subscription image and tag you will run, what support and security update commitments come with it, and how signed security updates reach your team. The Business plan, listed at 3 euros per user per month for up to 99 users on Collabora's pricing page, includes long term support, a service level agreement, signed security updates and customer portal access. Confirm current terms directly with Collabora, because pricing and plan contents can change. Plan for a recurring subscription cost, a one-time configuration and testing effort, and a recurring upgrade effort that depends on how often you pin new image tags.
Choosing between the CODE image and a subscription image
The free collabora/code image is aimed at people who want to try Collabora Online before committing. Collabora describes CODE as its free edition, suited to testing, home use or small teams, and not recommended for production. It is released as a rolling image on average once a month, which makes it a good way to exercise a Nextcloud or other WOPI host integration in a lab, but it is a moving target rather than a fixed release you can plan around.
- Fast trial: Run the image on a single host to confirm that your WOPI host can reach the server and open documents.
- Rolling releases: Expect changes roughly monthly, so pin a tag during testing and record what you tested.
- No production commitment: Collabora does not position CODE as production software, so do not treat it as the basis for a business rollout.
- Architecture support: The image is published for x86-64, ppc64 and arm64, which helps with lab hardware choices.
- Feature checks: Use the lab to test document fidelity, fonts and proxy settings before you decide.
Before relying on a test result, check the CODE page for the current terms of use and confirm with Collabora which image you should run for your use case.
Small teams often start on CODE because the cost is zero and the setup is short. The trade-off is that the free edition does not come with the commercial terms that a business usually needs, such as a service level agreement or long term support. A small team with few users and a tolerance for downtime may accept that gap, but the decision should be written down with the people who will answer for an outage or a security problem.
- Cost of entry: CODE has no licence fee, while a subscription adds a recurring per-user cost.
- Support expectations: Decide who responds when documents stop opening, and whether that is an internal person or a vendor.
- Security updates: Confirm how quickly you will apply point releases and advisories when running a rolling image.
- User count: Collabora's pricing page sets the Business plan for up to 99 users, so count the people who will edit documents, not the total mailbox population.
- Growth path: Plan the move to a subscription image before user numbers or data sensitivity increase.
Ask Collabora whether your planned user count and use case match the free edition's intended audience before you go live.
For business production, the Business plan is the subscription tier Collabora's pricing page describes for organizations of up to 99 users. According to that page, it costs 3 euros per user per month and includes long term support, a service level agreement, signed security updates and customer portal access. Those items are what separate a production commitment from an open test. Whether the plan gives you access to a specific subscription image, its tag naming and registry credentials must be confirmed with Collabora.
- Recurring cost: The per-user fee recurs monthly, so model it against your active editor count.
- Long term support: Check which branches are covered and how long each one is supported.
- Signed security updates: Confirm how advisories reach you and how you verify signatures on what you pull.
- Portal access: Confirm who in your team receives portal credentials and who can open tickets.
- Image access: Ask Collabora which image tag and registry access your plan provides before you write the deployment runbook.
Request a written quote and a sample of the image and tag scheme from Collabora before you design your upgrade process around it.
The Enterprise plan applies to organizations with 100 or more users. Collabora's pricing page says it is quoted with volume discounts and adds integration support, customization services and roadmap input. For a large or regulated environment, the value often sits in those extras, because they change who you can call when a WOPI integration, a custom feature or a platform upgrade goes wrong. The plan is priced per quote, so the scope you write down drives the number.
- Quoted pricing: Ask for the volume discount structure in writing and how it changes as your user count grows.
- Integration support: Confirm which WOPI hosts and versions are covered.
- Customization services: Separate work Collabora would do from work your partner or team would do.
- Roadmap input: Clarify how feature requests from your organization are considered and tracked.
- Image and registry terms: Confirm the subscription image, tag scheme and registry access in the contract, not only on a call.
Before you sign, compare the quote against the internal effort of running CODE with your own patch process and ask Collabora to confirm the image, tag and registry details in writing.
Container settings that decide how Collabora Online runs in production
This table compares the container settings that most affect a production Collabora Online deployment, including WOPI host allow lists, the public server URL, TLS handling, the proxy in front of the container, resource limits and image tag pinning. Read each row as a decision: what it changes, when it fits and what to confirm against the image documentation before you set it. The main takeaway is that the public URL, allow list and proxy must agree, because a mismatch on any one of them breaks editing for every user.
| Setting | What it changes | When it fits and what to confirm |
|---|---|---|
| Allowed WOPI hosts | Limits which Nextcloud or other WOPI host servers can open documents in the editor | Set to the exact host names your WOPI hosts use. Confirm the exact variable or config key in the image documentation before setting it. |
| Public server URL | Sets the address the browser and WOPI host use to reach the container | Must match the external name users see, including protocol. Confirm the key name in the image documentation, and the value must not point to an internal address. |
| TLS handling in the container | Decides whether the container terminates TLS itself or trusts a proxy in front of it | Terminating at a proxy is common when the proxy already manages certificates. Confirm the TLS settings and certificate paths for your image version. |
| Reverse proxy or host in front | Forwards WebSocket traffic, sets headers and applies timeouts for long editing sessions | Required for most production layouts. Confirm the forwarded paths and WebSocket routes against the reverse proxy guidance you follow. |
| Container capabilities | Grants the kernel features the server needs to isolate and run its processes | Grant only the capabilities the image documentation names. Adding broad privileges widens the attack surface and should be justified in your review. |
| CPU and memory limits | Caps how much compute each container can use during concurrent editing | Size against your concurrency, not user totals. The Helm chart README recommends production values of 8 CPU cores and 8000 MiB per pod as a reference point to check against. |
| Image tag pinning | Fixes the exact build that runs until you change the tag | Pin to a specific release tag, not a floating tag, and record it in change control. Upgrades then happen by tag, with a tested rollback to the previous tag. |
Setting up the production container step by step
This sequence takes a Collabora Online container from a pinned image to a verified editing session in your WOPI host. Each step closes with a check, so you know the container is ready before you move to the next one. Run the steps in a test environment first, then repeat them in production.
Pin the image tag
Choose the image tag you intend to run and write it into your compose file or deployment manifest. Use an exact version tag rather than a floating tag, so a restart never pulls a different release without a change record. Confirm with Collabora which image is the supported subscription build for your plan, and check that the tag matches the branch you tested. Done when
docker image inspecton the host reports the expected tag and digest, and the manifest contains no floating tag.Set the allowed WOPI host and public URL
Declare the hostname of each WOPI host that may open documents, and the public address users reach the container on. Keep the list short and limited to the Nextcloud or other host instances you operate. Confirm the exact setting names against the current image documentation for your tag, since they change between releases. Done when a request from an unlisted host is refused in the container logs and a request from the listed host is accepted.
Configure TLS handling
Decide where TLS terminates. If the reverse proxy handles certificates, run the container in plain HTTP on a private network and tell it that the public URL uses HTTPS. If the container terminates TLS itself, supply the certificate and key through mounted files. The Nextcloud administration manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Done when the public URL loads over HTTPS with a valid chain and the browser reports no mixed-content warnings.
Add only the capabilities the container needs
Start with no extra privileges and add a capability only when a specific feature fails without it. Record each addition and the reason in your change log, so a later reviewer can see why it exists. Avoid privileged mode unless the image documentation for your tag requires it for a feature you use. Confirm the list with Collabora for your version. Done when the container starts, serves the discovery endpoint, and runs with the minimal set you recorded.
Place the container behind the reverse proxy
Route public traffic through your reverse proxy to the container's internal port. Forward the WebSocket paths that the editor depends on and set proxy timeouts long enough for extended editing sessions. Restrict the container's port so only the proxy and the WOPI host network can reach it. Done when the discovery page loads through the proxy address, the editor WebSocket connects without errors, and the container port is unreachable from outside the private network.
Connect the WOPI host
In the WOPI host, enter the public URL of the Collabora container and set the protocol to match the host's own. In Nextcloud, this is done in the Nextcloud Office settings, where you can also limit which groups may use the editor and which may edit. Restrict WOPI requests to the container's outbound addresses where your network allows it. Done when the host's office settings show the server as reachable and the administration page reports no connection errors.
Confirm a document opens and saves
Open a test document of each type you support, including a docx, an xlsx and a pptx file, from the WOPI host. Edit it, save it, reload it, and check that the changes persist in the host's storage. Repeat the test with a second user to confirm that co-editing works through the proxy. Done when every test file opens, saves and reloads with the edits intact, and the container logs show no errors for those sessions.
Which container capabilities and resources the server needs
Start from the smallest set of Linux capabilities the container needs, not from privileged mode. Running with --privileged hands the container almost every host capability, which widens the blast radius of any flaw in the document conversion pipeline that Collabora Online runs for each editing session. Grant only the capabilities named in Collabora's current Docker documentation for the image tag you deploy, add them one at a time with --cap-add, and confirm that each one is still required after you upgrade. The capability list can change between releases, so treat the documentation for your tag as the source of truth and record the exact list in your deployment repository so a reviewer can compare it with the vendor guidance.
Resource sizing is the second decision, and it needs its own evidence. The Collabora Online Helm chart README gives production reference values of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. These are Kubernetes chart values, not a general rule for a Docker host, and they assume a particular workload. Use them as a starting reference only. Run a load test that reflects your real number of concurrent editing sessions, document sizes and document types, then set container limits and reservations from the observed peak with headroom. Ask Collabora or your implementation partner how the reference values were derived, and confirm which settings apply to the bare Docker host you are planning.
Security controls for a containerized Collabora Online server
A containerized Collabora Online server accepts requests from your document host and returns document content, so its perimeter is set by a few deliberate choices. The cards below cover who may call the server, how traffic is encrypted, what the container is allowed to do, and how updates reach it. Detailed control settings are covered in the hardening guide.
Restrict WOPI hosts by address
Limit WOPI requests to the addresses of your Nextcloud or other WOPI host servers, as the Nextcloud administration manual recommends. Decide this list before go-live and record who owns it. Check the allow list again whenever a host is moved, scaled out or placed behind a new NAT gateway, because a stale entry will either block editing or leave an unintended caller allowed.
Use HTTPS for the server URL
Use the same protocol for the Collabora server URL as for the Nextcloud installation, and prefer HTTPS, as the Nextcloud manual advises. Decide where TLS terminates, whether at the container or at a reverse proxy in front of it, and make sure the certificate chain is trusted by the host. Confirm that no mixed-protocol path remains between the browser, the host and the server during testing.
Avoid privileged containers
Run the container without privileged mode and grant only the capabilities that the image documents as necessary for your setup. Review any host-level settings you add to make the container start, since broad permissions often appear during troubleshooting and stay in place. Ask your deployment team to document each capability and the reason it is needed, so the exception can be removed later.
Patch the image and the host
Treat the Collabora image and the Docker host as one patch scope. Pin each deployment to a tag, pull the matching fixed image when Collabora ships a security release, and rebuild the container after host kernel and Docker updates. Record which tag runs in each environment so that an advisory can be matched to a running instance quickly.
Watch Collabora security advisories
Subscribe to Collabora release notes and advisories and map each one to the branch you run. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated package signing keys for RPM and DEB users. Confirm which fix applies to your tag, and check whether your image pull process would still deliver the correction before the next maintenance window.
Upgrading by image tag without breaking open documents
This sequence moves a production Collabora Online container to a new image tag only after the release notes, configuration and real documents have been checked on a staging copy. The result is a pinned, documented version change with a verified editing and saving path.
Pin the current tag and record the baseline
Before changing anything, record the exact image tag and digest the production container runs, along with the container command, environment variables and any mounted configuration files. Store these in version control or your change record so the running state can be restored. Confirm that the current tag is a specific point release rather than a floating tag such as latest, because a floating tag changes what runs on the next pull without a deliberate decision. Done when you can reproduce the running container from the saved definition alone.
Read the release notes for the target branch
Read the Collabora Online release notes for the target branch and the point releases between your current version and the target. Note changed environment settings, removed options, security fixes and any statements about compatibility with your Nextcloud or other WOPI host version. The 25.04 branch was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026, so a branch you already run may need only a point-release change rather than a branch move. Done when you have a written list of changes that affect your configuration and your host integration.
Back up configuration and host settings
Back up the container definition, environment file, any custom configuration and the WOPI host settings on the platform that calls Collabora Online, such as the allowed WOPI host list and the Collabora server URL. Store the backup somewhere separate from the host running the container. If your host platform also changes during the window, back up its data as well, since a mismatch between the two can look like a Collabora fault. Done when a restore has been rehearsed or the backup has been verified to open and contain the expected values.
Test the new tag on a staging container
Start the target tag on a staging container built from the same definition, pointed at a staging WOPI host that matches production as closely as possible. Use a copy of real documents that represent your users, including the Microsoft formats, spreadsheets with formulas and presentations with embedded media that your teams rely on. Check fonts, layout and any custom templates against the production rendering. Done when every test document opens, edits and saves, and any rendering differences are either accepted in writing or fixed.
Change the pinned tag in the deployment definition
In the deployment definition used for production, change the image reference to the tested tag. Keep the change to the tag and any environment settings the release notes require, so that the diff is small and easy to review. Commit the change with a reference to the release notes and the staging test record. Done when the reviewed definition names the new tag explicitly and the previous definition is still retrievable from version control.
Restart production and confirm the container is healthy
Pull the pinned tag, restart the production container during an agreed window and check the container logs for startup errors, including messages about WOPI host allow lists and TLS. Confirm that the service answers its discovery endpoint from the WOPI host network path and that the container runs with the capabilities it needed before. Done when the container reports healthy, the logs show no new startup warnings you have not already reviewed, and the discovery check returns the expected response.
Verify editing and saving end to end
From a test account on the production WOPI host, open a representative set of documents, make edits in Writer, Calc and Impress, save, close and reopen each one, and confirm that the changes persist. Check collaborative editing with two sessions on the same document, since that depends on routing to the same instance. Record the outcome in the change record. Done when every test edit saves and reopens correctly and no user-facing errors appear in the host or container logs.
Track advisories and plan the next pin
Subscribe to Collabora's release and security notices and record the date the upgrade was completed. Set a recurring review that compares your pinned point release with the latest one on your branch, because security fixes such as the 25.04.7.5 release that fixed CVE-2026-23623 arrive as point releases. Ask your support provider or internal team to confirm whether signed security updates and advisories are covered by your current plan. Done when a named owner and a review date are recorded for the next tag decision.
Limits to confirm before you commit to Docker
A Docker deployment of Collabora Online is only as sound as the assumptions behind it. The items below are the points to verify in your own environment before you choose a container layout, a routing design and an image source. Each one can change the architecture, so settle them before the build starts.
Single container or several
Confirm whether your target number of concurrent editors fits one container or needs several. The Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, so use those figures as a starting point to test against your own workload. Ask the vendor or a sizing partner to validate the numbers for your document mix before you commit to a replica count.
WOPISrc-aware routing beyond one server
If you run more than one container, confirm that your load balancer routes by the WOPISrc parameter so every user editing a document reaches the same instance. The Helm chart README states that horizontal autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set manually. Check how your proxy or ingress handles this before you rely on Docker Compose or a generic round-robin setup.
Font and fidelity testing
Confirm that the fonts your users expect are present in the container and that documents render the same after each image update. Test a representative set of Writer, Calc and Impress files, including Microsoft Office formats and PDFs, against the originals before go-live. Plan to repeat this testing whenever you change the image tag, because a rendering difference is easy to miss in a container that rebuilds cleanly.
Architecture support on the CODE image
The free collabora/code image is published for x86-64, ppc64 and arm64, so confirm that the tag you plan to run exists for your host architecture before you pull it. Do not assume that a multi-architecture manifest covers every tag or every build in your registry. If you mirror images into a private registry for restricted networks, verify the architecture of each mirrored tag as well.
Subscription image coverage
Ask Collabora which architectures and image variants your Business or Enterprise subscription covers before you plan a production container. Business plans are priced per user per month for up to 99 users and include signed security updates and customer portal access, but the exact image delivery method for your subscription should be confirmed in writing. Do not assume the free CODE image and the subscription image share the same architecture list or support terms.
Capabilities the container needs
Confirm the Linux capabilities, security profile and filesystem access your container runtime grants before you deploy, and check them against the container platform's policy. Many hardened hosts restrict the defaults that a container image expects, so an otherwise working deployment can fail on first document load. Record each capability you grant and the reason for it, so an auditor or security reviewer can trace it later.
Questions teams ask before running Collabora Online in Docker
What does moving Collabora Online to a production Docker setup cost?
The cost is mostly the people time to plan, build, test and hand over the setup, plus the infrastructure you run it on and any subscription you choose. The image itself is only part of the picture. Cost rises with the number of WOPI hosts, the number of environments (test, staging, production), how many TLS and proxy paths need work, and how much document fidelity testing is required. Subscription cost is separate and recurring: the Business plan is listed at 3 euros per user per month for up to 99 users, according to the Collabora Online pricing page, and the Enterprise plan for 100 or more users is quoted. Ask any partner for a written, fixed-scope quote that lists deliverables, environments and what is excluded, and confirm which subscription terms apply to your user count.
How long does a Docker production move take?
Duration depends on scope, not on the image pull. A single-server setup with one WOPI host and a known certificate process can be short. Timelines grow with the number of hosts, the need for WOPI allow list design, reverse proxy and load balancer routing, font and document fidelity testing, and integration with your change process. Any timeline should come from a written scope that names the environments and acceptance tests. Ask for the critical path and which tasks depend on your teams, such as DNS changes or certificate issuance, since those often set the pace.
What must our team provide before the work starts?
Plan to supply the following before the build begins:
- A Linux or container host with the CPU and memory your sizing plan requires, reachable from your WOPI host
- DNS records for the Collabora Online hostname, and a decision on the subdomain layout
- TLS certificates or an issuance process, plus the trust chain your WOPI host needs
- A representative test document set covering the Word, Excel and PowerPoint files your users actually open
- Named owners for the WOPI host configuration, the proxy and the change window
Confirm each item with your own environment before scheduling, because access rules, certificate authorities and network paths differ by organization.
Can our platform team run this migration alone?
A platform team with container, reverse proxy and TLS experience can usually run the technical steps itself, provided it has time and a test environment. The harder parts are often outside pure container work: confirming which WOPI hosts are allowed, checking document rendering against real files, and agreeing on upgrade windows with application owners. Decide early which parts you own and which you want a partner to design or review. If you bring in outside help, ask for a fixed-scope written agreement that states who approves configuration changes and who signs off on acceptance testing.
What recurs after go-live, such as upgrades and security advisories?
Recurring work includes tracking Collabora Online releases, testing new image tags in a non-production environment, applying security updates and refreshing signing keys where your process requires it. Collabora publishes security advisories for Collabora Online. For example, the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Each upgrade should include a rollback path, a check of WOPI connectivity and a sample document test. Subscription terms affect what you receive, including signed security updates and long term support for the Business plan, so confirm the exact support window for your branch before you plan the calendar.
Is the free CODE image enough for production?
Collabora describes CODE, the free Collabora Online Development Edition, as suited to testing, home use or small teams and not recommended for production, according to the CODE page. It is released as a rolling release on average once a month. A production container uses the subscription image and a pinned version tag, so you can plan upgrades and receive the support terms in your plan. Before you switch, confirm the exact image name and tag with Collabora's documentation and your subscription provider, since image naming for subscription customers should come from your vendor account.
Does the container need extra Linux capabilities, and what should we check?
Confirm the capabilities and security options the container requires with the vendor's current documentation for your image version, and grant only what is needed. Review the WOPI allow list, the TLS settings and the proxy routes together, since a permissive host list or a misconfigured certificate chain is a common source of errors. Test with real documents and with the browser paths your users take. Record the exact run options in version control so that a later upgrade can be compared against a known-good baseline.
How DeployOpen scopes and delivers a production container move
DeployOpen starts a container move with a written, fixed scope agreed before any work begins. The scope names the images and tags in use, the WOPI hosts that will call the server, the TLS and reverse proxy design, the upgrade cadence and the evidence the client expects at the end. Most engagements are fixed-scope, so deliverables and timelines are settled in writing up front and a quote follows from that scope rather than from a published price list. Before the scope is signed, the reader should be able to list which environments exist (test, staging, production), who owns each DNS name and certificate, and whether the Docker host is managed by a platform team with its own change process.
The environment review comes next and happens inside your infrastructure, against your container runtime, host kernel and capabilities, network paths and secrets tooling. The review checks the points this topic depends on: whether the runtime allows the capabilities the container needs, how aliasgroup1 and the extra_params allow list will be set for your Nextcloud or other WOPI hosts, where TLS terminates, and how image tags will be pinned and mirrored. DeployOpen configures the container, its environment and the surrounding proxy in your own cloud accounts, data centers or restricted networks. Your team keeps administrative control, and the configuration is delivered as files and runbooks your engineers can read and change.
Verification uses real documents rather than a single login test. The test set should include the Word, Excel and PowerPoint files your users actually send, PDFs, and documents with your corporate fonts, and it is run against the WOPI host before and after each image tag change. Optional retainers cover upgrades by image tag, security patch review and continuous support once the first move is complete. Ask any provider to state in the quote which of these items are one-time and which recur, who approves a tag change, and how a failed verification is handled. DeployOpen does not issue audit reports or certifications; where a compliance assessment follows, independent assessors make that judgment.
