When an OX Drive implementation makes sense for your App Suite estate
OX Drive is the file storage and sharing module of OX App Suite, and it sits alongside the mail, calendar and contacts that you run or plan to run on OX App Suite v8. If your users already depend on the core deployment and now need a governed place to store and share files, Drive is the module to evaluate. Its implementation is mostly about three decisions: the storage backend that holds user files, the identity path that signs users in, and the sharing policy that controls who can share what with whom and for how long.
The storage backend is the first decision and the one that is hardest to change later. Open-Xchange requires that persistent data such as Drive files and PIM attachments sit on a distributed file system. NFS is the documented option for small to mid-size deployments, and object storage such as AWS S3, Ceph RadosGW or Scality RING is the option for larger ones. Count your expected user numbers, file volumes and growth over the planning horizon, then ask Open-Xchange to confirm which backend and sizing it expects for that profile. If your organization already runs Ceph or an S3-compatible platform, check early whether your storage team will operate it as a dependency of the App Suite estate.
Identity and sharing policy are the second and third decisions. OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware. Confirm which protocol your directory and identity provider will use, how group membership maps to Drive roles, and whether external sharing requires any additional authentication. Write the sharing rules down before go-live: which users may create external links, which domains are allowed as recipients, and how expiry and removal of departed users are handled. These choices are easier to set before users have accumulated files than to correct afterward.
Decide whether Drive belongs in the initial build or is added later. If it is scoped with the core deployment, the storage class, backups, ingress and identity configuration are designed once. If it is added to a running estate, ask the vendor how the module is enabled on an existing cluster, whether storage changes require a maintenance window, and how backups and restore tests are extended to cover file data. Licensing also needs a check before scoping. Open-Xchange's Operations Guide notes that the right to use certain modules may be subject to custom packaging, limitations or separate fees set in the license agreement, so confirm in writing whether Drive is included in your agreement and whether any recurring fee applies.
What OX Drive does inside App Suite, according to the platform docs
The platform documentation places Drive alongside email, calendar, Documents and Tasks inside one App Suite deployment. The cards below separate what the docs confirm from what still needs checking against your App Suite version before you size storage, plan sharing or choose a sync client.
Drive as part of the suite
According to the platform documentation, OX Drive provides file storage and sharing inside App Suite, next to email, calendar, Documents and Tasks. For an implementation, this means Drive shares the same identity, login and deployment as the rest of the suite rather than running as a separate product. Confirm with the vendor which Drive features are included in your license and which are separately licensed modules.
Deployment models Drive can run in
The documentation states that App Suite can run on premises, in a public cloud or as the managed OX Cloud service. Your choice determines who operates the storage tier, the Kubernetes cluster and the backups that hold Drive data. Decide the model before sizing storage, because it changes which storage backends and operational responsibilities are realistic for your team.
Distributed file system for persistent files
The requirements state that persistent Drive files must sit on a distributed file system. Small to mid-size deployments use NFS, while larger ones use object storage such as AWS S3, Ceph RadosGW or Scality RING. Ask which option fits your file volume, latency needs and failure domains, and whether your storage team can operate it.
Sync client behavior to confirm
The supplied documentation context does not describe Drive sync client behavior in detail. Before committing to desktop or mobile sync, check the Drive documentation for your exact App Suite version. Test conflict handling, offline behavior and how sync interacts with your proxy and identity configuration in a staging environment.
Sharing options to confirm
Sharing rules determine who can reach a file and how long links remain valid, which matters most for regulated data. The details for internal, external and link-based sharing were not supplied here. Verify in the Drive documentation for your App Suite version whether sharing can be restricted by group or domain, and how external recipients authenticate.
Admin controls to confirm
Administrators need controls for quotas, retention, auditing and disabling sharing for specific users or groups. The documentation context for this topic does not list these controls. Before design sign-off, ask the vendor which administrative settings exist in your version, which are configured through the middleware, and which require a license or a separate module.
Which configuration decisions shape an OX Drive build
This table lists the decisions a team should settle before building OX Drive, with the conditions under which each option fits and what it commits the organization to. Read each row as a question to answer with your storage, identity and sharing requirements in hand. The main takeaway is that the storage backend and the choice of replacing or sitting beside an existing file platform are the decisions that are hardest to reverse.
| Decision | When the option fits | What it commits the organization to |
|---|---|---|
| File storage backend: NFS | Small to mid-size deployments where a distributed file system with NFS is already operated and supported | Operating the NFS service, its performance under Drive and attachment load, and its backup and restore process |
| File storage backend: object storage | Larger deployments that need object storage such as AWS S3, Ceph RadosGW or Scality RING at scale | Running or paying for an object store, its access model, credentials management and capacity planning |
| Deployment model: on premises | Data must stay in your data centers or air-gapped networks and your team will operate the platform | Your team owns hardware or virtualization, storage, patching, upgrades and disaster recovery |
| Deployment model: public cloud | Your cloud accounts are approved for the data classes Drive will hold and you want infrastructure you already run | Cloud account structure, network controls, storage encryption choices and cloud cost management |
| Deployment model: OX Cloud | You want the managed OX Cloud service and accept the provider's operating responsibilities for the platform | Reviewing the service terms, data location, and what the provider operates versus what your team still owns |
| Identity source: OpenID Connect | Your identity provider supports OIDC and you want single sign-on for App Suite login | Configuring client registration, claim mapping, token lifetimes and the users who can sign in |
| Identity source: SAML | Your identity provider or directory federation uses SAML and OIDC is not available | Configuring the SAML login for the middleware, certificate rotation and attribute mapping to user accounts |
| Sharing policy: internal and external | Users need to share files with colleagues and with people outside the organization | Defining who may share externally, which domains are allowed and how external recipients are authenticated |
| Sharing policy: link-based sharing | Teams send links to recipients who do not have accounts and the data class allows it | Link expiry, password rules, download controls and logging of link access, to be confirmed against the Drive documentation |
| Replace or sit beside an existing file platform: replace | The existing platform is retired and users move their files and sharing to Drive | A migration plan for files, permissions and sync clients, plus a cutover and retirement schedule |
| Replace or sit beside an existing file platform: sit beside | Some teams must keep their current platform, such as Nextcloud, during transition or for specific workloads | Two sets of identity, storage, backup and support processes, and a clear rule for which platform holds which data |
How the storage backend choice drives the OX Drive build
The storage backend is the first hard architecture decision in an OX Drive build, because OX Drive files and PIM attachments must sit on a distributed file system. Everything else in the plan, including sizing of the Kubernetes nodes, backup design and the recovery runbook, depends on which option you pick. Make this decision before you commit to capacity or to a delivery timeline with a partner.
The requirements position NFS for small to mid-size deployments and object storage for larger estates. Object storage examples named in the requirements are AWS S3, Ceph RadosGW and Scality RING. NFS keeps the model familiar to storage teams, but it puts the availability of the file service on the NFS platform itself, so you need people who can run that platform, define export and permission models for the Kubernetes workloads, and test failover. Object storage shifts the work toward bucket policies, access keys, lifecycle rules and capacity planning around the object store, and it usually suits growth that is hard to predict.
Backup approach differs between the two. With NFS, you typically back up the file system and the database together and verify that a restore brings back a consistent set of files and metadata. With object storage, you must confirm whether backups use versioning, replication to a second site, or a separate backup tool, and whether that tool can restore individual users' files. In both cases, plan how Drive file metadata in the database stays consistent with the stored objects after a restore, and test that path rather than assuming it works.
Capacity planning needs input from your own user counts, average file sizes, sharing patterns and retention rules. Ask Open-Xchange to confirm the storage versions it supports for each option, any quotas or limits that apply to Drive and attachments, and how replication behaves across sites or zones. Do not treat the NFS or object store documentation as a substitute for that confirmation, because the application's supported combinations and its handling of failures decide what is safe in production.
Before you choose, write down the expected growth over the planned support period, the recovery time your business requires for files, and the skills your team already has. Use those answers to test both options against a short written scope. If you cannot confirm the supported versions, quotas and replication behavior in writing, treat the storage choice as open and carry it into the quote request as a named assumption.
Implementation sequence for OX Drive, and the output of each step
The sequence moves from confirming the App Suite v8 platform baseline to a handed-over runbook set, with a named output at each step so the client can check progress and sign off before the next stage starts.
Confirm the App Suite v8 baseline and prerequisites
Before any Drive work, confirm the App Suite v8 release you will run and check the cluster against the requirements: a Kubernetes version within the supported N-1 or N-2 window, Istio (or the basic ingress-nginx option where Istio cannot be used), Helm 3.17.0 or newer, Redis 7.4.x and a supported MariaDB version. Confirm the release channel and whether you are on a current LTS release, using the support commitment as the reference. This step is led by DeployOpen with your platform team, and it is done when a written prerequisites checklist is signed off against your actual cluster, not a generic template. Ask the vendor to confirm any version not listed in the supplied requirements before you commit.
Choose and provision the distributed storage backend
Drive file data must sit on a distributed file system. NFS is the documented option for small to mid-size deployments, and object storage such as AWS S3, Ceph RadosGW or Scality RING is the option for larger ones. Compare the options on throughput, durability, backup tooling, your existing skills and where the data must physically reside. Provision the chosen backend in your environment and test mounts or bucket access from the cluster. The output is an approved storage design record that names the backend, capacity model, access path, encryption approach and owner, signed off by your storage and security leads.
Configure identity through OpenID Connect or SAML
Connect App Suite to your identity provider using OpenID Connect, which App Suite documents directly, or SAML, which Open-Xchange documents for the middleware login. Define claim mapping, group handling, session lifetime and how directory accounts match mailbox and Drive users. Test sign-in with a set of test accounts that covers normal users, administrators, disabled accounts and a user removed from a group. The output is a tested login flow with a recorded result for each test case, and a list of any open items your identity team must resolve before go-live.
Enable and configure Drive with sharing and quota policy
Enable Drive for the tenant or context and set the policies that govern daily use: which users may create external share links, expiry defaults, password requirements for shares, default and maximum quotas, and file types or size limits where your policy requires them. Decide what the sharing policy means for external recipients before users see the feature. Verify each policy in a non-production context by attempting the action as a standard user and as an administrator. The output is a configuration record and a policy test sheet, which becomes the reference your support team uses later.
Roll out sync clients to a pilot group
Install the sync clients on managed devices for a small pilot group that represents your main working patterns, such as office, remote and shared-folder users. Check that files sync in both directions, that conflicting edits create copies rather than losing data, that large files and offline changes behave as expected, and that proxy, VPN and certificate settings on corporate devices work. Collect user feedback on performance and confusion points. The output is a pilot sign-off record listing the tested scenarios, the issues found and their resolution, and the approval to widen the rollout.
Migrate or import existing file data
If users already hold files in a file share, a separate file platform or personal storage, plan the import as a separate, repeatable task. Map folder ownership and permissions, agree which data stays behind, and run a test import on a copy first. Compare file counts, sizes and checksums between source and target, and review a sample of files with their owners. Decide whether a separate file platform such as Nextcloud will run alongside Drive or be retired, since that decision changes the migration scope. The output is a migration reconciliation report with counts, exceptions and owner sign-off for each migrated area.
Verify backup and restore of file data
Confirm that backups capture the Drive file store, its metadata in the database and the configuration needed to rebuild the service, and that they are stored outside the failure domain they protect. Then perform a restore into an isolated environment, time it, and check that restored files open, shares resolve and quotas match. Record what was restored, what was missing and how long each step took in your environment. The output is a restore test record, reviewed by your operations and security teams, that states what the recovery procedure achieves in practice.
Hand over runbooks and operational ownership
Close the engagement by handing over runbooks for routine operations, incident response, user support, quota changes, sync client updates, upgrades and restore. Walk through each runbook with the teams that will run it and confirm who owns each task after handover. Agree whether ongoing support, upgrades and testing will be handled by your team or under a retainer. The output is an accepted runbook set and an ownership matrix signed by your platform lead, which marks the point where the implementation is considered complete.
What drives OX Drive effort and cost, and how to keep it down
This table lists the factors that most change the effort and cost of an OX Drive rollout, with the cost direction, which parts are one-time or recurring, and what to request in a written quote. Use it to compare scope options before asking for a fixed-scope proposal. No prices or durations are given here, so ask for them in writing against your own environment.
| Driver | How it moves cost or effort | One-time or recurring | What to request in a written quote |
|---|---|---|---|
| Number of users and expected file volume | More users and more stored data increase storage sizing, capacity testing, and the time spent on load and performance checks. Volume estimates made early set the storage tier. | One-time sizing and testing; storage capacity recurs as data grows | Assumed user count, expected data per user, growth forecast, and the capacity test scope |
| Storage backend: new object storage versus existing NFS | OX Drive files must sit on a distributed file system. NFS suits small to mid-size deployments, while object storage such as S3, Ceph RadosGW or Scality RING suits larger ones. Building new object storage adds platform work; reusing NFS adds performance and resilience checks. | Platform build is one-time; capacity and hardware or licensing for storage recur | Chosen backend, why it fits the expected scale, sizing assumptions, and whether the storage platform is included or assumed to exist |
| Identity already federated or not | Where OIDC or SAML login from an existing directory is already working, integration is smaller. If identity must be built or cleaned up first, the work grows and may run ahead of the Drive project. | One-time integration; directory and certificate upkeep recurs | Identity provider in scope, login protocol, group mapping for Drive, and who owns directory changes |
| Size and location of existing file repositories to migrate | Large or scattered file shares, legacy home drives, and mixed permissions take longer to inventory, map and validate. Data located across regions or sites adds transfer and access planning. | One-time migration and validation | Source inventory (volume, file count, locations), permission mapping approach, cutover plan, and validation criteria |
| Number of sharing and retention policies | Each sharing rule, link policy, expiry rule, or retention period needs design, configuration, and testing. Fewer, standard policies keep the build smaller and the review cycle shorter. | Design and testing one-time; policy review recurs | List of sharing and retention policies in scope, approval owner for each, and how policy changes are handled after go-live |
| Sync client rollout breadth | Rolling out desktop and mobile sync clients to a few teams is simpler than a company-wide rollout with device management, packaging, and user support. Platform differences in client behavior add testing. | Packaging and rollout one-time; support and client updates recur | Client platforms in scope, pilot group size, device management method, and user support hours or channel |
| Module licensing terms set in the agreement | OX Drive and related modules may be subject to custom packaging, limitations, or separate fees set in the license agreement. Confirm which features are included before design, since a missing entitlement changes the scope. | License fees are typically recurring; configuration is one-time | Written statement of entitled modules and features, license term, renewal conditions, and any usage limits |
| Integration with backup and monitoring | Backup of file data and metadata, restore testing, and monitoring of storage and the Drive service must be built around the chosen backend. Teams without an existing backup target or monitoring stack add scope. | Integration one-time; backup storage, monitoring, and restore tests recur | Backup target and retention, restore test frequency and scope, monitoring tools in use, and alerts covered at handover |
Should OX Drive replace Nextcloud or sit beside it?
The first decision is whether OX Drive becomes the single file platform for your organization or runs alongside Nextcloud for a defined group of users. Neither answer is correct by default. The choice turns on which users already depend on Nextcloud, how much of your identity and sharing policy must be identical across both platforms, and whether your team can operate two file systems without weakening either one. Treat this as a requirements exercise, not a product preference, and confirm every detail below with both vendors before you commit.
Licensing and support models differ. Nextcloud Server is licensed under AGPL-3.0, so the community edition carries no license fee. Nextcloud GmbH also sells Nextcloud Enterprise in Standard, Premium and Ultimate tiers with a 100-user minimum and list prices per user per year. Its pricing page describes Standard as including one year of maintenance, Premium adding a lifecycle of five or more years and clustered instance support, and Ultimate adding support up to 24/7. OX App Suite is delivered under a commercial agreement, and some modules may be subject to separate fees set in the license agreement. Ask each vendor for a written statement of what is covered, for how long, and for which users, then compare the two in the same currency and period.
Release cadence is the operational cost to plan for. Nextcloud publishes a new major version every four months and supports each one for a year, and it does not allow skipping major releases. An administrator running Nextcloud therefore plans a sequence of one-step upgrades, with a backup before each one and third-party apps checked for compatibility. OX App Suite has its own cadence: standard releases are supported for 12 weeks, and LTS releases are supported until the next LTS plus six months. Map both calendars against your change windows before deciding which platform your team can keep current.
How OX Drive connects to identity, storage and the rest of the platform
OX Drive depends on six connection points: sign-in, file storage, the data layer, the Kubernetes networking layer and the office editor. Each one changes how Drive behaves for users, so decide them before installation. Confirm every connection in your target environment, because supported versions and options depend on the platform release you deploy.
Sign-in through OpenID Connect or SAML
App Suite supports single sign-on through OpenID Connect, and Open-Xchange also documents SAML login configuration for the middleware. Decide which protocol your identity provider will use, then map the claims or attributes that identify each user. Confirm with Open-Xchange how the documented SAML configuration applies to your release, and test a disabled account and a password reset before go-live.
Distributed file system for Drive data
OX Drive files and PIM attachments must 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 documented option for larger ones. Ask how the chosen store is backed up and restored alongside the database, because file content and file metadata must stay consistent after a restore.
MariaDB and Redis data layer
MariaDB with the InnoDB storage engine is the primary data store, and the supported lines are 10.6.x, 10.11.x, 11.4.x and 11.8.x. Galera Cluster is supported for higher availability. Redis 7.4.x handles caching and session storage, deployed by default through the littlered operator, with unmanaged or custom Redis configurable. Confirm the database line and Redis topology against the requirements for your release before you size the cluster.
Kubernetes with Istio or ingress-nginx
App Suite v8 is delivered as Helm charts on Kubernetes and requires Helm 3.17.0 or newer. Kubernetes versions N-1 and N-2 are supported, and Istio is required, with the latest Istio release plus two prior versions supported. Where Istio cannot be used, the basic ingress-nginx option applies, so confirm early whether your platform team can operate Istio before the cluster design is fixed.
Documents for office files in Drive
Documents edits office files stored in Drive, so the storage choice affects editing as well as sharing. Confirm that the editors reach files through the same storage path that users see in Drive. Test opening, saving and concurrent edits on your chosen file store, and confirm the Documents module scope in the license agreement before you promise editing to users.
Nextcloud coexistence and sibling modules
If Nextcloud already holds files, decide whether Drive runs beside it or takes over those workloads, since both platforms can use OpenID Connect or SAML for sign-in and LDAP-based directory access. OX Guard adds encryption for mail and Drive files, and some modules may carry separate fees set in the license agreement. Confirm each module's terms and each integration in your environment before you commit to a file platform.
Questions teams ask before an OX Drive implementation
What does an OX Drive implementation cost and what drives the price?
DeployOpen does not publish a price list, and the quote follows from the written scope. Who is paid for what: DeployOpen is paid for planning, infrastructure preparation, storage and identity configuration, backup setup, testing, documentation and handover. Open-Xchange licenses are paid under your license agreement, and you pay for the infrastructure itself, including Kubernetes capacity, file storage, the database and the backup target. What recurs: infrastructure, license renewals and any support or upgrade retainer continue after go-live, while the build work is usually one-time. What drives cost up or down: user and mailbox counts, the expected file volume, the storage backend you choose, the number of identity and other integrations, whether you migrate existing files, and the service mesh or ingress choice. Ask the quote to show one-time and recurring items separately.
How long does an OX Drive implementation take?
The timeline is set in the written scope, and no fixed duration applies to every deployment. The main drivers are how quickly your Kubernetes platform and storage backend are ready, how long identity integration takes (OpenID Connect or SAML), how much existing file data must be migrated and validated, and how many sync clients and user groups must be rolled out. Approvals from your security, compliance and change teams often set the pace more than the technical build does. Storage procurement is another common delay if the object storage or NFS capacity is not in place at kickoff. Ask for a milestone plan that names which prerequisites your team owns and which dates depend on them.
What skills does our internal team need for OX Drive?
Your team needs working knowledge in four areas. Storage: administration of NFS for small to mid-size deployments, or of object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones, including capacity growth and performance. Identity: configuring OpenID Connect or SAML login against your directory and checking group mapping. Kubernetes: operating a cluster that supports the Helm charts, which require Helm 3.17.0 or newer, plus the Istio or ingress-nginx option and the supported Kubernetes versions. Backup: taking consistent backups of the database and the file store together, and proving restores work. Dependencies also include MariaDB (10.6.x, 10.11.x, 11.4.x or 11.8.x) and Redis 7.4.x. Confirm the exact versions in the requirements before you commit to a design.
Can our own team implement OX Drive without a partner?
Yes, a capable internal team can implement OX Drive, but the work is broader than the application itself. Open-Xchange publishes mirrors of the App Suite UI and middleware code on GitHub under AGPL-3.0, but those mirrors do not replace your license agreement, and you should confirm which components and modules your entitlement covers. Your team also takes on the upgrade burden. Open-Xchange supports a standard release for 12 weeks, and an LTS release until the next LTS release plus six months, so you must plan upgrades on that cadence. If you use a partner, DeployOpen works under a fixed scope with written deliverables, and ongoing support, upgrades and testing are available as retainers. Compare the internal effort with the scope before deciding.
Can OX Drive run alongside Nextcloud in the same organization?
Running both is possible as two separate platforms, but confirm any integration between them in the written scope, because the supplied material does not document a built-in link between OX Drive and Nextcloud. Each platform brings its own identity configuration, storage, database, backup routine and upgrade cycle. Nextcloud publishes a new major version every four months, supports each for one year, and does not allow skipping major releases, so administrators must step through each major version with a backup before every upgrade. Open-Xchange sets its own release and LTS timing. Decide early which user groups or data types belong on each platform, how users find files in each, and who owns the operating effort for both.
Which OX Drive licensing terms should we confirm before buying?
Confirm these points in writing with Open-Xchange and in your agreement. 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, so check whether Drive is included in your entitlement and whether any feature you need carries a separate charge. Other items to confirm: the user count and tier basis, whether sharing and sync client use carries conditions, which Documents, Guard or other modules are priced separately, what support level applies, and how upgrades to new LTS releases are covered. Ask for the terms that apply to your hosting model, whether on premises, in a public cloud or through a managed service, because these can differ.
What storage backend does OX Drive need for production?
OX Drive files must sit on a distributed file system. Open-Xchange documents NFS for small to mid-size deployments and object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Choose by expected file volume, growth rate, latency needs and the skills your team already has. Object storage usually suits larger or growing estates, but it adds an access layer to plan. NFS is simpler to start with but needs careful capacity, performance and failover design at scale. Whichever you choose, test restores of file data together with the database, check how the backend behaves during a node or site failure, and set quotas and retention rules before users arrive. Confirm the final design with your storage team and the written scope.
How DeployOpen scopes, delivers and supports an OX Drive implementation
DeployOpen plans, implements, integrates, hardens, backs up and documents OX App Suite with OX Drive inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- Written scope defines whether OX Drive files live on NFS or object storage such as Ceph RadosGW or S3
- Sharing rules, user groups and external guest access are listed as in-scope or out-of-scope items
- The scope records whether Drive replaces a separate file platform such as Nextcloud or runs beside it
How we build
- Configure the distributed file system Drive depends on, then connect it to App Suite's persistent data
- Configure sharing, guest access and identity sign-in, with OpenID Connect or SAML where your directory requires it
- Test sync clients against the target operating systems and browsers, and document each supported version
How we hand over
- Runbooks for storage capacity, backup restore and sharing administration, written for your operations staff
- Test evidence for restores and access controls, prepared for your internal reviews or external auditors
- Documented decision record covering the Drive backend and licensing terms for any module with separate fees
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Upgrade planning follows OX App Suite support commitments, including the LTS release window
- Storage capacity checks, restore tests and Drive access reviews can be scheduled under a retainer
