What an OX App Suite v8 implementation involves
OX App Suite v8 is delivered as Helm charts that reference container images and run on a Kubernetes cluster, and the platform beneath the application often takes more effort than the application configuration itself. The chart requires Helm 3.17.0 or newer, and the stack expects Istio as the service mesh, with a basic ingress-nginx option only where Istio cannot be used. Redis 7.4.x handles caching and session storage, deployed by default through the littlered operator, and MariaDB with InnoDB is the primary data store. Persistent data such as OX Drive files and PIM attachments needs a distributed file system, NFS for smaller deployments or object storage such as S3, Ceph RadosGW or Scality RING for larger ones.
Three triggers usually start this work: a new mail platform, replacing an older deployment, or a hosting provider launching a service. Each one changes the early decisions. A greenfield build leaves the cluster, storage and identity choices open. A replacement or provider launch often inherits existing directories, mailbox volumes and operating habits, which means the platform team must confirm the Kubernetes and Istio versions, the storage class and the database topology before anyone writes application configuration. Ask your team which of these already exist and which must be built.
In-house delivery suits teams that already run Kubernetes, Istio, managed Redis and MariaDB, and have staff who can own Helm values, upgrades and storage operations after go-live. A partner is usually the better choice when one or more of those platforms is new to the team, or when the migration deadline leaves no room for learning on the job. Ask any partner for a written scope that separates platform build, application configuration and cutover support, so you can compare it line by line with your own estimate.
Cost follows the platform gaps you find in that inventory, and both the one-time build and the recurring run cost need to be on the quote. One-time items include cluster setup, storage design, database and Redis deployment, identity integration and testing. Recurring items include infrastructure, support subscriptions, patching inside the support window and the staff who operate the stack. Confirm with Open-Xchange which modules fall under custom packaging or separate fees in your license agreement, because the Operations Guide notes that these terms are set in the license, not in the platform itself.
What the work includes and what you receive
Each card below is one work package in a fixed-scope Open-Xchange plan. Scope, deliverables and timelines are agreed in writing before work starts, so the list below is what you can expect to see in that written scope, not a menu of optional extras.
Platform prerequisites
We confirm the Kubernetes version against the N-1 and N-2 support rule, the Istio release against the latest-plus-two rule, or the ingress-nginx fallback where Istio cannot be used, and the Helm version, which must be 3.17.0 or newer. You receive a prerequisites checklist with the cluster, DNS and ingress decisions recorded and signed off by your platform team.
OX App Suite Helm deployment per environment
We install the official OX App Suite v8 Helm charts with separate values files for development, test and production, so each environment differs only where you intend it to. You receive the deployed charts, the values repository and a record of which image versions run in each environment.
Mail backend and storage connection
We connect the middleware to your MariaDB InnoDB data store, including the chosen topology such as a single instance or Galera Cluster, and attach the distributed file system or object storage used for OX Drive files and PIM attachments. The main decision to confirm early is NFS against object storage, which depends on your mailbox and file volume.
Identity connection
We configure single sign-on through OpenID Connect, or SAML where your identity provider requires it, and agree how users and contexts are provisioned from your directory. You receive a tested login flow for each environment and a list of the directory attributes the platform depends on.
Release and support plan
We set the release channel, either the standard release line or the LTS line, and map each upgrade window against the published support end dates so you never run an unsupported build. You receive a written release calendar, an owner for each upgrade decision and a test gate that each Helm chart upgrade must pass before rollout.
Test and acceptance
We run functional tests for mail, calendar, contacts, Drive and Documents, plus failover and restore checks for the components you asked us to test, against criteria written before the build starts. You receive test scripts, results and a signed acceptance record that names what passed and what was accepted with known gaps.
Documentation and runbooks
We write the operating documentation for your own team: architecture, configuration by environment, Redis and MariaDB operations, backup and restore steps, upgrade procedure and escalation paths. You receive runbooks your operators can follow without us, along with a note on which items your licence terms or module agreements may still require you to confirm.
What drives cost and duration
This table lists the inputs that most change the effort of an OX App Suite v8 deployment, why each one adds work, and how to keep it manageable, so you can ask a partner or your own team for a scoped quote.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Mailbox and user counts | Mailbox and user numbers set the sizing of MariaDB, Redis, middleware replicas and storage, and they determine how much data a migration must move at cutover. | Confirm the peak concurrent user count and the mailbox population per context with the business owner before sizing, and phase onboarding by business unit. |
| File and attachment volume | OX Drive files and PIM attachments must sit on a distributed file system, so total volume drives storage capacity, backup scope and restore time. | Measure current mailbox and file-share volumes, set retention rules for old attachments and agree on a quota model before the storage design is frozen. |
| Kubernetes and Istio readiness | OX App Suite v8 is delivered as Helm charts on Kubernetes and requires Istio, so a cluster that lacks a supported version, DNS setup or Istio experience adds platform work before any application work starts. | Check the cluster against the supported Kubernetes and Istio versions in the requirements, and decide early whether ingress-nginx is an acceptable fallback where Istio cannot be used. |
| Redis topology | Redis 7.4.x holds caching and session data. The default operator-based deployment is quicker to stand up, while an unmanaged or custom Redis setup needs your team to build and maintain its own high availability and failover. | Use the default operator path unless a corporate standard forces otherwise, and confirm who owns Redis patching and failover tests. |
| MariaDB topology (single instance or Galera Cluster) | A single MariaDB instance is simpler to build, but high availability needs a Galera Cluster, which adds node sizing, quorum rules, state transfer testing and monitoring for each node. | Decide on the availability target before design. If Galera is required, plan node count, backup method and failover tests as separate work items in the scope. |
| Storage choice (NFS or object storage) | NFS suits small to mid-size deployments. Object storage such as AWS S3, Ceph RadosGW or Scality RING suits larger ones, but it adds integration, access policy, lifecycle and capacity planning work. | Choose the storage class by volume and by what your infrastructure team already runs. Confirm supported backends with Open-Xchange before procurement. |
| Identity source (OIDC or SAML) | Single sign-on needs a configured identity provider, claim mapping, session and autologin rules, and user provisioning from a directory. SAML and OIDC each carry their own configuration and testing effort. | Name the identity provider and protocol early, and reuse an existing federation where one exists. Confirm the exact login configuration in the OIDC and SAML documentation for your release. |
| Number of environments | Each environment (test, staging, production, and sometimes a disaster recovery site) needs its own Helm values, secrets, data sets and test runs, so effort scales with environment count. | Keep one chart and one values structure with per-environment overrides, and limit the number of long-lived environments to what the test plan requires. |
| Compliance evidence needs | Assessors expect documented configuration, access reviews, backup and restore tests, patch records and change history. Producing this evidence is extra work on top of the technical build. | Agree the evidence list before build begins, and generate it from the build process where possible. DeployOpen prepares evidence, but auditors and certification bodies issue any assessment outcome. |
| Deployment model (on premises, public cloud or OX Cloud) | On premises work includes hardware, network and storage procurement. Public cloud work adds account, network and managed service design. OX Cloud moves platform operation to the provider, so your scope shifts toward integration and migration. | Decide the model before scoping. Confirm with Open-Xchange what the managed OX Cloud service includes, and which parts of the self-hosted scope would remain yours. |
Project phases and the output of each
The sequence moves from sizing and architecture decisions through platform build, application deployment, migration hand-off, testing and handover, and each phase closes with a named artifact.
Confirm scope, sizing and mailbox profile
Your team and DeployOpen review mailbox counts, mailbox growth, expected use of Drive and Documents, identity sources and the hosting location. DeployOpen confirms the target infrastructure and the support window you intend to stay inside. The step closes with a written sizing record and a scope document agreed before design starts.
Decide architecture and prerequisites
The team fixes the Kubernetes version within N-1 or N-2 of the supported range, the Istio release within the latest release plus two prior versions, or the basic ingress-nginx option where Istio cannot be used. It also settles Helm 3.17.0 or newer, the Redis 7.4.x approach, the MariaDB version from the supported list, the storage type and the identity method. The closing artifact is an architecture decision record that your security and platform owners sign off.
Build the platform layers
DeployOpen and your platform engineers build the Kubernetes cluster, Istio or the chosen ingress, the Redis deployment through the littlered operator or a custom setup, the MariaDB InnoDB database with the agreed Galera or single-node design, and the distributed file or object storage. Each layer is checked against the requirements before the next one is built. The output is a platform readiness report with version records and connectivity tests.
Deploy and configure OX App Suite
DeployOpen installs the OX App Suite v8 Helm charts with environment-specific values, sets branding and core configuration, and connects the chosen identity method for single sign-on. Configuration is kept in version-controlled values so it can be reproduced. The step closes when the deployment runs in the target environment and the configuration baseline is recorded.
Hand off mail and data migration
Migration work starts only after the platform is stable. The migration plan covers source mailboxes, calendars, contacts and attachments, coexistence and cutover approach. Your team validates the source data and migration tooling, and DeployOpen records the agreed migration inputs. The output is a signed migration hand-off document listing the source systems, data scope and cutover owners.
Test and go live
Functional, integration, performance and failover tests run against the agreed acceptance criteria, including a test of the high availability behavior your design depends on. Go-live follows a rollback plan and a cutover checklist approved by your team. The output is a test report with open defects tracked and a go-live record.
Handover and operating documentation
Your operations team receives runbooks for upgrades, backups, restores, monitoring and incident response, along with the values files, architecture decisions and access model. Knowledge transfer sessions confirm your staff can operate the platform. The step closes with a handover acceptance record and a list of any retained support arrangements.
What teams keep in-house and what they outsource
This table compares each work part of an OX App Suite v8 deployment against who usually owns it, the skills the internal owner needs, and where a partner's experience usually shortens the schedule.
| Work part | Usually owned by | Skills the internal owner needs | Where a partner usually shortens the schedule |
|---|---|---|---|
| Kubernetes and Istio platform | Platform engineering team | Kubernetes administration, Helm 3.17.0 or newer, Istio operation, ingress and TLS, cluster DNS | Confirming supported Kubernetes and Istio version pairs and avoiding rework on ingress design |
| Redis and MariaDB operations | Database and platform team | Redis 7.4.x operator management, MariaDB InnoDB administration, Galera cluster operation, backup and restore | Choosing Redis operator or unmanaged setup and sizing Galera topology against the supported MariaDB versions |
| Storage design | Infrastructure or storage team | Distributed file system or object storage design, capacity planning, access and backup policy | Matching NFS or object storage to mailbox counts and Drive attachment volumes before purchase |
| OX App Suite configuration | Messaging or collaboration team with platform support | Helm values per environment, middleware settings, release notes review, branding and module setup | Mapping licensed modules and feature limits to the chosen configuration before build starts |
| Identity integration | Identity and access team | OpenID Connect or SAML administration, directory design, provisioning of users and contexts, session policy | Sequencing identity cutover with mail client sign-in and testing autologin rules end to end |
| Mail migration | Messaging team with a migration partner | Mailbox export and import tooling, coexistence routing, cutover communication, user support | Planning coexistence, pilot waves and rollback steps from earlier migrations |
| Security review | Security team with an external tester | Hardening baselines, network policy design, patch cadence within the support window, evidence collection | Running configuration review against the hardening scope and preparing evidence for assessors |
| Run operations | Operations team | Monitoring, upgrade testing with Helm charts, backup restore tests, on-call and incident handling | Writing runbooks, setting upgrade test routines and staying inside the release support window |
What usually goes wrong and how to prevent it
Most Open-Xchange delays come from decisions that were deferred rather than from the software itself. Check each item below during scoping, before the design is signed off.
Prerequisites found late
OX App Suite v8 is delivered as Helm charts, and Helm 3.17.0 or newer is required. Kubernetes versions must sit within the N-1 and N-2 range, and Istio must match the supported release window unless you use the basic ingress-nginx option. Confirm the cluster, Helm and service mesh versions against the requirements page before the plan is priced.
Redis operator chosen after deployment
Redis 7.4.x handles caching and session storage. The default deployment uses the littlered operator, while unmanaged or custom Redis setups are also configurable. Choosing between them after the cluster is running forces rework of chart values, secrets and failover testing, so settle the operator model in the design phase.
Storage sized without mailbox growth
OX Drive files and PIM attachments must live on a distributed file system, either NFS for small to mid-size deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Size the volume against projected mailbox counts and growth over the planned life, not against today's migrated data, and ask the vendor to confirm the capacity model in writing.
MariaDB version outside the support list
The primary data store is MariaDB with InnoDB, and the supported lines are 10.6.x, 10.11.x, 11.4.x and 11.8.x, with Galera Cluster also supported. A distribution package or an older image may carry a version that is not on this list. Pin the MariaDB line in the build specification and verify it against the current requirements before installation.
Separately licensed modules found late
The Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Features discovered after the architecture is fixed can change the cost and the integration plan. Ask Open-Xchange to list every module in the target design and its license terms before the scope is agreed.
Go-live on an unsupported release
A standard release is supported for 12 weeks, ending with the availability of the third following release, and LTS releases run until the next LTS plus six months. A go-live date that lands on a release already outside its window creates an immediate upgrade obligation. Check the support commitment table against the planned cutover date and the chosen release channel.
Identity mapping gaps
Single sign-on through OpenID Connect or SAML depends on attributes that match user and context records in OX App Suite. Missing or inconsistent identifiers, such as mismatched usernames or absent mail attributes, cause login failures or duplicate accounts after cutover. Map each directory attribute to its OX counterpart and test provisioning with a sample of real account types before go-live.
How the work changes by starting point
Your cluster already exists and your team runs workloads on it, so the work starts at the application layer. The key question is whether the cluster meets the OX App Suite v8 requirements before any chart is installed.
- Prerequisites: Confirm the Kubernetes version falls within the N-1 or N-2 range the requirements allow for v8.
- Istio: Check whether Istio is installed and which release, because v8 requires it. The basic ingress-nginx option applies only where Istio cannot be used.
- Tooling: Confirm Helm 3.17.0 or newer is available in your deployment pipeline.
- Effort drivers: Chart values per environment, the Redis and MariaDB decisions, and a first install in a non-production namespace.
- Sign-off: Agree the upgrade path for the cluster alongside the application. See the Helm deployment topic for depth.
The cluster does not exist yet, so platform decisions come before any OX work. Schedule and cost shift toward infrastructure, and the cluster design determines what the application can use.
- Distribution and version: Choose a Kubernetes distribution and version inside the supported window, with an upgrade plan that keeps the cluster in that window.
- Istio: Install Istio as part of the base platform and agree which supported release line you will run.
- Storage: Select storage classes and the distributed file system or object storage for Drive files and attachments. NFS suits small to mid-size deployments and object storage suits larger ones.
- Effort drivers: Cluster build, identity integration and hardening of the base platform, all completed before the application install.
- Sign-off: Platform acceptance tests on the cluster before OX is deployed. See the Kubernetes and Helm deployment topic and the security hardening topic for depth.
Multi-tenant rollouts add tenancy design, provisioning and per-tenant operations on top of the base platform. Open-Xchange positions v8 for hosting providers and telcos, but the tenancy model must fit your own billing and support model.
- Tenancy model: Define how contexts, users and brands map to tenants, and confirm with the vendor how white-label features apply to each.
- Capacity: Size the Redis, MariaDB and storage tiers for the combined mailbox count across all tenants, not one customer at a time.
- Identity: Plan SSO and provisioning per tenant from each tenant's directory.
- Licensing: Confirm with the vendor which modules are covered by your license agreement, since some features may carry separate fees.
- Sign-off: Tenant isolation tests, onboarding and off-boarding runbooks, and support tiers agreed in writing. See the high availability topic for depth.
Restricted networks change how software reaches the cluster. Container images, Helm charts and updates must move through a controlled transfer path, and every dependency must be known before installation.
- Inventory: List every image, chart and package the deployment pulls, including Redis, MariaDB and Istio components, and confirm the mirror path with the vendor.
- Updates: Plan how each release enters the network within the support window, since the release cadence sets how often that path is used.
- Dependencies: Confirm the Redis operator choice and any external registries work without internet access.
- Effort drivers: Transfer procedures, offline testing and the evidence your security team needs for each import.
- Sign-off: An offline install test and documented transfer records. See the security hardening topic for network policy depth.
A migration adds data movement, coexistence and cutover planning alongside the platform build. The platform can be ready while mailboxes still sit on the old system, so the two tracks must be scheduled together.
- Source assessment: Inventory the source platform, mailbox counts, calendar and contact data, and folder structure, then agree which data moves.
- Coexistence: Plan coexistence and cutover windows with the mail team, including how mail routing changes on each cutover date.
- Capacity: Size database and storage tiers for the migrated volume, using the database and storage design topic.
- Effort drivers: Data mapping, migration rehearsals and user communication.
- Sign-off: Rehearsal results, a documented rollback decision point and approval from the mail owners. See the Open-Xchange migration topic for depth.
What you need to provide before work starts
The written scope for an Open-Xchange deployment depends on a short list of answers from your team. Until these are settled, no fixed price or timeline is meaningful, so gather them before the first scoping call. Start with the target cluster: either access to an existing Kubernetes cluster that meets the supported version window, or a target design that describes node pools, storage classes and network boundaries. Record whether you will run Istio, which the v8 requirements call for, or whether an ingress-nginx option is acceptable for your environment.
Confirm ownership of DNS and TLS before design starts. Someone must control the zone records for the mail and web hostnames, issue or approve the certificates, and decide how they are renewed and stored. Also name who provides access to the storage platform (NFS or an S3-compatible service for OX Drive files and attachments) and to the MariaDB and Redis platforms, including whether Redis will be the operator-managed default or a custom setup you already run. Expect the database and storage answers to drive much of the sizing work.
Give a mailbox and user count, split by tenant or context if you host several organizations, plus expected growth over the next budget cycle. Add your identity provider details: the protocol you intend to use (OpenID Connect or SAML), the issuer or metadata location, and who administers it. Then name accountable owners for mail, identity and platform operations, and agree on the change windows in which cluster and mail changes may happen. Finally, have legal or procurement review the license agreement, including any modules that may carry separate fees or custom packaging limits.
Frequently asked questions
What drives the cost and timeline of an OX App Suite implementation?
Scope drives both cost and duration, so no fixed figure is given without a written scope. The main drivers are mailbox count, storage volume, Kubernetes and Istio readiness, MariaDB and Redis choices, the mail backend, identity integration and migration. Storage choice matters: NFS suits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING suits larger ones. Ask for a quote that separates one-time work (design, build, migration, testing, handover) from recurring costs (infrastructure, separately licensed modules, operating staff).
Can our own team deploy OX App Suite without a partner?
Yes, a capable internal team can deploy OX App Suite v8 without a partner, because the official Helm charts and the public code are available. The team must cover Kubernetes operations, Istio or the ingress-nginx option, MariaDB with InnoDB, Redis, distributed storage, identity integration and mail migration. Assign a named owner for each role, keep a test environment and allow time for release testing before each rollout. Confirm skills and capacity against the written scope before committing.
Is OX Cloud an alternative to self-hosting OX App Suite?
OX Cloud is Open-Xchange's managed service and an alternative to the self-hosted deployment described here. OX App Suite can run on premises, in a public cloud or as OX Cloud, so the choice depends on where data must reside, who operates the platform and how much control your team needs. Self-hosting in infrastructure you control means your team or a partner runs Kubernetes, databases, storage and upgrades. Compare both options against your data residency rules and staffing before choosing.
Which Kubernetes and Istio versions does OX App Suite v8 require?
OX App Suite v8 supports Kubernetes N-1 and N-2 and requires Istio, with support for the latest Istio release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option is available. The platform is delivered as Helm charts and requires Helm 3.17.0 or newer. Confirm the exact compatibility matrix in the requirements and operations documentation for the release you plan to deploy before selecting cluster versions.
Do the AGPL code mirrors remove OX App Suite license fees?
Not automatically. Open-Xchange publishes mirrors of the App Suite UI and middleware code on GitHub under AGPL-3.0, but the Operations Guide states that some modules or features may carry custom packaging, limitations or separate fees set in the license agreement. Ask the vendor which modules your deployment would use, and get any fees in writing. Include this license review in your cost of ownership plan.
What does running OX App Suite look like after go-live?
After go-live, the platform needs patching, upgrades, backups and monitoring within the support window. 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 (FCS 2026-03-18) is the current LTS. Plan staff for release testing, Helm chart upgrades and incident response, or agree a retainer for ongoing support.
How DeployOpen scopes, delivers and hands over
DeployOpen plans, builds and documents OX App Suite v8 inside infrastructure you control, starting from a written scope that names the cluster, mail backend, identity and storage decisions before any build begins. Engagements are fixed-scope, so the cost and effort follow from what the scope agrees.
How we scope
- The written scope lists the Kubernetes, Istio, Redis, MariaDB and storage components each deployment needs.
- We confirm the Helm 3.17.0 or newer tooling and the Kubernetes and Istio versions your cluster will run.
- Storage choice between NFS and object storage is recorded, with mailbox and file volumes as inputs.
How we build
- Cluster prerequisites, Redis and MariaDB with InnoDB are deployed and tested against the chosen versions.
- Identity is wired through OpenID Connect or SAML, with user and context provisioning designed alongside it.
- Mail backend, migration steps and Helm values per environment are built and checked in a non-production setup.
How we hand over
- Deliverables include architecture documentation, configuration records, runbooks and test results for each component.
- Upgrade and rollback steps are documented against the release channel and support window you select.
- Your operators are walked through daily checks, backups and the verification steps used before each rollout.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support covers keeping the platform inside the Open-Xchange support window as new releases ship.
- Changes to scope, such as added modules or licensing needs, are agreed in writing before work starts.
