How OX App Suite fits into openDesk as the groupware component
OX App Suite is one of the components bundled in openDesk, and it is deployed through the openDesk Helmfile and Helm automation as part of that bundle. No separately built connector is involved. A public administration or regulated organization that selects openDesk for its digital workplace usually needs mail and calendar from the first day of operation, so the mail and calendar decision is largely a decision about the openDesk release, its configuration and the Kubernetes platform it runs on. The groupware role is filled by OX App Suite inside that release, alongside chat, files, wiki and the web office.
OX App Suite v8 runs on Kubernetes and is delivered as Helm charts that reference container images. OX requires Helm 3.17.0 or newer. openDesk, in turn, requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. The integration method is therefore the bundled deployment, not a custom plugin or an add-on that your team builds on top of openDesk. Your platform team should check that the cluster, ingress and Helm versions satisfy both sets of requirements at the same time, and that the ingress choice works with OX, which documents Istio and a basic ingress-nginx option.
The supplied material does not document a separate OX-to-openDesk connector, so the exact configuration hooks are not described here. Before planning the build, confirm them in the openDesk deployment documentation for the release you intend to deploy. Ask which values or Helmfile settings control the OX component, how OX resolves user identity through the openDesk identity stack, and which storage backend holds OX Drive files and PIM attachments. OX requires a distributed file system for that data, either NFS for small to mid-size deployments or object storage for larger ones. openDesk Enterprise Edition lists OX S3 storage among its Enterprise-only features, so confirm which storage option your edition covers.
Three checks belong in the plan now. First, confirm which OX App Suite version the chosen openDesk release bundles and whether that version is covered by the Open-Xchange support commitment for your planned operating period. Second, confirm the database and cache services that OX expects in your environment, because openDesk production guidance lists external services that must be provided. Third, agree on an upgrade order before go-live. openDesk supports only the latest minor version, and in-place upgrades between majors are not guaranteed, so the OX version and the openDesk release must be upgraded together under a tested procedure.
What an openDesk cluster needs before OX App Suite can run
OX App Suite v8 and openDesk share one Kubernetes cluster, so the platform, the ingress and storage layer, and the data services both products depend on must be settled first. Confirm each item against the current product documentation before installation starts.
Kubernetes and deployment tooling
openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, with Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later for deployment. openDesk is tested on kubespray clusters, and it is not tested on OpenShift, so an OpenShift estate needs its own validation plan before OX App Suite is added. Confirm the cluster version, distribution, Helm and Helmfile versions with your platform team before the first deployment.
Ingress, certificates and volumes
openDesk needs an ingress controller, either haproxy-ingress or the deprecated Ingress nginx, plus cert-manager for TLS certificates and an RWO volume provisioner for ReadWriteOnce claims. The ingress layer also routes user traffic to the mail and calendar services, so the controller choice affects both products. Ask the platform team which storage class serves RWO claims and how certificates are issued and renewed in your environment.
Istio or basic ingress-nginx for OX
OX App Suite v8 requires Istio, and Open-Xchange supports the latest Istio release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option exists. OX also supports Kubernetes versions N-1 and N-2, so confirm that your cluster version falls inside that window before you choose the mesh. Decide early, because the choice shapes how traffic reaches OX components and what your platform team must operate.
Redis 7.4.x and MariaDB with InnoDB
OX App Suite v8 uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator, and you can configure an unmanaged or custom Redis instead. Its primary data store is MariaDB with the InnoDB engine, with supported lines 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Check that the MariaDB and Redis versions openDesk expects elsewhere in the stack can coexist with the OX lines you choose.
Distributed file system for PIM attachments
OX Drive files and PIM attachments must sit on a distributed file system. NFS suits small to mid-size deployments, while larger ones typically use object storage such as AWS S3, Ceph RadosGW or Scality RING. Confirm the choice against expected attachment volume, backup and restore method, and whether the object storage openDesk expects can also serve OX. Test latency and file locking behavior before go-live.
Production services and evaluation sizing
openDesk expects production-grade external services, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. The evaluation minimum of 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, with no ARM support yet, is for trying the stack and is not a production sizing. Ask for production sizing per component and plan each external service as a separately operated system.
What the openDesk deployment manages for OX App Suite and what stays with your team
The openDesk deployment automation handles much of the installation work for OX App Suite, but it does so as one component in a larger release, not as a standalone OX installer. The automation is Helmfile and Helm based and licensed under Apache-2.0. Each bundled component keeps its own license, so OX App Suite carries its own terms alongside components such as Nextcloud and Nubus under AGPL-3.0, OpenProject under GPL-3.0 and Collabora under MPL-2.0. OX App Suite is one of many components that the same release process updates. An OX change therefore reaches you through an openDesk release, and your upgrade planning should follow that release cadence.
Your team owns the Kubernetes cluster. The openDesk requirements call for a CNCF-certified cluster at v1.33 or later, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. You also choose the ingress controller, either haproxy-ingress or the deprecated ingress-nginx. Make that decision before the first deployment, because it determines how users reach OX and how certificates are issued. Confirm with the openDesk documentation that your chosen distribution is covered, since the requirements note that the deployment is tested on kubespray clusters and not on OpenShift.
External production services also stay with your team. For production, openDesk expects PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, all operated at production grade. For OX App Suite, the database, cache, mail relay and object storage paths matter most. Your team decides who operates each service, how it is patched, and how it is backed up. Storage sizing for mailboxes, attachments and files is also yours. The deployment does not size that capacity for you, so ask for the storage assumptions in writing and check them against your expected mailbox and file volumes.
Before go-live, read the exact values the openDesk release sets for OX rather than assuming them. Check image tags, replica counts, resource requests, database and Redis endpoints, session and file storage settings, and the backup hooks. Confirm whether the release uses Enterprise-only settings such as OX S3 storage, which the Enterprise Edition documentation lists as an Enterprise-only feature. Store the resulting values in your own configuration repository and review them again after every openDesk release. Ask the openDesk team or your implementation partner for a written list of the OX values the deployment sets and a list of what it expects your team to provide.
How to deploy OX App Suite inside an openDesk release, step by step
This sequence takes an openDesk deployment from cluster checks to a working OX App Suite mail and calendar service inside your own Kubernetes environment. Each step ends with a check you can record, so a failure is caught before the next layer depends on it. Confirm the exact release and component versions against the openDesk and OX documentation before you start.
Confirm cluster versions and tooling
Your platform team checks that the Kubernetes cluster is CNCF-certified and at v1.33 or later, and that cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later are installed. Confirm that the same toolchain also meets the OX App Suite v8 requirement of Helm 3.17.0 or newer. Check whether your cluster distribution is one openDesk tests against, since ZenDiS reports testing on kubespray clusters and not on OpenShift. Done when each tool reports a version that meets the documented minimum and a test volume claim binds successfully.
Choose the ingress path
Select the ingress controller openDesk will use, either haproxy-ingress or the deprecated Ingress nginx, and confirm it is the one the target release documents. OX App Suite v8 is designed around Istio, supporting the latest Istio release plus two prior versions, and offers a basic ingress-nginx option where Istio cannot be used. Decide which path your security team accepts, because it determines how routes, TLS and mail client endpoints are exposed. Record the decision with its reasons. Done when a test route through the chosen ingress returns a certificate issued by your cert-manager issuer.
Provision external production services and storage
Your infrastructure team provisions the services openDesk expects in production: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. For OX App Suite, choose a MariaDB version from the 10.6.x, 10.11.x, 11.4.x or 11.8.x lines using the InnoDB engine, and provide Redis 7.4.x. Attachments and Drive files need 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. Done when each endpoint accepts connections from the cluster network and a write and read test succeeds on the file store.
Configure identity federation with the external IdP
Follow the openDesk federation guide to connect your external identity provider, and map the claims and groups that identify each user to the accounts OX App Suite uses. OX App Suite supports single sign-on through OpenID Connect, and its middleware also documents SAML login, so confirm which protocol the target openDesk release wires to OX before you register client credentials. Sign in with one pilot account from each group that will need a mailbox. Done when a pilot user signs in through the openDesk portal and the OX session shows the expected name, address and group membership.
Select the release and run the openDesk deployment
Select the latest minor release that openDesk supports, because only the latest minor version is supported. Skipping several minor versions may require intermediate steps listed in the release management documentation, so read those before you upgrade an existing installation. At research time the newest listed release was v1.19.1, published 2026-10-06, so confirm what is current when you start. Set values for the external services, ingress and federation, then run the Helmfile deployment. Done when Helmfile reports every release as deployed and the openDesk login page responds through the ingress.
Verify OX pods, Redis and database connections
Check that the OX App Suite pods are running and ready, then confirm the middleware connects to Redis and to MariaDB. OX v8 deploys Redis by default through the littlered operator, so inspect the operator's pods and the connection settings, and review them carefully if you use an unmanaged or custom Redis. Scan the logs for database authentication errors and session storage errors, and confirm the schemas use the InnoDB engine. Done when all OX pods report ready, a Redis ping and a database query both succeed from a pod in the OX namespace, and the logs show no connection errors over the period you observe.
Test mail send, receive and calendar invitations
Create two test mailboxes, send mail between them, and send a message through the SMTP relay to an external address, then confirm delivery in both directions. Send a calendar invitation from one mailbox to the other and to an external address, accept it, and check that the event appears in each calendar with the correct time in each time zone. Confirm that ClamAV scanning and the TURN server are reachable if your release uses them in this path. Done when external messages arrive, invitations display correctly, and the results are recorded before users are onboarded. Repeat these checks after every upgrade.
How identity and single sign-on work between openDesk and OX App Suite
The first thing to settle is which protocol the openDesk release actually wires into OX App Suite. The two products document their identity features separately, and the documentation alone does not show how they connect in a given openDesk release. OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange also documents SAML login configuration for the middleware. openDesk uses Nubus for its portal and identity functions and documents federation with an external identity provider. Before planning any login work, the team should confirm, with ZenDiS or in the deployed configuration, whether OX receives its login through OIDC, through SAML, or through a path that openDesk manages itself.
Two documents are the reference points for that check. The openDesk federation document explains how Nubus relates to an external identity provider, including where authentication happens and which identities are passed on. The OX OIDC documentation describes how the App Suite login is configured to trust an OpenID Connect provider. Read them side by side. Ask which client registration, redirect addresses and token settings the openDesk deployment creates for OX, and whether those values are generated by the deployment or must be set by the operator. The OX SAML guide is written for the middleware in a 7.10.1 documentation path, so confirm whether its settings apply to the v8 release on Kubernetes before relying on them.
The team also needs to know where the login form lives and where the session ends. Confirm whether the user signs in at the external identity provider, at Nubus, or at the OX login page, and whether a single logout from the openDesk portal ends the OX session. Token lifetimes, refresh behavior and the handling of mobile and desktop clients that connect through OX interfaces are details that change the user experience. Record the answers in a login flow diagram that the operations team can test, rather than assuming that sign-in in one application carries over to the others.
Provisioning is the second open question. A user who signs in must also have a mailbox, calendar and contact store in OX App Suite, so the team must confirm how those accounts are created: at first login, through the openDesk deployment, or through a directory synchronization. Ask who removes an account when an employee leaves, how quickly that removal reaches OX, and what happens to mail and files owned by the account. openDesk lists GroupSync and an Admin Console among its Enterprise-only features. Confirm with ZenDiS whether either of them manages OX accounts, because that answer determines who owns the provisioning process.
Which data stores and identities map between openDesk and OX App Suite
This table maps the data stores and identity paths that OX App Suite uses inside an openDesk deployment, and what openDesk provides for each. Read the middle column as what openDesk supplies and the last column as what your team must confirm before go-live. The main takeaway is that the database, cache, file storage and mail relay are external services in openDesk production, so their versions and ownership need agreement early.
| Item | Where it lives | What the openDesk deployment provides | What the team must confirm |
|---|---|---|---|
| User identity and login | Nubus for portal and identity, with OX login configured against it | Identity and portal from Nubus. OX App Suite supports OpenID Connect login. | Which user attributes OX receives and how openDesk maps users to OX accounts |
| Sessions and caching | Redis 7.4.x, used by OX for caching and session storage | Expects an external Redis 7 service for production use | Redis 7.4.x is the OX requirement. Confirm the openDesk Redis version, and whether it is managed by littlered or custom. |
| Primary data store | MariaDB with InnoDB as the OX primary store | Expects an external MariaDB 10 service for production use | Confirm the exact minor version (10.6.x, 10.11.x, 11.4.x or 11.8.x) and whether Galera Cluster is used. |
| PIM attachments and Drive files | Distributed file system or object storage used by OX | Expects object storage in production. Enterprise adds OX S3 storage. | Confirm the backend (NFS or S3-compatible), capacity, and backup scope for attachments and files. |
| Mail transport | Outbound mail from OX to the SMTP relay | Expects an external SMTP relay service for production use | Confirm relay host, authentication, TLS settings and which sender domains OX may use. |
Which OX features are Enterprise-only in openDesk and what that changes
The openDesk Enterprise Edition keeps the same open-source core licenses as the community deployment, so the OX App Suite components you run remain under their upstream licenses. What changes is the surrounding package. Enterprise adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches. ZenDiS sells this edition as SaaS or for on-premises installation. For the mail and calendar part of the stack, the decision is therefore not whether OX App Suite is open source, but which of its features and fixes are reached through the Enterprise channel.
Among the openDesk Enterprise-only features, the item that touches OX App Suite directly is OX S3 storage and advanced full-text search. Both need a decision before build. If your storage design for OX Drive files and PIM attachments points to S3-compatible object storage, confirm whether the OX S3 storage path is available to you under the edition you buy, or whether you would run a different storage configuration. Likewise, if users expect deep search across mailbox content and attachments, confirm whether the standard search covers that requirement or whether advanced full-text search is needed. Write the answer into the design document so the storage and search tiers are chosen together.
ZenDiS recommends openDesk Enterprise Edition for production, and the reasons are the Enterprise-only registry, the license file and the support and patch commitments. For an OX-dependent deployment, the practical question is who delivers and tests OX patches, on what timeline, and through which channel. Ask ZenDiS for the written support scope that covers the OX components, the escalation path from second to third level, and whether security patches for OX arrive through the same SLA as other openDesk components. Confirm these points before procurement, because they determine how you plan maintenance windows and upgrades.
Open-Xchange states in its Operations Guide that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. This means an Enterprise subscription does not automatically settle the status of every OX capability. Confirm each feature you plan to use in the openDesk release you intend to run, since openDesk ships monthly minor releases and supports only the latest minor version, so availability can shift between releases. Request a feature list from ZenDiS and Open-Xchange that marks each item as included, separately packaged or separately priced, and attach it to your scope.
How to harden OX App Suite in openDesk without breaking the bundle
OX App Suite runs inside openDesk as a bundled component, so most hardening work touches values that the openDesk deployment also renders. The cards below cover the settings that matter most for mail and calendar. Any change to OX values can be overwritten or conflict with the bundle on upgrade, so record each change and test it against the next release.
Stay on a supported release
openDesk ships monthly minor releases, and only the latest minor version is supported, so running an older minor version leaves you without fixes. Read the release notes for OX App Suite changes before each upgrade, because in-place upgrades between majors are not guaranteed and skipping several minor versions may need intermediate steps. Confirm that your Kubernetes cluster meets the openDesk minimum of v1.33 before you schedule the upgrade window.
Control ingress and TLS certificates
openDesk uses haproxy-ingress or the deprecated Ingress nginx in front of its services, and cert-manager issues the certificates for the hostnames that serve OX App Suite. Decide who owns the certificate issuer and renewal process, and confirm that issuer settings and custom certificate values survive a Helmfile sync. Test a certificate renewal in a non-production release before you rely on it for users.
Restrict access to Redis and MariaDB
OX App Suite v8 uses Redis 7.4.x for caching and session storage and MariaDB with the InnoDB engine as its primary data store. openDesk expects production-grade Redis 7 and MariaDB 10 services from you, so limit network paths from OX workloads to these endpoints and keep credentials in Kubernetes secrets. Confirm that your Redis and MariaDB topology, including any Galera Cluster layout, still matches what the OX values expect.
Protect attachment and Drive storage
Mail attachments and OX Drive files sit on a distributed file system, either NFS for smaller deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Restrict access to the NFS export or bucket so only the OX workloads can reach it, enable encryption at rest in your storage layer, and back up file storage and the database together so attachments stay consistent with their metadata. Confirm which storage option your openDesk edition supports.
Configure SMTP and TURN paths
OX App Suite sends mail through the SMTP relay that you provide to openDesk, and openDesk also expects a TURN server for the components that need relayed connections. Define which hosts may relay outbound mail, how authentication and TLS are enforced on that path, and whether attachments pass through ClamAV over ICAP before delivery. Record each relay and TURN setting in your change log, because these values are easy to set once and then forget.
Review the openDesk security document
The openDesk security document is the reference for hardening decisions that span the whole bundle, so read it before you change any OX value. Map each of its recommendations to the OX settings you have changed, and note the reason for any item you have not adopted. Repeat this review whenever you change the release or the hosting environment, because an earlier review may no longer match the bundle you run.
Why OX App Suite in openDesk fails and how to fix it
This table lists the symptoms teams most often see when OX App Suite runs inside openDesk, the likely cause of each, and the requirement or release document to check before changing anything. Read each row against your cluster inventory and version record, starting with the platform and component checks. The main takeaway is that most failures trace back to a platform, version or sizing assumption that can be confirmed in the requirements before installation.
| Symptom | Likely cause | Fix and document to check |
|---|---|---|
| Install or upgrade fails or behaves unpredictably on an OpenShift cluster | openDesk is tested on kubespray clusters, not on OpenShift, so OpenShift-specific security and networking defaults can break the deployment | Confirm the platform before planning. Check the openDesk requirements document, and either move to a tested Kubernetes distribution or ask ZenDiS and DeployOpen for a written support position first |
| Components fail to schedule or show API incompatibilities | The cluster runs a Kubernetes version below v1.33, which openDesk does not support, or an older version than the OX App Suite N-1 and N-2 window allows | Check the cluster version against the openDesk requirements (v1.33 or later) and the OX App Suite requirements (N-1 and N-2). Plan a cluster upgrade before the openDesk install |
| Ingress resources are not reconciled, or the controller shows deprecation warnings | The deployment uses the deprecated Ingress nginx controller instead of haproxy-ingress, which is the stated option in openDesk | Switch to haproxy-ingress as described in the openDesk requirements document, and retest routing and certificate handling for the mail and calendar endpoints |
| OX components cannot route traffic or fail health checks | Istio is absent, but OX App Suite v8 expects it. The basic ingress-nginx option is only the fallback where Istio cannot be used | Confirm whether Istio is required in your design, then install a supported Istio release (latest plus two prior versions) as set out in the OX App Suite requirements. Record the fallback decision if Istio is not possible |
| Middleware cannot connect to Redis or MariaDB, or the database layer behaves inconsistently | The Redis or MariaDB version falls outside the lists in the OX App Suite requirements. OX uses Redis 7.4.x and MariaDB 10.6.x, 10.11.x, 11.4.x or 11.8.x with InnoDB | Compare the running versions against the OX App Suite requirements and the openDesk production services list. Upgrade or reprovision the service to a listed version, and confirm Galera Cluster support if you use it |
| Attachments or Drive files are missing, slow or lost after node changes | A node-local volume or an NFS share is used for attachments in a larger deployment. OX App Suite expects a distributed file system, and NFS is documented for small to mid-size deployments only | Check the storage section of the OX App Suite requirements. For larger deployments, plan object storage such as S3, Ceph RadosGW or Scality RING, and confirm how openDesk's RWO volume provisioner fits the design |
| Pods cannot start on a mixed cluster, or images fail on some nodes | The cluster includes ARM nodes. openDesk does not support ARM yet, and the evaluation minimum requires x64 CPU cores | Remove ARM nodes from the openDesk node pools or run openDesk only on x64 nodes. Check the minimum hardware section of the openDesk requirements document before adding capacity |
| Upgrade breaks after jumping several releases, or the deployment cannot be brought current | Minor versions were skipped. openDesk supports only the latest minor version and may require intermediate steps when several minors are skipped. OX LTS and standard release windows also constrain the path | Read the openDesk release management document for the intermediate steps, and check the OX Support Commitment for the supported release window. Upgrade in sequence, with a tested rollback and a backup before each step |
| Performance degrades, pods are evicted or the platform runs out of resources under real mailbox load | The evaluation minimum (12 x64 cores, 32 GB RAM and more than 10 GB disk) was used as production sizing. openDesk expects external production-grade services and recommends the Enterprise Edition for production | Re-size the platform for production using the openDesk requirements and the production services list (PostgreSQL 15, MariaDB 10, Redis 7, object storage, SMTP relay and others). Ask ZenDiS about the Enterprise Edition support model and confirm sizing with a written scope before go-live |
What buyers ask before hiring help for OX App Suite in openDesk
How much does OX App Suite in openDesk cost to deploy?
There is no published price. A quote follows from a written scope, and the cost depends on what that scope includes. Costs fall into three groups: the services you pay DeployOpen for (planning, build, configuration, testing and handover), the infrastructure you pay your cloud or data center provider for, and any software licenses. The main cost drivers are the number of cluster and external services to provision (openDesk expects production-grade PostgreSQL, MariaDB, Redis, Memcached, Cassandra, an SMTP relay, ClamAV, object storage and a TURN server), how identity federation is built, the storage design for OX Drive files and PIM attachments, the testing scope, and whether you choose the openDesk Enterprise Edition. ZenDiS recommends Enterprise for production. OX module licensing may carry separate fees under your license agreement, so ask for that line to be itemized.
How long does an OX App Suite openDesk project take?
Duration depends on the written scope, and the schedule is set in that scope. The biggest factors are how ready your cluster is, since openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later with an ingress controller, cert-manager and an RWO volume provisioner; how many decisions are still open on identity federation, storage and the Enterprise Edition; how much data must be migrated; and how much testing your organization requires before go-live. Release timing also matters. openDesk plans major releases annually in Q3 and minor releases monthly, and only the latest minor version is supported. Ask for milestones, dependencies on your teams and the change windows you must respect.
Can our own team deploy OX App Suite in openDesk without a partner?
Yes, if your team already holds the skills, and the skills matter more than headcount. The team needs Kubernetes operations experience, Helm 3.17.3 or later below v4, Helmfile 1.0.0 or later, and ingress and certificate management. For OX App Suite v8 it also needs Istio or the basic ingress-nginx option, Redis 7.4 and MariaDB operations on InnoDB, a distributed file system such as NFS or object storage, OpenID Connect or SAML configuration, and SMTP and mail delivery knowledge. openDesk is tested on kubespray clusters, not OpenShift, so check your platform first. A small pilot in a non-production cluster will show whether those skills are present before you commit.
What does our team need to provide for an OX App Suite openDesk project?
You provide access, decisions and named owners. Expect to supply access to the cloud accounts, data centers or air-gapped networks where the platform will run, and a Kubernetes cluster that meets the openDesk requirements. Name owners for identity (the directory and external identity provider used for federation), DNS and certificates, the SMTP relay, and backups. Decide the storage type: NFS suits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING suits larger ones. Provide test users, sample data, migration sources if any, and the change windows and approval steps your organization requires. Missing owners and late decisions are common causes of schedule slippage.
Which OX App Suite openDesk costs recur after go-live?
Infrastructure and licensing recur. Scoping, build, migration and testing are one-time. Recurring costs include the compute, storage, database and backup capacity your cloud or data center charges for, the openDesk Enterprise subscription if you choose it (which adds SLA-backed 2nd and 3rd level support and patches, sold as SaaS or for on-premises installation), any OX module fees set in your license agreement, and an ongoing support or upgrade retainer if you want DeployOpen to carry that work. Upgrades also recur. Plan for the openDesk release cadence, and note that in-place upgrades between majors are not guaranteed and that skipping several minor versions may need intermediate steps. Ask the quote to separate one-time and recurring amounts.
Which OX App Suite features require Enterprise in openDesk?
The openDesk Enterprise Edition docs list OX S3 storage and advanced full-text search as Enterprise-only features. The Enterprise Edition uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed support. Because the feature list belongs to the openDesk release you deploy, confirm the current list with ZenDiS and the version you plan to run before you finalize the scope. If your storage design depends on OX S3 storage or your search requirements depend on advanced full-text search, the Enterprise decision affects both architecture and cost, so settle it early. Ask the quote to show the Enterprise line separately from the DeployOpen services.
What information should we send to get an OX App Suite openDesk quote?
Send the inputs that define the scope. Include the openDesk version you intend to run and whether you need the Enterprise Edition for production. Describe your Kubernetes distribution and version, your ingress choice (Istio or ingress-nginx for OX), and whether the platform runs in a cloud, data center or air-gapped network. List the number of users and mailboxes in rough terms, your existing mail or calendar system and any migration needs, your identity provider and directory, your storage preference, and your backup and recovery expectations. Add the OX modules you need, your compliance requirements, and any fixed dates. A quote follows from a written scope, so the more specific the inputs, the more accurate the scope.
How DeployOpen scopes, delivers and supports OX App Suite in openDesk
DeployOpen approaches OX App Suite inside openDesk as one component of a Kubernetes-based workplace suite, running in infrastructure you control. Each engagement starts from a written, fixed scope, then covers the build, testing, documentation and handover of the mail and calendar path. Ongoing support is available as a retainer.
How we scope
- The written scope names which openDesk components and which OX App Suite mail and calendar functions are included.
- It states whether the deployment is an evaluation or a production system, since ZenDiS recommends Enterprise Edition for production.
- It lists any Enterprise-only OX features, such as OX S3 storage, and confirms that your organization holds the required license.
How we build
- Kubernetes cluster preparation to the openDesk requirements, including an ingress controller, cert-manager and an RWO volume provisioner.
- Helmfile and Helm configuration of the OX App Suite component, with values for your identity, storage and SMTP relay.
- Testing of mail send and receive, calendar invitations and shared calendar access before any user onboarding begins.
How we hand over
- Documentation of the Helmfile values, pinned chart versions and secrets handling used for the OX App Suite component.
- Runbooks for openDesk minor upgrades, including the intermediate steps needed when several minor versions are skipped.
- A walkthrough with your operations team covering mail flow, logs and the checks to run after each upgrade.
How we support
- Retainer options for ongoing patching, upgrades and monitoring, agreed in writing alongside the original scope.
- Tracking of OX App Suite release support windows, which Open-Xchange documents per release, against your openDesk upgrade plan.
- Confirmation of which party handles second and third level OX issues under your openDesk support agreement before go-live.
