Open-Xchange App Suite Kubernetes and Helm deployment

Before the first Helm install, the cluster must resolve every hostname the OX App Suite v8 deployment uses, and the ingress layer must terminate TLS for the public ones. Most login and session failures at this stage trace back to a name that resolves to the wrong place, or to a certificate that does not match the name the browser requested. Treat DNS and ingress as a checklist to finish before the first install, so that the pods are not the first place these faults show up. Work through the checklist with the platform team, and keep a written record of each name, its owner and the component that answers for it.

The deployment depends on two groups of names. Public hostnames serve the web client and any service endpoints that browsers or mail clients reach from outside the cluster. Internal service names carry traffic between the middleware and Redis inside the cluster, and they must resolve through cluster DNS to the services the chart creates. The web client builds redirect targets and session cookies from the hostname the user sees, so a mismatch between that hostname and the one the middleware expects can break the login redirect and end sessions early. Confirm the exact hostnames, the required record types and any split-horizon requirements against the official requirements page before you create a single record.

Istio is the required ingress path for OX App Suite v8, and the platform supports the latest Istio release plus two prior versions. Confirm which of those versions your cluster runs before you choose a gateway configuration. Istio gateways terminate TLS at the edge, with certificates held in Kubernetes secrets, and the routing rules must match the public hostnames exactly. Where Istio cannot be used, a basic ingress-nginx option exists. That choice changes who owns TLS termination and how the chart values describe the ingress, so the decision belongs in the design phase, not in the middle of the install. In either case, the ingress layer should be the single place where public names and certificates are defined.

Certificate management is where platform teams most often need to agree on ownership before install. Ask who issues and renews the certificates, whether cert-manager or an internal certificate authority is already in use, how the full certificate chain reaches the gateway, and how renewal is tested without downtime. Confirm how TLS is handled for any internal service names, and set the rotation schedule to match your security policy. Record the answers in the values file for each environment, so the first install and every later upgrade apply the same ingress definition and the same certificate process.

Drift in an OX App Suite v8 deployment usually starts with values that were edited by hand in one environment and never recorded anywhere else. The fix is to keep one base values file under version control, hold every environment-specific difference in a thin overlay, and make each change to the cluster traceable to a commit. Start by listing what legitimately differs between development, test and production: public hostnames for the middleware and frontend, replica counts for the stateless components, storage classes for the volumes that back OX Drive files and PIM attachments, and the Redis and MariaDB endpoints. Everything else should be identical across environments, so that a reviewer can see at a glance what is special about production.

Pin the chart version and every container image tag explicitly in the base file and in each overlay. A floating tag or an unpinned chart dependency means the same values file can render different manifests on two different days. Confirm with Open-Xchange which chart and image versions correspond to the App Suite release you have chosen, and record that pairing in the repository. Before every helm upgrade, render the manifests with helm template for the target environment and review the diff against the currently deployed release, using helm diff or an equivalent tool. Look specifically for changed image tags, altered replica counts, new or removed environment variables and anything touching ingress or storage. Treat an unexpected diff as a stop condition rather than a formality.

Secrets must stay out of values files entirely. Database passwords, Redis credentials, OIDC client secrets and SAML material should be referenced by name from the overlay and supplied from a secret store or from Kubernetes secrets managed by your existing tooling. Check that the rendered manifests contain references to secrets rather than the secret values, and make this check part of the review. Be aware that committed history keeps old values, so audit the repository for any credential that was ever placed in a file and rotate it.

Release timing, the choice between standard and LTS lines, and the testing of chart upgrades in a staging cluster belong to the upgrades and support topic, and this section does not repeat that guidance. What matters here is that the values structure makes those upgrades testable: if the overlays are thin and the base is pinned, the staging environment is a faithful rehearsal of production. Ask your team to confirm how the chosen Helm version, currently at least 3.17.0 according to the OX App Suite requirements, is pinned in your pipeline, so that the same client renders the same output everywhere.

Verification is the point where a Helm install stops being a deployment command and becomes a platform your team can operate. Before any user is pointed at the new cluster, confirm that every workload the chart created is healthy, then confirm the dependencies that OX App Suite v8 relies on are reachable from the middleware. Start with pod state across the release namespace, including the middleware, frontend and any supporting services the chart deployed. Any pod that is restarting, not ready, or stuck in a pending state should be explained in writing before you continue, because a pod that looks healthy can still be failing its readiness probe against a dependency. Next, test the data paths directly from inside the middleware pods. Check that the Redis instance used for caching and session storage answers from the middleware namespace, whether it was deployed through the littlered operator or is a custom or unmanaged setup. Check that MariaDB accepts connections with the account the middleware uses, and confirm the server version is one of the supported branches listed in the requirements (10.6.x, 10.11.x, 11.4.x or 11.8.x). If you run Galera Cluster, connect to more than one node and confirm the cluster reports as synced. For file storage, confirm the NFS export or object storage bucket is mounted or reachable, and write a test file from a middleware pod to prove it is writable by the service user, then remove it. Then verify from outside the cluster. Resolve the public hostname from a machine on a network you do not control, confirm the certificate chain presented at the ingress or Istio gateway matches the expected name and is trusted, and confirm that internal names are not leaking into public DNS. Run a test login through the web interface using a dedicated test account, then send a message to an external address and a reply back in, confirming delivery in both directions. Record the message identifiers and timestamps. Have the mail flow owner, not only the platform engineer, sign off on that test. For failure, decide the rollback rule before the install, not during it. Helm keeps a revision history for each release, so run helm history to identify the previous revision that was healthy, then roll back with helm rollback to that revision number if readiness fails and the cause is in the chart change rather than in shared data. Do not roll back blindly after database schema changes or after users have written data, because the previous chart may not match the new state. Confirm the rollback path in a non-production environment first, and ask DeployOpen or your own team to document which changes are reversible. Keep an evidence record for every check: the command or test, the environment, the chart version and values file hash, the result, the person who ran it, and the revision number. Store the record with the change ticket so auditors and your own operations team can trace what was verified and when.

The release you install decides how long you keep receiving fixes, so settle it before you write the Helm values. OX App Suite v8 offers two support paths. A standard release is supported for 12 weeks, and that window ends when the third following release becomes available. An LTS release is supported until the next LTS release plus six months. The current LTS is v8.47 (first customer shipment 2026-03-18 is the FCS date recorded in the commitment). The newest release listed is v8.53, with first customer shipment on 2026-09-23. v8.35 was the first v8 LTS and is now discontinued, so it should not appear in any new deployment.

The choice between a standard release and the LTS line shapes your operating model more than your first install does. Standard releases move the platform forward every few weeks, which suits a team that can test and roll out often. The LTS line changes less often and gives a longer window between mandatory moves, which suits organizations whose change boards meet on a slower cycle. Decide this per environment if needed. Record the chosen release in the chart version and container image tags, and make sure your test and production environments do not drift onto different support paths without a documented reason.

Confirm the release on the day you install, not from a copy in an old runbook. Open the Open-Xchange support commitment page and check three things: the release status, the date it stops receiving support, and whether a newer release has changed the window. Write the release number, the check date and the end-of-support date into the change record. Repeat the check before any production go-live, because the list changes as new releases ship and a release that is supported on Monday can be near its end a few weeks later.

Plan for the window to close while your project is still running. A migration or customization effort can take longer than a standard release stays supported, so the install date is not the only date that matters. Ask the vendor or partner to show the upgrade path from your chosen release to the next one, including the Helm chart changes and the test cycle each step needs. If you choose an LTS release, confirm when the next LTS is expected and when the six-month tail ends, and keep that date visible to the people who own the calendar.

Put release ownership in writing before work starts. The statement of work should name who selects the release, who confirms its support status on the install day, who performs each upgrade, and who pays for the testing between upgrades. Ask for the support end date to appear in the handover documents together with the chart version. This turns a public support page into a dated commitment your team can track, and it makes clear whether upgrades are included in the scope or sold as a separate retainer.