What an OX App Suite air-gapped deployment involves
OX App Suite v8 runs on Kubernetes and is delivered as Helm charts that reference container images, so an air-gapped deployment is mainly the work of building a complete local copy of those artifacts and a repeatable path for moving updates into the isolated network. The charts and images are only the starting point. Every image a chart references, and every component those images need at runtime, must be available from a registry the cluster can reach without leaving the boundary. Teams usually plan for this model when regulation, public sector rules, critical infrastructure obligations or sovereignty requirements mean that email, calendar and contacts data cannot depend on an outside network path, including pulls made during installation and upgrades. The same constraint often applies to the people who run the platform, who need a way to reach vendor documentation and release notes without giving the cluster a route out.
Helm 3.17.0 or newer is a supplied minimum for OX App Suite v8, so the first decision is the Helm version the staging host and the offline installation workstation will use. Confirm that version before any artifacts are packaged, because a chart that installs cleanly on one client and fails on another creates avoidable troubleshooting inside a network where you cannot easily fetch a fix. The artifact list is the most important document in the project. It should cover the OX App Suite charts and images for the release you select, the Kubernetes version your cluster runs, and the ingress path you choose. OX App Suite v8 requires Istio, with support for the latest Istio release plus two prior versions, and offers a basic ingress-nginx option where Istio cannot be used. Redis 7.4.x and MariaDB images are also part of the picture, depending on whether you use the littlered operator or a custom setup. The exact mirror tooling and the complete artifact list must be confirmed with Open-Xchange before procurement of the offline toolchain.
Two decisions shape the update process from the start. The first is the release channel. A standard release is supported for 12 weeks, ending with the availability of the third following release, while an LTS release is supported until the next LTS release plus six months. The current LTS named in the support commitment is v8.47, and the newest release listed there is v8.53. Choose a channel that matches how often your change board can approve an offline update cycle, and confirm the support end date for that channel with Open-Xchange. The second decision is how software crosses the boundary. Each update means a new transfer, scanning and verification step. For operators in critical infrastructure, the NERC CIP-013-2 supply chain requirement, which asks procurement processes to address verification of software integrity and authenticity, is a useful reference for documenting that step. Plan for the transfer to be repeatable, logged and tested in a non-production environment before it reaches the production enclave.
Plan for the work outside the cluster as well. OX Drive files and PIM attachments need 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. Those storage products and their own packages must also be obtainable inside the network if they are hosted there. Ask Open-Xchange which of these components it expects you to mirror, which it expects you to source separately, and which must be verified before installation. Finally, ask for a written confirmation of the mirror workflow, the artifact manifest for your chosen release, and the upgrade steps between releases. Those answers determine the staffing, test environments and change windows you will need, and they are the basis for a fixed-scope quote from any implementation partner.
Configuration choices that change the air-gapped install
This table compares the four decisions that most change what goes into the disconnected mirror: ingress, Redis, MariaDB and file storage. For each option, read when it fits, what extra images, charts or operators it adds, and what to confirm with Open-Xchange before the first image pull. Settle these choices early, because they set the mirror list and the offline steps for every later update.
| Decision | When it fits | What it adds to the mirror | What to confirm offline |
|---|---|---|---|
| Ingress: Istio | Where your cluster supports Istio and your team can operate a service mesh | Istio control plane and gateway images, plus their Helm charts, at the version the release requires | Which Istio releases the current OX release accepts, and the exact images to mirror |
| Ingress: ingress-nginx | Where Istio cannot be used and a basic ingress controller is acceptable | The ingress-nginx controller image and chart, plus any admission webhook images it needs | Whether the basic option covers every route in your deployment, and any limits compared with Istio |
| Redis: littlered operator | Default path for Redis 7.4.x caching and session storage, managed by the install | The littlered operator, its controller image, and the Redis 7.4.x images it creates | Operator and Redis image tags for an offline pull, and how operator upgrades reach the environment |
| Redis: unmanaged or custom | An existing Redis service you already run, or a setup your team must control directly | Only the Redis 7.4.x image if you deploy it yourself, plus any exporters or sidecars you add | Which Redis 7.4.x configurations OX supports, and how the install connects to your instance |
| MariaDB: single instance | Smaller deployments that accept one database node and a restore-based recovery path | One MariaDB image on a supported line: 10.6.x, 10.11.x, 11.4.x or 11.8.x | Which line OX recommends for your release, and the InnoDB settings it expects |
| MariaDB: Galera Cluster | Deployments that need several database nodes for availability | Galera-enabled MariaDB images and any cluster or operator charts, on the same supported line | The Galera setup steps, node count and recovery procedure OX supports, and matching images for your line |
| File storage: NFS | Small to mid-size deployments storing OX Drive files and PIM attachments | Possibly no extra images, but NFS client or provisioner components if your chart uses them | Mount options, export layout and the distributed file system behavior OX requires |
| File storage: object storage | Larger deployments using AWS S3, Ceph RadosGW or Scality RING as the backend | Any storage driver or provisioner images, plus the chart values that point to the bucket | Which S3 API features the release uses, and how your chosen backend is validated for OX |
How the registry mirror and local charts are scoped
The mirror has to hold everything an offline install will request: the OX App Suite charts, their dependencies, the container images they reference, and the Kubernetes images that build the cluster. The Kubernetes version window and the mirror script's inputs and outputs decide what that set contains, so confirm both before the transfer is planned.
OX Helm charts and dependencies
The mirror must hold the OX App Suite v8 Helm charts and every chart dependency they pull in, so Helm can install from a local source without outside network calls. Pull the charts at the exact version named in the release materials and record each chart version next to its image tags. Helm 3.17.0 or newer is required, so install that version on the admin workstation and the jump host. Ask Open-Xchange whether any sub-chart fetches from an external repository at install time.
Container images the charts reference
Every image the charts reference belongs in the mirror. That includes the Istio images if Istio is your mesh, the littlered operator and the Redis 7.4.x images it deploys, and the MariaDB images for your chosen 10.6.x, 10.11.x, 11.4.x or 11.8.x line. Build the list from rendered output using helm template so sidecar and init images are captured. Confirm with Open-Xchange which optional images, such as the ingress-nginx option for clusters where Istio cannot be used, belong on the list.
Kubernetes images for an offline cluster
For a kubeadm-built cluster, run kubeadm config images list to see the control plane images for your Kubernetes version, then kubeadm config images pull while network access is still available. Push those images to the private registry and run kubeadm init with --image-repository set to that registry. If you use a Kubernetes distribution, follow its own offline procedure, since its installer may pull images that the kubeadm steps do not list. Verify image digests after transfer.
Cluster version and the N-1 and N-2 window
OX App Suite v8 supports Kubernetes versions N-1 and N-2, so choose a cluster minor version inside that window for the App Suite release you are installing. Build the mirror for that exact cluster version, because control plane and system images change with each minor release. Plan mirror refreshes around any Kubernetes upgrade, and check the version skew rules before upgrading the API server and kubelets. Confirm the current window with Open-Xchange.
Mirror script inputs and outputs
Open-Xchange provides a mirror script that gathers artifacts for transfer. Before you plan the transfer, confirm its inputs, such as the release version, chart list, image list and registry credentials, and its outputs, such as archive layout, manifests and checksums. Ask whether the output is signed and how the import side validates it. Treat the output as a supply chain artifact that must pass integrity checks before it enters the isolated network.
Air-gapped install sequence for OX App Suite v8
This sequence takes a disconnected Kubernetes cluster from a version check to the first login for OX App Suite v8. Each step closes with a check, so the team knows the environment is ready before the next dependency goes in. The order matters because the charts only install cleanly once every image, data store and file path they reference resolves inside your network.
Confirm the Kubernetes version against the support rule
The platform team checks the OX App Suite v8 requirements, which support Kubernetes versions N-1 and N-2, and confirms the target version is still maintained by the Kubernetes project. The chosen version determines the Istio release, the chart versions and the upgrade path to the next minor version, so it is fixed before any build work starts. Done when the Kubernetes version, the matching Istio release and the upgrade plan are written into the install record and approved by the change owner.
Build or validate the cluster without internet access
The platform team builds the cluster on nodes with no route to the internet, or validates an existing one. For kubeadm clusters, control plane images are pulled in advance on a staging host with kubeadm config images pull, and the --image-repository flag points kubeadm init at the internal registry. Production designs follow the kubeadm high availability guide, with at least three control plane nodes behind a TCP load balancer on port 6443. Check: all nodes report Ready and an etcd snapshot saves successfully with etcdctl.
Stand up the internal registry
The team deploys a container registry inside the isolated network with TLS, authentication and enough storage for the full OX image set plus the images for Redis, MariaDB and the gateway components. Cluster nodes and the staging host are configured to trust the registry certificate. Check: a test image pushed from the staging host pulls successfully on a worker node in the isolated subnet.
Run the mirror process for charts and images
On a staging host with controlled internet access, the team runs the mirror process described in the Open-Xchange documentation to collect the OX App Suite Helm charts and every container image they reference. The artifacts then cross into the isolated network through your approved transfer process, with checksums verified and provenance recorded for each file. Where your regulator applies NERC CIP-013-2, this verification is the control that addresses software integrity for vendor software carried across the boundary. Check: the mirrored image list matches the image references in the charts one for one.
Install Helm and configure the gateway
The team installs Helm 3.17.0 or a newer release on the administration host, using a binary verified through the same transfer process as the charts. Helm is pointed at a local chart repository or directory only. OX App Suite v8 requires Istio, so the team installs the Istio release listed as supported in the requirements, or configures ingress-nginx where Istio cannot be used. Check: helm version reports 3.17.0 or newer and the gateway control plane reports healthy.
Deploy Redis and MariaDB from local images
The team deploys Redis 7.4.x for caching and session storage, by default through the littlered operator, or connects a custom or unmanaged Redis if your standards require it. MariaDB runs with the InnoDB storage engine as the primary data store, using one of the supported 10.6.x, 10.11.x, 11.4.x or 11.8.x lines. Decide with the architecture team whether Galera Cluster is needed. Both services pull images from the internal registry and store data on encrypted, backed-up volumes. Check: a MariaDB backup restores into a separate namespace and the restored database opens.
Attach NFS or object storage for files
The team attaches a distributed file system for OX Drive files and PIM attachments. NFS suits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING suits larger ones. The storage endpoint must be reachable only from the isolated subnet, and any images it needs are included in the mirror plan. Permissions and mount options are set before the install, because storage changes are harder to reverse once users store data. Check: a file written from one pod is readable from another, and a storage restore reproduces it.
Install the charts from local sources and sign in
The team runs helm template against the local chart source first and confirms the output references only internal image addresses. It then runs helm install with values that point Redis, MariaDB, storage and the gateway at the local services. Login is configured for the chosen identity design, using OpenID Connect or SAML, and a test account signs in. Updates later follow the same mirror cycle, so repeat the mirror and template checks for each release. Check: helm template renders only internal image references, every pod pulls from the isolated network, and the test login succeeds.
How updates reach a disconnected OX App Suite cluster
Every update to a disconnected OX App Suite cluster is a repeated transfer, not a single download. Release artifacts are fetched on a connected staging side, verified there, carried across the boundary by an approved method and loaded into the internal registry. Only after the images are in the internal registry should anyone run a Helm chart upgrade. The target side needs Helm 3.17.0 or newer, so the cluster's tooling must be checked against the new release before the transfer starts, not after it arrives.
The support windows determine how often this path runs. 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. v8.47 (FCS 2026-03-18) is the current LTS. An organization on a standard release therefore has a shorter window than one on an LTS line, and it will need to move through the transfer path more often to stay supported. Work out which line each environment is on, and when its support ends, before scheduling the first transfer.
Confirm with Open-Xchange which release cadence your contract or support agreement gives you, and whether your environment follows the standard releases, the LTS line or both. The answer sets the transfer calendar, the staffing for each cycle and the number of change windows you need in the cluster. Ask for the expected date of each upcoming release and for the list of artifacts each one ships, including container images, Helm charts and any supporting packages, so that the staging side can collect everything in one pass.
Ask how security fixes are delivered to an isolated environment. Find out whether they arrive as patch releases on the line you are running, as separate images or chart versions, or only inside the next feature release. Confirm whether a fix can be applied to an LTS release between LTS releases, and how the fix is identified and signed so your verification step can check it. Your security team should also decide how fast a critical fix must reach the cluster and which approval path it follows. This is the control point that frameworks such as NERC CIP-013-2 expect to see for vendor software and patches, where it applies.
Confirm how many releases can be skipped inside an isolated environment. A jump across several releases may need intermediate transfers, database schema steps or a specific upgrade order, and the answer determines whether you can move directly to a newer release or must stop at each one. Illustrative example: if a cluster is three releases behind and the vendor requires one intermediate stop, the plan needs two transfers and two rehearsals, not one. Test each step on a staging cluster that matches the disconnected one, and keep a written record of every transfer, including the verification results and the chart version deployed.
Security and operations for an isolated OX App Suite cluster
An air-gapped OX App Suite cluster has no vendor connection to fall back on, so every control must be decided at build time. The cards below cover secrets, identity, cluster hardening, etcd recovery and the integrity of each package that crosses the boundary.
Encrypt and manage Kubernetes Secrets
Kubernetes stores Secrets unencrypted in etcd by default, and OX App Suite holds database, Redis and integration credentials in them. Decide before installation whether to enable encryption at rest, restrict list and watch access with least-privilege RBAC, or source credentials from an external store through the Secrets Store CSI Driver. Confirm which option your operator can support in a disconnected environment, and who holds the encryption keys.
Define cluster user authentication
Kubernetes does not manage normal users as API objects. It accepts X.509 client certificates, OpenID Connect or JWT bearer tokens, webhook token authentication and authenticating proxies. Choose the method for administrators and for automation before the cluster is handed over, and confirm that your identity provider is reachable from inside the isolated network without outbound calls.
Plan application sign-in
OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware. Decide which protocol your users will sign in with, where the identity provider runs, and how its signing keys and metadata reach the cluster as part of the offline bundle. Confirm the exact configuration with Open-Xchange before you fix the design.
Apply Pod Security and CIS hardening
Pod Security Standards define baseline and restricted policies for workloads, and the CIS Kubernetes Benchmark provides configuration checks for the control plane and nodes. Set a Pod Security level for the OX namespaces, run your chosen benchmark tool against the cluster, and record every deviation with its reason. Expect the first scan to reveal defaults that need deliberate change.
Back up etcd and test restores
etcd holds the cluster state, so a snapshot taken with etcdctl snapshot save is the basis of recovery. Restore with etcdutl into a separate test cluster on a regular schedule, not only when something fails. Run an odd number of etcd members, with five recommended for production, so that a majority remains after a single failure. Store snapshots inside the isolated environment and encrypt them.
Verify every package crossing the boundary
Each Helm chart, container image and mirror artifact carried into the environment needs a documented integrity and authenticity check, with checksums or signatures compared against values obtained through a separate trusted path. Record who approved each transfer and keep the manifest with the bundle. NERC CIP-013-2 describes this kind of verification for vendor software and patches, and similar expectations apply in other regulated sectors.
What drives the cost and duration of an air-gapped install
The cost of an air-gapped OX App Suite install is driven less by the Helm install itself than by the work required to make a disconnected Kubernetes cluster and its dependencies carry the platform. Four scoping decisions move the estimate most: the artifact list (every container image, Helm chart, Redis and MariaDB operator dependency, and Istio or ingress-nginx component that must cross the boundary), the cluster build and hardening, the storage and database design, and the transfer process that moves each release across the isolation boundary. Ask any partner to show the artifact list before agreeing a price, because an incomplete list is the most common source of late change.
Most of the effort is one-time. The initial build covers the cluster, the private registry, the local Helm chart repository, the mirror workflow, validation inside the isolated network, and any integrations such as SSO through OpenID Connect or SAML, plus a migration from an existing OX App Suite 7 or mail system if one is in scope. Several factors raise this effort sharply. Galera Cluster for MariaDB adds quorum, backup and failover testing. Large file stores on NFS or object storage such as Ceph RadosGW or Scality RING add sizing and replication work. A custom or unmanaged Redis instead of the littlered-operator default adds configuration and support boundaries. Multiple environments (production, staging, disaster recovery) multiply every step.
Licensing is a separate cost line. Open-Xchange's Operations Guide states that some modules or features may be custom packaged, limited or charged separately under the license agreement. Confirm in writing which modules you intend to run, whether they are covered by your agreement, and whether any of them need a different package before the artifact list is frozen. Source code availability under AGPL-3.0 on GitHub does not by itself settle which modules are licensed for your use.
Recurring work follows the release and patch cycle. Each OX App Suite release must be reviewed, mirrored, transferred, imported into the registry, tested in the isolated network and then promoted. The support commitment, which gives a standard release 12 weeks of support and an LTS release support until the next LTS plus six months, sets how often you must do this. Kubernetes patching is also recurring: Kubernetes minor releases arrive about three times a year, and the version skew policy requires the control plane to move before nodes. Scheduled backup restore tests, including MariaDB and file store restores in the isolated network, belong in the recurring budget.
When requesting a quote, ask the partner to separate one-time from recurring work, to state the assumed number of environments and release transfers per year, to list the artifacts and integrations in scope, and to name the licensed modules and who pays for them. Ask who performs each transfer and who signs off the validation evidence. A quote that cannot answer these questions is pricing an assumption, not your environment.
Limits to confirm before you commit to an air-gapped OX App Suite install
An air-gapped install depends on what Open-Xchange packages, which versions your cluster can run and what your license allows you to use. Confirm these limits in writing before you order hardware or start the mirror work, because each one changes the build plan.
Complete mirror artifact list
Ask Open-Xchange for the full set of artifacts a disconnected cluster needs: Helm charts, container images, the Redis operator and any supporting images, plus the tooling that packages them. Compare that list against the images your chosen chart version actually references. A missing sidecar or init image is one of the most common reasons an offline install stalls partway through.
Mirror script and registry support
Confirm whether the mirror script works with your private registry product, its authentication model and its handling of nested repository paths. Ask who supports the script when it fails, and whether it can be run again to pick up a newer release without re-copying the entire set. Test it against your registry before the change window opens.
Licensing and separate module fees
Open-Xchange's Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask which modules you plan to use are covered, which are priced separately, and whether any feature changes behavior when the deployment has no outbound connection. Get the answer in the license terms, not in a sales call.
Istio and Kubernetes version matrix
OX App Suite v8 requires Istio, and the support window covers the latest Istio release plus two prior versions. Kubernetes support covers N-1 and N-2. Ask for the matrix that applies at the time of your build, then confirm that your cluster distribution, its Istio packaging and your mirror contents all line up. If Istio cannot be used, confirm the ingress-nginx option and its limits.
MariaDB and Redis versions
OX App Suite v8 supports MariaDB 10.6.x, 10.11.x, 11.4.x and 11.8.x with InnoDB, and Galera Cluster is supported. Redis 7.4.x is used for caching and session storage, deployed by default through the littlered operator. Confirm which MariaDB and Redis images are in your mirror, whether they are self-managed or existing services, and who patches them while the environment has no internet access.
Release channel access without internet
Confirm how new releases, LTS updates and security fixes reach a disconnected environment. Ask whether the release channel can be consumed through media or a transfer process, how signed packages are verified after they cross the boundary, and what the support commitment says about standard and LTS releases. Plan the update cadence around the support windows, not around your change calendar.
What do buyers ask before running an air-gapped OX App Suite install?
What drives the cost of an air-gapped OX App Suite installation?
The main drivers are scope, environments and how much of the supporting stack must be prepared offline. More clusters, more modules, more identity and storage integrations, and more backup and test work each add effort. A quote follows from the written scope, and DeployOpen does not publish a price list.
The cost components are planning and architecture, building the offline image mirror and local Helm chart process, cluster deployment, identity and storage integration, backup setup, testing and handover. Design and mirror setup are usually one-time work, while update cycles and ongoing support recur.
Ask for a quote that lists each deliverable, the environments covered and the tasks your team keeps. Also confirm licensing with Open-Xchange, because the Operations Guide notes that some modules may carry custom packaging or separate fees set in the license agreement.
How long does an air-gapped OX App Suite deployment take?
Duration depends on how many environments and integrations are in scope and on how fast your approvals move. No general timeline applies, so the written scope and its dependencies set the schedule.
Most time goes to prerequisites: confirming the Kubernetes version, choosing Istio or the basic ingress-nginx option, selecting the storage type (NFS for small to mid-size deployments, or object storage for larger ones), and fixing the MariaDB and Redis configuration. Approval cycles for moving signed images and charts across the isolation boundary can take longer than the technical install.
Ask for a timeline that names each approval gate, the work your team must finish before each phase, and the acceptance tests that close the engagement.
What does our team need to provide for an offline OX App Suite install?
Your team provides access, approvals and owners for the systems the install depends on. Plan these before the work starts, because they often decide the schedule.
- Cluster administrators who can grant access to the Kubernetes control plane and worker nodes
- Storage for persistent data such as OX Drive files and PIM attachments, on NFS or on object storage
- Network approvals for the transfer path, the private registry and the DNS and certificate changes
- An identity provider for single sign-on through OpenID Connect, and SAML if your middleware login requires it
- Backup owners for MariaDB, persistent storage and etcd, with a tested restore procedure
- Named owners for Istio or ingress-nginx, Redis and the operations runbook
Confirm each item in the written scope so that responsibilities are clear before the first image crosses the boundary.
Can our own team run an air-gapped OX App Suite install without a partner?
Your team can do it if it already runs Kubernetes in an isolated network and has the skills for each supporting component. The gap is usually in offline operations, not in the application itself.
The work includes pulling images and charts on a connected system, mirroring them to a private registry, verifying what crosses the boundary, deploying with Helm 3.17.0 or newer, and configuring Istio or ingress-nginx, storage, MariaDB with InnoDB, and Redis 7.4.x. Regulated sectors may also need documented software integrity checks for anything carried across an isolated boundary. NERC CIP-013-2 is one example in the electric sector.
Assess your team against that list. A partner is often used for the first install and the documented procedure, with your team taking over operations afterward.
What changes when a new OX App Suite release must reach an air-gapped cluster?
Every update repeats the transfer cycle: new charts and images are pulled, mirrored, verified and applied inside your environment. The update path therefore needs a schedule, owners and a rollback plan.
The Open-Xchange support commitment says a standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months, and v8.47 is the current LTS. Choosing between standard and LTS tracks sets how often your team must move.
Kubernetes updates follow the version skew policy: kube-apiserver is upgraded first, one minor version at a time. Ask for an upgrade plan that covers the cluster, the database, Redis and the mirror process.
Is a fixed-scope engagement possible for an air-gapped OX App Suite install?
Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The written scope is also the basis for a quote.
A fixed scope usually defines the environments, the modules and integrations, the identity and storage choices, the backup and restore tests, the documentation handed over, and the work left to your team. Changes such as an extra cluster, an additional integration or a new module are handled as scope changes in writing.
Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
What should an engineer check before starting an offline OX App Suite install?
Check version support, component choices and storage before any image is mirrored. Each of these decisions changes the mirror contents and the install steps.
Confirm that the Kubernetes version falls within N-1 or N-2 of the OX App Suite v8 requirements, and that Helm is 3.17.0 or newer. Choose Istio, which supports the latest release plus two prior versions, or the basic ingress-nginx option where Istio cannot be used. Pick MariaDB from 10.6.x, 10.11.x, 11.4.x or 11.8.x, with InnoDB and Galera if clustering is needed. Decide on Redis 7.4.x through the littlered operator or a custom setup.
For the cluster itself, plan kubeadm image pulls from a private registry, etcd backups and encryption at rest for Secrets, because Kubernetes stores Secrets unencrypted in etcd by default.
How DeployOpen scopes and delivers an air-gapped OX App Suite install
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including disconnected networks. For OX App Suite v8 on Kubernetes, that means agreeing the mirror, chart, identity and storage design in writing before any build starts, then handing over a tested environment with the update process your team will run.
How we scope
- Inventory the target cluster, Kubernetes version, Istio or ingress-nginx choice, and Helm 3.17.0 or newer availability.
- Confirm the MariaDB version, Galera Cluster needs, and the distributed file system for OX Drive and PIM attachments.
- Agree in writing which Redis, identity, and mail backend components are in scope, and which are provided by your team.
How we build
- Stage container images, Helm charts and the mirror script through your approved transfer and verification process.
- Configure the private registry and local chart repository so the cluster pulls only from inside your boundary.
- Test install, upgrade and rollback on a non-production cluster before the production change window is scheduled.
How we hand over
- Deliver the written runbook, values files, network and storage configuration, and the mirror procedure for each release.
- Walk your operations team through checking package integrity and authenticity before each import across the boundary.
- Document the verification steps and evidence that compliance assessors may ask to see for the environment.
How we support
- Plan how each new OX App Suite release is reviewed, mirrored and tested against the Open-Xchange support commitment.
- Offer ongoing support, upgrades and testing as a retainer, sized to the agreed environment and scope.
- Confirm with Open-Xchange which release channel, LTS line and licensing terms apply before your first upgrade cycle.
