What running OX App Suite costs and who decides
Running OX App Suite is mostly a recurring cost, and the license agreement is the largest variable in it. The open-source code is only one input. Open-Xchange publishes mirrors of the App Suite UI (appsuite-frontend) and middleware (appsuite-middleware) under the AGPL-3.0 license, but the operating cost sits in the commercial software subscription, any separately licensed modules, the Kubernetes cluster, Istio, Redis, MariaDB, distributed storage for Drive files and attachments, support windows, and the staff who operate them. Ask which of these the quote covers and which is left to you.
Teams usually start a cost of ownership study for one of four reasons: choosing between on-premises, public cloud and the managed OX Cloud service; a renewal that changes the commercial terms; a move from another mail platform; or a board request for a total cost comparison over several years. Each trigger changes the model. A managed service shifts infrastructure and operations cost to the provider, while on-premises or public cloud deployments keep those costs on your side of the ledger.
Most organizations build the model with a mix of internal finance and platform staff and an implementation partner. Internal teams own the assumptions about headcount, cloud accounts, data center costs and the existing mail spend. A partner can scope the Kubernetes, storage and database components and estimate effort. Neither side can finish the model alone until the written license agreement is in hand.
No price list is published for OX App Suite, and this page does not give figures. Before modeling, request the written license agreement and confirm the module set, user or mailbox metric, term length, support tier and any custom packaging or separate fees the Operations Guide says may apply. Then confirm the chosen deployment model, because the infrastructure and staffing lines differ substantially between on-premises, public cloud and OX Cloud.
What a cost of ownership study covers
The study breaks the total cost of ownership into six parts, each tied to a decision or a document you can check against your own plans.
Inventory of editions and modules
List every edition, module and feature the organization intends to use, including email, calendar, Documents, Drive, Tasks, SSO and any white-label work. Each item becomes a cost line, because modules that Open-Xchange packages separately can carry their own fees. Record planned mailbox and user counts per group so the model can scale.
License review against the agreement
Compare the inventory with the license agreement you hold with Open-Xchange. The Operations Guide notes that the right to use certain modules or features may depend on custom packaging, limitations or separate fees set in that agreement. Confirm which items are covered, which carry fees, and how the AGPL-3.0 code mirrors relate to the commercial subscription.
Infrastructure model for the platform
Model the Kubernetes cluster, Istio, Redis, MariaDB with InnoDB, and the distributed file or object storage for Drive files and attachments. Check the supported version for each component, including Kubernetes N-1 and N-2 and Redis 7.4.x, and note whether the ingress-nginx option applies where Istio cannot be used. Each component adds hardware or managed service cost.
Operating model and support window
Estimate the staff needed to run the platform, covering platform engineering, database and storage administration and mail operations, and decide which work stays in-house. Map upgrade effort to the support window: standard releases are supported for 12 weeks, and LTS releases until the next LTS plus six months. Staff time and upgrade windows recur every year.
Comparison of deployment options
Compare on-premises deployment, public cloud and the managed OX Cloud service against the same inventory and infrastructure model. Each option shifts cost between licenses, infrastructure, data residency controls and staff time. Ask Open-Xchange and the reseller which option your license terms cover and what the managed service includes before comparing totals.
Deliverables for finance and procurement
The study ends with three deliverables: a cost model with every assumption written down, a list of questions for Open-Xchange and the reseller or sales contact, and a recurring cost schedule the finance team can maintain. Each assumption names its source, so changes in user counts, release choices or licensing can be tested without rebuilding the model.
What drives cost and effort
This table lists the factors that change what an OX App Suite deployment costs to build and run, why each one moves the total, and what usually reduces it.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Mailbox count and growth | Mailbox count sets the size of the Kubernetes capacity, MariaDB sizing, Redis memory and the distributed storage that holds mail attachments and OX Drive files. Growth over the contract term means the platform must be sized for a trajectory, not only the first day. | Size from a named mailbox forecast with growth assumptions written into the scope. Ask the vendor or partner how capacity scales and which components need planned expansion. |
| Modules and features in use | The 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. Each added module can add licensing cost, configuration work and test cases. | List the modules required on day one and confirm in the license agreement which ones are included, separately licensed or limited. Defer optional features to a later phase. |
| Deployment model | On premises means you pay for and operate the cluster, storage, backups and patching. A public cloud deployment shifts infrastructure cost to your cloud bill. OX Cloud moves operations to the managed service, with its own commercial terms. | Compare total run cost for each model with the same mailbox count and availability target. Ask which operational tasks stay with your team under each option. |
| Storage type | NFS suits small to mid-size deployments. Object storage such as AWS S3, Ceph RadosGW or Scality RING is listed for larger ones. Object storage adds platform components to operate, while NFS adds a single point to size and back up carefully. | Choose the storage type from the expected file and attachment volume, and reuse storage your organization already runs and supports where the requirements allow it. |
| Number of environments | Each environment (test, staging, production, disaster recovery) repeats the Kubernetes, Istio, Redis, MariaDB and storage footprint, and each needs its own Helm values and upgrade rehearsal. | Keep non-production environments smaller and automate Helm value management across them. Confirm which environments the quote includes. |
| Service provider or white-label use | Hosting providers, telcos and ISPs running OX App Suite as a white-label service take on tenant provisioning, branding, multi-customer operations and support obligations. Open-Xchange positions the product for this use at large mailbox counts. | Define tenant isolation, branding scope and support boundaries in writing before build. Confirm the commercial terms for resale and white-labeling with Open-Xchange. |
| High availability requirements | Multiple replicas, MariaDB Galera, Redis and replicated distributed storage each add infrastructure and test effort. Failover testing before go-live is an additional activity. | Agree a recovery objective with the business and build only the redundancy it needs. Schedule failover tests as part of the delivery plan. |
| Compliance evidence needs | Assessors expect evidence of configuration, access control, patch cadence, backups and change records. Producing this evidence adds documentation, logging and review work. DeployOpen prepares evidence, while independent auditors issue any attestation. | Decide early which controls must be evidenced and build logging, backup records and change history into the platform rather than collecting them later. |
| Release train cadence | Standard releases are supported for 12 weeks, and LTS releases are supported until the next LTS release plus six months. Taking every standard release means more chart upgrades and test cycles per year than an LTS-only plan. | Choose between the standard release line and the LTS line based on your test capacity. Keep a rehearsed upgrade process so each release costs less to adopt, and confirm current release dates with Open-Xchange. |
Phases of a cost of ownership study
The sequence turns an OX App Suite decision into a cost model with named assumptions, owners and review dates that your team can maintain after the study ends.
Confirm requirements and name the owners
Map the mailbox population, file storage needs, identity sources and the business owners for mail, calendar, contacts and Drive. Your team and DeployOpen agree who supplies each input. The step closes with a signed requirements list that every later figure traces back to.
Review licenses and editions against the agreement
Read the commercial agreement with Open-Xchange alongside the AGPL-3.0 code mirrors on GitHub, and list which modules, features and support terms are included or separately charged. The output is a license register that flags any module the Operations Guide says may carry custom packaging or separate fees.
Size infrastructure against the v8 prerequisites
Translate the requirements into a Kubernetes cluster, Istio or ingress-nginx choice, Redis 7.4.x, a supported MariaDB version with InnoDB, and a distributed file or object store for Drive files and attachments. Confirm the Helm 3.17.0 or newer baseline. The output is a bill of materials with cloud or data center line items your team can price.
Estimate the operating model and staffing
Describe who runs upgrades, backups, on-call and identity administration, and how often the support commitment requires you to move to a supported release. Estimate the staff hours for each role in your own environment and separate one-time build work from recurring operations. The step closes when each recurring role has a named owner.
Compare options and obtain sign-off
Model the realistic alternatives, such as a managed OX Cloud service, an on-premises build, or a different mail platform, using the same assumptions for each. Present the comparison side by side with its sensitivities. Sign-off comes from the budget holder and the platform owner, who accept the assumptions in writing.
Hand over the model with assumptions and review dates
Deliver the spreadsheet or model, the assumptions register, the source for each figure and the quote basis. Set review dates tied to support windows and license renewal, and agree who updates the model when the release train or your mailbox count changes. The handover is complete when your team can rerun the model without DeployOpen.
Recurring costs after go-live
This table lists the recurring cost lines for an OX App Suite v8 deployment, who pays for each one and what drives it up, so you can check a quote against your own scope.
| Cost line | Who pays | One-time or recurring | What drives it |
|---|---|---|---|
| Subscription under the agreement | Organization, to Open-Xchange | Recurring, set by the agreement | Licensed scope and included support terms. Confirm the basis and renewal terms in writing. |
| Separately licensed modules or features | Organization, to Open-Xchange | Recurring where the agreement sets a fee | Each module the license may package or price separately. Confirm every module before go-live. |
| Kubernetes cluster and node capacity | Cloud or hosting provider, or the organization | Recurring | Node count and size for mailbox load, plus spare capacity for rolling upgrades. |
| Istio and Redis operation | Organization, or hosting provider if managed | Recurring operating effort, plus any hosted Redis | Istio versions within the supported range and Redis 7.4.x. Each upgrade needs compatibility testing. |
| MariaDB with Galera Cluster or a managed alternative | Organization, or a managed database provider | Recurring compute, storage and operation | Galera node count, backup storage and whether a managed service replaces self-operation. Confirm supported MariaDB versions. |
| NFS or object storage growth | Cloud provider or organization | Recurring, grows with stored files and attachments | Volume of OX Drive files and PIM attachments, retention and replication. NFS suits smaller deployments, object storage larger ones. |
| Backups and disaster recovery capacity | Cloud provider or organization | Recurring storage and transfer, plus one-time restore testing | Retention period, number of copies and how often restores are tested end to end. |
| Support contracts and upgrade testing | Organization, to Open-Xchange and to the staff or partner running tests | Recurring, tied to the support window | Standard releases are supported for 12 weeks. LTS lines run to the next LTS plus six months. Helm chart tests must fit inside that window. |
| Internal staff time | Organization | Recurring | Platform, mail and security operations, monitoring, on-call and change control. Staffing depends on the operating model you choose. |
What goes wrong in cost models
Cost models for OX App Suite often miss the same five items. Each card names the gap and the check that closes it before you sign off on a budget.
Treating the AGPL mirrors as full cost
Open-Xchange publishes the App Suite UI and middleware mirrors on GitHub under AGPL-3.0. The Operations Guide says certain modules or features may carry custom packaging, limits or separate fees set in the license agreement. Before modeling, request the agreement's module list, feature entitlements and white-label terms in writing.
Underestimating storage growth
OX Drive files and PIM attachments must sit 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. Storage grows with every attachment and shared file, so model usage per mailbox and per Drive user, add the storage platform's replication overhead, and confirm who pays for expansion.
Missing the support window
Open-Xchange states that a standard release is supported for 12 weeks, ending when the third following release is available. An LTS release is supported until the next LTS plus six months. v8.35 is discontinued and v8.47 is the current LTS. Budget for forced upgrades, Helm chart testing and change windows whenever a running version leaves support.
Assuming one cluster and one database
A single-cluster model leaves no failure domain to absorb a node, database or site outage. MariaDB Galera is supported, and Redis deploys by default through the littlered operator. Add the extra Galera nodes, Redis replicas, second-site infrastructure and the test time needed to prove failover before go-live.
Omitting operating staff
Running v8 requires people who know Kubernetes, Istio, Galera and mail operations, including queue handling, delivery troubleshooting, Helm releases and database recovery. Many models price software and infrastructure but leave out these salaries or retainer hours. Ask who holds each skill, how on-call coverage works, and whether training or a support retainer is included.
How the model changes by deployment situation
A new on-premises deployment starts with the full set of platform lines because nothing is reused. The model is built from the prerequisites up, and most of the cost sits in infrastructure and build effort rather than in migration.
- Kubernetes cluster: a new cluster, or capacity added to an existing one, with its own operating effort.
- Istio and ingress: OX App Suite v8 requires Istio. Confirm whether a basic ingress-nginx option is acceptable for your environment, since that changes the build.
- Redis, MariaDB and storage: Redis 7.4.x, a MariaDB InnoDB data store and a distributed file or object store all appear as new lines.
- Helm delivery: effort for chart values per environment and a repeatable upgrade test.
Ask Open-Xchange which MariaDB and Redis topologies it expects for your mailbox count, and which module and license terms apply to your planned features.
A migration keeps the platform lines of a new build but adds lines for moving data and running two systems during cutover. The old platform cost phases out only after cutover is verified.
- Migration tooling and effort: mailbox, calendar and contact transfer, plus validation of migrated items.
- Coexistence period: both platforms run in parallel, so license, infrastructure and staff time for the old system continue until retirement.
- Retirement lines disappear: old server licenses, hardware and support contracts stop only at a dated decommission.
- Client changes: user retraining and client reconfiguration appear as a one-time cost.
Ask Open-Xchange which source platforms and versions its migration path covers, and whether migration work is quoted separately from the platform subscription.
An organization already running Kubernetes and Istio removes the largest infrastructure lines, so the model shifts toward application, data and operations effort.
- Cluster lines shrink: existing clusters may host OX App Suite, but capacity, node pools and version alignment still need checking.
- Version checks: confirm the cluster's Kubernetes version sits within the N-1 or N-2 window and the Istio release is one OX supports.
- Shared services: if Redis or a database operator already exists, the model may drop a line, but only after OX confirms it is supported in your setup.
- Mesh policy: existing mesh policies may need changes for OX traffic, which adds review effort.
Ask Open-Xchange whether it supports your existing Istio configuration and which shared services it accepts without modification.
Choosing the managed OX Cloud service replaces most infrastructure and operations lines with a service relationship. Self-hosting keeps those lines and adds control over data location and release timing.
- Managed service: the service fee replaces infrastructure, database, storage and most operations lines. Confirm what it includes and what you still operate.
- Self-hosting: infrastructure, storage, backups, patching and on-call remain your cost, along with the platform subscription.
- Data location and control: if residency or sovereignty rules apply, self-hosting may be required, and that changes the model.
- Release timing: under self-hosting you control upgrade timing within the support window. Confirm how managed releases are scheduled.
Ask Open-Xchange what the managed service covers in writing, its termination terms, and how data would move if you later switch to self-hosting.
A hosting provider or telco offering OX App Suite to its own customers changes the model from one organization's cost to a per-tenant and multi-tenant cost. Open-Xchange positions the platform for white-label service delivery at scale.
- White-label work: branding and customization effort is added and may recur with each product change.
- Scale lines: storage, database and cluster capacity grow with mailbox counts, and the model needs to show that growth.
- Licensing per customer: confirm how the commercial subscription and any separately licensed modules are counted across tenants.
- Support obligations: customer-facing support and SLA commitments add staff lines.
Ask Open-Xchange how service-provider licensing counts tenants and mailboxes, and which white-label rights are included in the subscription.
An air-gapped or restricted network adds lines for offline delivery and for the controls that replace internet-connected services. The model changes most in delivery, updates and evidence.
- Offline artifacts: container images, Helm charts and dependencies must be mirrored into the network, which adds build and transfer effort for each release.
- Update cadence: each upgrade requires a repeat of the mirror and test cycle, so recurring effort rises.
- Identity and licensing checks: confirm whether license validation or support access needs outbound connectivity.
- Evidence and access controls: additional logging and approval records for each change appear as operating effort.
Ask Open-Xchange which components need outbound connectivity, how licenses are validated offline, and how it supplies images and charts to a restricted environment.
What the client needs to provide
The cost study depends on a short list of inputs from your side. Gather these before the first working session, because the model cannot produce a comparison without them. The most important item is the license terms in writing. Without the current license agreement or quote, and without the written terms for any module you plan to use, the study cannot be finished. Open-Xchange's Operations Guide notes that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so a price read from a website or a sales conversation is not enough.
Provide mailbox and user counts for today and for the planned horizon, with the growth assumption behind each number. Separate active mailboxes from shared, resource and archived accounts, since they often sit in different license or storage categories. Also list the features and modules you expect to use, such as email and calendar, Documents, Drive and Tasks, and any separately licensed capability you have already asked about. Each module you name changes the subscription line and the storage sizing.
State your deployment preference and any constraints from existing cloud accounts or data centers, including whether the platform must run in an air-gapped network. Record the current cost of the mail platform being replaced: licenses, hosting, storage, backup, support contracts and the internal hours spent operating it. Name one owner each for licensing, finance and platform operations, and confirm the target release channel: the standard release line or the LTS line. That choice sets the support window and the upgrade effort, so it belongs in the model from the start.
Questions buyers ask about OX App Suite costs
Is OX App Suite free to run because the code is AGPL licensed?
Not necessarily. Open-Xchange publishes mirrors of the App Suite UI (appsuite-frontend) and middleware (appsuite-middleware) code on GitHub under the AGPL-3.0 license, and that license governs your rights to that code. It does not decide whether you receive support, release access, packaged modules or hosting services, which depend on your license agreement and subscription. Even without a software subscription, Kubernetes, Istio, Redis, MariaDB, distributed storage and staff time remain costs. Ask Open-Xchange to confirm in writing how the AGPL terms apply to your intended use.
What does the commercial subscription cover, and how do I get a quote?
The subscription covers what your agreement with Open-Xchange or its reseller states, so start by asking for that scope in writing. Request a list of included products, the release line and support commitment that applies, the basis for counting users or mailboxes, the hosting model (on premises, public cloud or the managed OX Cloud service) and the renewal terms. A quote follows from that written scope, so compare quotes only when each one covers the same products, support and hosting model.
Which OX App Suite modules might need separate license fees?
The 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. The suite includes email and calendar, Documents, Drive and Tasks, but you should still confirm each module and feature your rollout will use. Ask for a line-item list in the license agreement, and confirm whether single sign-on, white-label branding or any integration feature carries separate terms, and whether any fee changes with user counts.
How much effort does a cost model take, and what drives it?
The effort depends on how many inputs you already hold: mailbox and storage counts, identity sources, availability targets, and the layout of Kubernetes, Istio, Redis, MariaDB and file or object storage. Drivers that raise effort include high availability with MariaDB Galera, large object storage, custom single sign-on, and coexistence during migration. No effort figure is supplied here, so ask for the work as line items so that each driver is estimated and scheduled on its own.
Can our own team build the cost model without an outside partner?
Yes, a capable platform team can build the model if it has the vendor's written scope, its own infrastructure prices and estimates of operating staff time. Split the model into one-time rows, such as design, migration and initial build, and recurring rows, such as subscription, infrastructure, upgrades and on-call. Validate the vendor assumptions with Open-Xchange before relying on them. An implementation partner such as DeployOpen can scope the work under a written, fixed-scope agreement that your team can compare with its own model.
How does the support window change recurring costs over time?
Each standard release is supported for 12 weeks, ending with the availability of the third following release, and an LTS release is supported until the next LTS release plus six months. Staying inside the window means upgrading on that cadence, so the recurring cost is the staff time and test environments needed for regular upgrades, plus any subscription terms tied to your release line. Choosing LTS reduces how often you make major changes but still requires a patch and upgrade routine. Ask Open-Xchange which release line your subscription covers.
How DeployOpen scopes and supports this work
DeployOpen models the running cost of OX App Suite in your own infrastructure, separating the open-source code from the commercial subscription, separately licensed modules, Kubernetes and storage, and operating staff. Each estimate starts from a written scope that you can check against your own environment.
How we scope
- The written scope lists which OX App Suite components, editions and licensed modules your cost model includes, and which it leaves out.
- We confirm with Open-Xchange which modules or features may carry custom packaging or separate fees under your license agreement.
- Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any cost modeling work starts.
How we build
- We build a cost model that maps each Kubernetes, Istio, Redis, MariaDB and distributed storage requirement to the infrastructure line it adds.
- We record which costs recur each year, such as subscriptions and storage growth, and which are one-time, such as design and migration effort.
- We test the model against your planned mailbox counts and release channel, then document the assumptions behind each figure.
How we hand over
- You receive a documented cost model with assumptions, cost drivers and the questions to put to Open-Xchange in a quote request.
- The handover includes a checklist that compares the open-source code mirrors on GitHub with the commercial software subscription and any separate module fees.
- Your team walks through the model with us so that operating staff know which cost lines they own after go-live.
How we support
- Ongoing cost reviews, upgrade planning within the support window and periodic re-estimates are available as a retainer.
- When the release channel or the LTS line changes, we update the model so that recurring support and infrastructure costs stay current.
- Support covers the infrastructure you control, and we do not issue audit reports, attestations or certifications for the platform.
