When does an OX Documents implementation start with the license, not the install?
If your team wants browser-based text, spreadsheet and presentation editing inside OX App Suite, the first decision is not which server to install. OX Documents is part of the App Suite family, but Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Scope therefore starts with confirming in writing which rights your organization holds for Documents, under which terms, and for which user counts or deployment types. Whether you build in-house or bring in a partner, that answer changes the work. This page follows the order that matters for that decision. It starts with what the module does according to the Open-Xchange documentation, then covers the license questions in more detail. After that it covers the stack prerequisites, the data setup, the integrations with the document converter and spellcheck services, the factors that drive effort, and how rollout and handover are usually structured. Each section assumes the license has been confirmed, so read this one first.
Ask your Open-Xchange contact or reseller to name the exact modules covered by your agreement, including whether Documents is bundled with App Suite or sold as an add-on. Get the answer in writing and keep it with the scope document. Also confirm the deployment model the license allows: on-premises in your own Kubernetes cluster, a public cloud account you control, or the managed OX Cloud service. These are different commercial arrangements, and an agreement written for one may not cover another. Ask whether there are limits tied to user counts, tenants or environments such as test and disaster recovery, since those limits affect sizing and the number of instances you plan to run. Also check what the license does not change. Open-Xchange publishes mirrors of the App Suite UI and middleware code on GitHub under the AGPL-3.0 license. That public source does not by itself settle the rights to every module, and the license agreement governs what your organization can run, modify and distribute. Involve your legal and procurement teams early. If they discover a restriction after the platform is built, the cost of rework will be much higher than the cost of the questions asked now.
Once rights are confirmed, record them in the implementation plan as an input, not a footnote. Note the covered modules, the deployment model, the user limits, the support entitlement and any renewal or true-up terms. Support entitlement matters here: Open-Xchange's Support Commitment describes how standard releases and LTS releases are supported, so the release channel you choose depends on what your contract includes. Check which App Suite release lines your agreement covers before you pick a version to standardize on. The current LTS and the newest listed release are documented in the Support Commitment, and both should be checked against your contract at the time of planning. The licensing review also determines who should own the decisions that follow. If Documents is sold separately, the budget owner, the legal reviewer and the platform owner should sign off on the scope together. If it is included, the review can be shorter, but it still needs a named owner. Treat the license record as a controlled document that changes when the agreement changes, and link it to the release calendar so that an upgrade does not silently move you outside the terms you accepted.
What OX Documents adds to OX App Suite
OX App Suite groups Documents with email, calendar, Drive and Tasks, so office files are edited in the same environment where users already work. The cards below cover the components, editor types, hosting models and licensing terms that shape an OX Documents implementation.
Documents alongside the core suite
OX App Suite bundles Documents with email, calendar, Drive and Tasks, so office files are opened and edited from the same web interface where users already work. Confirm how Documents depends on the suite's identity, session and storage settings for your target release, because sign-in and file handling choices made for mail and Drive will shape the Documents rollout. Check which components must be enabled together before user onboarding begins.
Text, spreadsheet and presentation editors
The module provides three editor types: text, spreadsheet and presentation. Each covers a different office file family, so user testing should use representative file sets from each department, including documents with complex formatting, spreadsheets with formulas and presentations with embedded media. Ask the vendor which file formats each editor opens, saves and exports for your target version, and which features are limited in the browser. Record the results so that gaps are known before go-live.
Document converter and spellcheck services
Supporting services sit beside the editors and handle document conversion and spellcheck. Their exact roles and deployment units, including how many workloads each service needs, how they reach the editors and what resource limits apply, must be confirmed against the release documentation for the target version. Plan network paths, capacity and scaling for these services before performance testing, because a conversion bottleneck usually appears to users as slow document loading.
On premises, public cloud or OX Cloud
The suite can run on premises, in a public cloud or as the managed OX Cloud service. The hosting choice decides who operates the Kubernetes cluster, storage, database and Redis, who patches the Documents components, and where office files physically reside. Record the hosting decision in the written scope before design starts. Ask whether the managed service offers the same Documents features and release timing as a self-hosted deployment in your environment.
Module licensing and packaging
Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before design, confirm in writing whether Documents is included in your agreement, which editors and supporting services are covered, and whether any limits apply to users, environments or deployment models. Licensing terms affect architecture because they determine what you can deploy in each environment and what must be paid for separately.
Checking OX Documents license terms before sizing the rollout
Before you size an OX Documents rollout, confirm in writing what your license agreement grants for the module. The Open-Xchange Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Documents is one of the modules the guide places in that category, so the editors, the converter and the spellcheck service should not be assumed to be included just because the core App Suite is licensed. Treat the contract as the source of truth for scope, and ask for that answer before you choose user counts, server capacity or a deployment model.
Ask Open-Xchange or your reseller to confirm four things in writing. First, whether Documents is included in your agreement at all, or priced and packaged separately. Second, which user counts the grant covers, and whether it is tied to named users, concurrent users or mailboxes. Third, which deployment models it covers, such as on premises Kubernetes, a public cloud or a hosted arrangement, since a grant that fits one model may not fit another. Ask for the answer as a document you can attach to the design record, not as an email summary from a sales contact.
Ask separately whether the document converter and spellcheck services carry terms of their own. These components are often what makes Documents usable at scale, and they can have their own packaging, limits or support boundaries. If the converter is licensed or limited differently from the editors, the capacity plan for converter workers and the number of editing sessions you can run must follow that limit, not the total user count. Record the answer next to the sizing inputs so that a later change in user numbers triggers a license review.
Do not use the public source code as evidence of your rights. Open-Xchange publishes mirrors of the App Suite UI (appsuite-frontend) and middleware (appsuite-middleware) on GitHub under the AGPL-3.0 license. That license governs the copies of that code that are published under it. It does not, by itself, establish what your commercial contract grants for Documents, its converter or spellcheck services, or any separately packaged feature. Reading the public repositories can help you understand the code, but it is not a substitute for the signed agreement and its order documents.
Plan for the possibility that the answer changes the design. If Documents is a separately priced module, the rollout may start with mail, calendar and contacts while the editing features are scoped later. If limits apply, you may need to size fewer editing sessions or separate the converter onto its own capacity. Put these decisions into the written scope with your implementation partner before work starts, so that the license terms, the user onboarding plan and the infrastructure budget are approved from the same basis.
Which deployment and service choices shape an OX Documents rollout
This table compares the decisions that set the shape of an OX Documents rollout, with the options for each and when each one fits. Read it before scoping, because the deployment model, the user population, service placement and the storage backend are hard to change once users have files in the system. The main takeaway is that converter and spellcheck placement and external recipient access should be settled alongside the platform design, not added after go-live.
| Decision | Options | When each fits |
|---|---|---|
| Deployment model | On premises, public cloud, or OX Cloud | On premises or public cloud when you must run the stack in your own accounts or data centers; OX Cloud when you want the managed service |
| User rollout | All users, or a pilot group first | Pilot when you need to validate editing, converter load and storage behavior before wider enablement |
| Converter placement | Inside the App Suite cluster, or dedicated nodes in the same cluster | Dedicated nodes when conversion jobs could compete with mail and calendar workloads for capacity |
| Spellcheck placement | Inside the App Suite cluster, or a separately scaled service | Separate scaling when your language mix or user count makes spellcheck demand differ from the editing tier |
| External recipients | Internal users only, or editing for external recipients | External access when partners or customers must edit shared documents, which adds identity and sharing policy work |
| Storage backend for documents | NFS, or object storage such as S3, Ceph RadosGW or Scality RING | NFS for small to mid-size deployments; object storage for larger ones, chosen before Drive and PIM attachments accumulate data |
Which App Suite v8 stack OX Documents depends on
OX Documents does not run as a standalone application. It is part of the App Suite v8 platform, so the Documents deployment inherits the platform's Kubernetes, Helm, service mesh, cache and database requirements. The first decision is to confirm that your target App Suite release is delivered as Helm charts and that your team can deploy and upgrade those charts. OX App Suite v8 requires Helm 3.17.0 or newer, so your deployment tooling, pipelines and chart values files should be checked against that minimum before any cluster work begins.
The platform requires Istio. Open-Xchange documents a basic ingress-nginx option for environments where Istio cannot be used, and that choice changes how the editors and their collaboration traffic reach users. Decide early which path applies, because it affects ingress design, certificate handling and the network policies you write for Documents. Confirm with Open-Xchange which Istio releases the target App Suite release supports. Open-Xchange's guidance covers the latest Istio release plus two prior versions, but the exact pairing should be checked against the release you plan to deploy rather than assumed.
Caching and session storage run on Redis 7.4.x, deployed by default through the littlered operator. Teams with an existing managed or custom Redis service can configure that instead, but the choice must be made before go-live because session behavior for editing sessions depends on it. Plan who owns the Redis instance, how it is monitored and what happens to open editing sessions during a Redis failover. Database storage uses MariaDB with the InnoDB engine in the supported 10.6.x, 10.11.x, 11.4.x and 11.8.x series, and Galera Cluster is supported. Confirm the exact MariaDB series your release accepts and whether your database team already runs that series.
Kubernetes support follows the N-1 and N-2 rule for the App Suite release. Confirm which Kubernetes minor versions your target release accepts, and check the release notes for any Documents-specific component versions, such as the converter and spellcheck services. Those component versions can change between App Suite releases, so do not carry them over from an earlier deployment. Also check the Open-Xchange support commitment for the release you select, since a standard release has a short supported life and an LTS release is supported longer. A version mismatch found after installation usually means a rebuild of the cluster stack, so this check belongs in the design phase.
Ask your platform team to list every dependency in one matrix: Kubernetes, Helm, Istio or ingress-nginx, Redis, MariaDB and the file storage backend that Documents uses for files. For each row, record the version you will run, the owner, the upgrade trigger and the source that confirmed compatibility. Share this matrix with Open-Xchange before the scope is fixed, so that any gap between your standards and the supported stack is resolved in the written plan rather than during deployment.
How an OX Documents rollout runs, step by step
This sequence moves OX Documents from a confirmed license and version record to a tested, piloted and handed-over production service. Each step closes with a named artifact so the next step starts from agreed facts.
Confirm license and module scope
Start by confirming with Open-Xchange which modules and features your license agreement covers. The Operations Guide notes that module use may be subject to custom packaging, limitations or separate fees, so Documents must be checked against the signed agreement before any build work. Your team and the implementation partner agree the environments, user groups and integrations in scope. The step is complete when a signed scope document lists the Documents components, the converter and spellcheck services, and the environments to be built.
Choose target version and release channel
Select the App Suite v8 release and channel that will run in production. A standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months, and v8.47 is the current LTS, while v8.35 is discontinued. Record the chosen version, its end-of-support date from the support commitment, and the planned upgrade window. The output is a version record that the security, operations and application owners all approve.
Check cluster and stack readiness
Verify that the Kubernetes cluster, Helm tooling and supporting services meet the App Suite v8 requirements. Helm 3.17.0 or newer is required, Kubernetes must be within the N-1 or N-2 window, and Istio or the basic ingress-nginx option must be in place. Confirm Redis 7.4.x, a supported MariaDB version with InnoDB, and a distributed file system for persistent data. The platform team signs a readiness checklist, and any gaps are logged with owners before the test tenant is built.
Enable Documents in a test tenant
Deploy the chosen release into a test environment and enable Documents for a small set of test accounts. The engineers open and edit text, spreadsheet and presentation files, and confirm that Documents opens from mail and Drive. All Helm values and configuration changes are stored in version control so the build can be repeated. The step closes with a configuration baseline in version control and a note of any deviations from the reference setup.
Verify converter and spellcheck services
Test the document converter and spellcheck services with a representative set of office files taken from your own document types, including large and macro-free samples and files with languages used in your organization. Check that files convert correctly in both directions, that spellcheck works for each required language, and that failures are reported clearly to users. Confirm sizing and service placement with Open-Xchange before production. The output is a test report with pass or fail results per file type and a list of open issues with owners.
Run a pilot with a user group
Select a pilot group that uses the editors in daily work and includes users from the teams most likely to raise issues. Enable Documents for the group only, with sign-in through your identity provider over OpenID Connect or SAML, and collect feedback on editing, sharing and file handling for a period agreed in advance. The pilot lead logs each issue with its severity and resolution. The step is complete when the business owner and the service owner sign a pilot sign-off that lists accepted behavior and remaining known issues.
Enable Documents in production
Schedule the production change after the pilot sign-off, using the same configuration baseline that passed the test tenant checks. Confirm backup and restore coverage for the database and persistent storage before the change, and document the rollback steps in case the release must be reversed. The engineers enable Documents for the production user groups in the agreed order and watch service health, conversion errors and login behavior. The output is a production change record with the outcome, timing and any follow-up actions.
Communicate and hand over the runbook
Send users a short notice on what Documents does, where to find help and what has changed in their daily work, and publish it through the channels your organization already uses. Hand the service to operations with a runbook that covers version tracking against the support commitment, upgrade procedure, converter and spellcheck checks, log locations and backup verification. The operations team confirms receipt of the handover, and the rollout closes when a signed handover record and the runbook are filed with the service owner.
How document files and attachments are stored and backed up
Documents content is only as recoverable as the file store and database behind it, so the storage design has to be settled before the editors go live. OX App Suite requires persistent data such as OX Drive files and PIM attachments to sit on a distributed file system. NFS fits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING is the option to plan for at larger scale. Your team also needs to establish where office files saved from Documents are written, whether they land in the same store as Drive content or in a separate location, and which temporary paths the document converter uses while it processes files.
The core decision is how the database and the file store are backed up together. The database holds metadata and references, and the file store holds the document content. If the two are captured at different times, you can end up with records that point to files that no longer exist, or files with no record. Plan a single backup window or a coordinated snapshot across MariaDB, which is the primary data store with InnoDB as its engine, and every file store involved. If you run Galera Cluster, confirm how its consistency is checked during the backup. Also confirm whether object storage versioning or replication is in use, since those features change what a backup needs to capture.
Retention and restore need explicit rules and a tested procedure. Decide how long backups are kept, how deleted or superseded documents are handled, and who approves a restore. A restore test should bring the database and file store back as one set into an isolated environment, then check the result: open a sample of spreadsheets, text documents and presentations in the editors, confirm that attachments and Drive links resolve, and compare record counts against the source. Run the converter and spellcheck services in the same test so you know whether they depend on any state that also needs to be backed up.
The exact file handling for Documents must be confirmed in the product documentation for the version you deploy, not assumed from the Drive or mail design. Ask Open-Xchange or your implementation partner for a written list of every path and bucket Documents uses, the supported backup method for each, and the expected restore steps. Recurring costs will mostly come from storage capacity and the retention period for backups, which should be sized from your document volume and growth. One-time costs include the design, the backup configuration and the first full restore test. Ask any quote to name who operates the backup jobs and who runs the restore tests on a set schedule.
What drives OX Documents implementation effort and cost
This table compares the factors that change OX Documents implementation effort and cost, what each one does to the work, and how to keep it manageable. Cost is set by the written scope, so no price figures appear here. Read the license and cluster rows first, because they decide whether the build can start.
| Driver | Effect on effort | How to reduce it |
|---|---|---|
| License scope and negotiation | Documents may be packaged, limited or priced separately under the license agreement, which can add commercial review before design starts. | Confirm in writing which modules and features your agreement covers before the scope is signed. |
| Existing cluster readiness | Gaps in Helm 3.17.0 or newer, Istio, Kubernetes N-1 or N-2 support, Redis 7.4.x or MariaDB versions add remediation before install. | Inventory the cluster against the requirements page early, and decide whether an ingress-nginx option is acceptable where Istio cannot be used. |
| Storage backend choice | NFS suits smaller deployments, while object storage such as S3, Ceph RadosGW or Scality RING suits larger ones, and each changes setup and backup design. | Size users and expected file volume first, choose one backend, and reuse an existing platform if it meets the requirements. |
| Number of users and tenants | Higher user counts and more tenants increase sizing, performance testing, tenant configuration and support paths. | Define the tenant model, user groups and load targets in the written scope so they are not added later. |
| Converter and spellcheck verification | Conversion and spelling services must be tested against the Word, spreadsheet and presentation files your staff actually use. | Build a fixed test set of your real file types, confirm which converter and spellcheck components your release requires, and sign off before cutover. |
| Identity integration (OIDC or SAML) | OpenID Connect is documented for App Suite and SAML for middleware login, and claim mapping, group handling and MFA add design work. | Choose one protocol per environment, agree attribute mapping with the identity team early, and test with a small pilot group. |
| User training | Staff familiar with desktop office tools need guidance on the editors, sharing and file locations, and effort grows with headcount and departments. | Train a set of local champions, provide short task guides and schedule sessions around the cutover window. |
| Upgrade cycles to plan around | Standard releases are supported for 12 weeks, and LTS releases for the next LTS plus six months, so the team must test and apply upgrades on a recurring basis. | Choose the LTS track where it fits, schedule regular upgrade test windows, and state the upgrade responsibilities in the scope. |
How OX Documents connects to Drive, identity and the rest of the stack
OX Documents runs inside OX App Suite, so its connections are the App Suite connections: file storage, identity, data stores, cluster networking and operations tooling. Each dependency needs a decision about where it runs and who owns it before the editors go live.
Drive file storage and sharing
Documents are saved and shared through OX Drive, so the Drive storage backend determines where office files physically live. Persistent Drive data must sit on a distributed file system such as NFS for smaller deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Confirm which backend your team will use, how Drive quotas and sharing rules apply to edited files, and how file locking and versioning behave when several people open the same document.
OIDC single sign-on
OX App Suite supports single sign-on through OpenID Connect, and the same login path serves Documents users. Confirm with Open-Xchange documentation and your identity provider team whether Documents login follows the App Suite login flow in your version, which claims map to user accounts, and how session lifetimes and logout propagate. Settle this before pilot users are created, because changing the identity source later affects account matching.
SAML login configuration for the middleware
Open-Xchange documents a SAML login configuration for the middleware, which is relevant where your identity provider supports SAML but not OIDC for the target setup. Confirm against the operator guide for your release whether SAML is supported for your App Suite version, how the assertion attributes map to users, and which certificates need rotation. Do not assume the SAML and OIDC settings behave identically for Documents sessions.
Database and Redis dependencies
Documents relies on the same MariaDB and Redis services as the rest of App Suite. Supported MariaDB versions and InnoDB storage are listed in the requirements, and Redis 7.4.x is used for caching and session storage, deployed by default through the littlered operator or configured as an unmanaged or custom instance. Confirm which MariaDB topology, including whether Galera Cluster is used, and who operates Redis, backups and failover for both.
Kubernetes ingress and Istio layer
App Suite v8 is delivered as Helm charts on Kubernetes and requires Istio, with a basic ingress-nginx option only where Istio cannot be used. Document editing sessions depend on stable routing through this layer, so confirm the Istio version against the supported range, the Kubernetes version against the N-1 and N-2 policy, and the Helm version your pipeline uses. Test long editing sessions and websocket-style traffic through the ingress before sign-off.
Document converter and spellcheck services
The document converter and spellcheck services are separate components that Documents calls, so they add their own pods, scaling needs and failure modes. Confirm how many converter instances your expected concurrency requires, where they run in the cluster, and how a converter outage appears to users. Ask Open-Xchange for the current deployment guidance for these services in your release.
Monitoring, logging and backup tooling
Operations teams need App Suite and its dependencies visible in the monitoring and logging tools they already run, and they need backups that cover database rows, Drive file storage and Redis state where it matters. Confirm which metrics and log sources Open-Xchange exposes for your release, how Drive object or file storage is snapshotted consistently with MariaDB, and how a restore of a document with its metadata is tested. Record these owners in the runbook.
What buyers ask before hiring help with OX Documents
How much does an OX Documents implementation cost?
The cost follows from the written scope, and DeployOpen does not publish a price list, so the quote is the figure to compare. The main drivers are the editors you enable (text, spreadsheet and presentation), how the document converter and spellcheck services are sized and placed, whether Documents is wired into Drive and mail, and how much of the surrounding platform still has to be built. Your infrastructure matters too. OX App Suite v8 runs on Kubernetes with Helm, Istio or ingress-nginx, Redis and MariaDB, and gaps there add work. Ask the quote to separate one-time build effort from recurring items such as upgrades, monitoring and support, which are available as retainers. Licensing is a separate cost line set by Open-Xchange, so confirm it with them before you compare quotes.
How long does an OX Documents implementation take?
Duration depends on the scope and on your environment, and the timeline is agreed in writing before work starts. The largest driver is readiness of the platform underneath: a Kubernetes cluster on a supported version, a decision on Istio or ingress-nginx, Redis and MariaDB in place, and a distributed file system for persistent data such as Drive files and attachments. Timelines also stretch when access approvals, change windows, identity integration or user acceptance testing wait on other teams. Release choice affects planning as well. Open-Xchange lists v8.47 as the current LTS release, and an LTS is supported until the next LTS release plus six months, so a longer rollout may need a version check partway through. Ask for milestones and the dependencies each one assumes.
What does an OX Documents implementation need from our team?
Expect to provide people who own decisions, access and environment details. Typical needs include a product owner who signs off scope, platform engineers who can grant access to the Kubernetes cluster, container registry, databases and storage, identity owners for single sign-on through OpenID Connect or SAML, and a DNS and certificate owner. You also need users for acceptance testing across text, spreadsheet and presentation editing. Your team should agree on backup, monitoring, change control and who receives alerts after handover. Name these people in the scope so the schedule reflects their availability. If Open-Xchange requires a named licensing or documentation contact for your deployment, identify that person early as well.
Can our own engineers deploy OX Documents without outside help?
Yes, if your team already runs Kubernetes, Helm, a service mesh or ingress, Redis, MariaDB and a distributed file system at production standard, and can work closely from Open-Xchange's documentation. The install is only part of the work. The rest includes sizing the converter and spellcheck services, integrating authentication, testing editing across file types, setting up backups and planning upgrades against the support windows. Teams most often underestimate upgrade planning and recovery testing. Assess your skills against the requirements page before deciding, and write down which parts you would hand over. A partner can take the full build, a single area such as the upgrade plan, or a review of the build your team has already made.
Does our OX App Suite license cover OX Documents?
It may not. Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Whether Documents is included depends on your contract, your deployment type and the packaging agreed with Open-Xchange, and DeployOpen cannot confirm that for you. Check the license agreement for the Documents module by name, then ask Open-Xchange in writing whether it is included, limited or charged separately. Ask the same question about the converter and spellcheck services. DeployOpen can cover the technical deployment, but the licensing relationship sits between you and Open-Xchange. Settle this before scope sign-off so the quote does not assume an entitlement you lack.
How does a fixed-scope OX Documents engagement work?
Most engagements are fixed-scope. DeployOpen and your team agree the scope, deliverables and timeline in writing before work starts, and the quote follows from that document. Typical stages are a requirements review against your environment, a written scope that lists the editors, services, integrations and exclusions, then build, testing and handover. Changes after signing go through a written change request that states the effect on cost and schedule. Check that the scope names what it excludes, such as licenses, hardware and cloud spend. Ask for acceptance criteria for each deliverable, the test evidence you will receive, and the support or upgrade retainer that follows handover. Ongoing support, upgrades and continuous testing are separate retainers, not part of the build.
What infrastructure does OX Documents need before deployment?
Documents runs inside the OX App Suite v8 platform, so the prerequisites are the platform's. OX App Suite v8 is delivered as Helm charts that reference container images, and it requires Helm 3.17.0 or newer. It is designed for Kubernetes and supports the N-1 and N-2 Kubernetes versions. It requires Istio, supporting the latest Istio release plus two prior versions, with a basic ingress-nginx option where Istio cannot be used. Redis 7.4.x handles caching and session storage, deployed by default through the littlered operator. MariaDB with InnoDB is supported in 10.6.x, 10.11.x, 11.4.x and 11.8.x, including Galera Cluster. Persistent data needs a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Confirm converter and spellcheck sizing for Documents against Open-Xchange's documentation for your chosen release.
Which OX App Suite version should we target for Documents?
Target a version that is still inside Open-Xchange's support window, and choose between standard releases and LTS based on how often you can upgrade. A standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. According to the support commitment, v8.35 was the first v8 LTS and is now discontinued, and v8.47 is the current LTS. The commitment also lists v8.53 as the newest release, with first customer shipment on 2026-09-23. Deploying on a discontinued release creates upgrade work on day one, so confirm the current entries in the support commitment on the day you sign. Ask that the scope include the upgrade path you expect to follow after go-live.
How DeployOpen scopes and delivers an OX Documents implementation
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and OX Documents work follows the same pattern. The engagement starts with a written, fixed scope that settles the editors, converter and spellcheck services, module licensing and the platform they sit on before any build begins.
How we scope
- Confirm which OX Documents editors you need and which users will open them.
- Map the document converter and spellcheck services onto your existing OX App Suite topology.
- Check module license terms with Open-Xchange, since some modules may carry separate fees.
How we build
- Deploy the OX App Suite v8 Helm charts and the Documents components into your Kubernetes cluster.
- Verify Istio or ingress-nginx routing for the editors and converter, and test document opening and saving.
- Test spellcheck behavior and file persistence on the storage backend you selected.
How we hand over
- Provide the written configuration, deployment records and the as-built architecture for your team.
- Document the module license position, including what your agreement covers and what needs confirmation.
- Walk your operations staff through upgrade steps, testing and rollback for the Documents components.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, scoped in writing.
- Plan upgrades against the Open-Xchange support commitment for the release channel you run.
- Review converter and editor performance as user numbers and document volumes change over time.
