openDesk upgrades and support

The published cadence sets the upgrade rhythm for openDesk. ZenDiS plans major releases annually in Q3, minor releases monthly and patch releases on demand, and supports only the latest minor version. For a platform team, the supported target changes every month, so the upgrade window has to be planned around that cadence rather than around a version number that stays fixed. Start by deciding who owns the monthly check of the release list, who approves a move to a new minor, and how much staging time each upgrade needs before it reaches the production namespace.

The pace of the line is easy to underestimate. The latest release at research time was v1.19.1, published on 2026-10-06, and it followed v1.19.0 on 2026-10-01, less than a week earlier. A team that plans a quarterly change window may find that the version it tested is already outside the supported line when the window opens. Before any planning session, check the current release list in the openDesk releases on GitLab, record the newest minor and any patch on it, and confirm the date of that release so the plan starts from the live state, not from this page.

Staying on an unsupported minor is a decision with consequences that the team should confirm in writing before it makes that choice. A deployment on a minor outside the supported line may not receive fixes from the vendor, and support requests may be answered with a request to upgrade first. Ask ZenDiS or your support provider which support, patches and advice still apply to the version you run. Also ask whether your chart values, Helmfile state and bundled component versions can be brought forward without a full reinstall, because the cost of a delayed upgrade often grows with each skipped minor.

Upgrades between major releases carry more risk than monthly minor moves. In-place upgrades between majors are not guaranteed, and skipping several minors may require intermediate steps. Before committing to a jump, read the release notes for every minor in the path, confirm with the vendor whether a direct path exists, and rehearse each step in a staging cluster that matches production's Kubernetes version, external PostgreSQL, Redis and object storage settings. Record the result of each rehearsal so the production change follows a tested sequence instead of an assumed one.

The support model decides who answers when an openDesk upgrade breaks, so settle it before the first production upgrade and before an incident forces the question. Community Edition is supported only by the community on openCode, and that support carries no SLA. No one is contractually obliged to respond, to help diagnose a failed Helmfile run or to deliver a fix by a set date. Because openDesk supports only the latest minor version, a community answer may also arrive after you have already needed to move to a newer release. Community Edition can suit evaluation and non-production work, but you should document in writing which team in your organization owns any failure.

Enterprise Edition uses the same open-source core licenses as Community Edition, but it adds closed-source modules, an Enterprise-only registry and a license file that your deployment must present. It also includes SLA-backed 2nd and 3rd level support and patches, and it is sold as SaaS or for on-premises installation. For upgrade work, the registry and license file become dependencies of your deployment pipeline. Confirm with the vendor who issues the license, how credentials are rotated, what response times apply to each severity level, and whether the SLA covers every bundled component or only some of them.

Several Enterprise-only features touch upgrade work directly. Collabora automatic load scaling, Element AdminBot, GroupSync and Admin Console, Nextcloud Enterprise security patches and the Guard app, OX S3 storage and advanced full-text search, OpenProject Enterprise add-ons and XWiki Pro apps each bring their own configuration, images or dependencies. A Helmfile values set that is correct for one edition may therefore need changes for the other. Before you choose an edition, list which of these features your rollout needs, and ask the vendor which of them change between the minor releases you plan to take.

ZenDiS recommends Enterprise Edition for production use. Your organization must confirm licensing and support terms directly with the vendor, including who is entitled to open tickets and which versions are covered. A partner retainer can cover upgrade execution, testing and operations, but it does not replace vendor support unless the contract says so. Ask for a written responsibility split that names who triages a failed upgrade, who escalates to 2nd and 3rd level support, and who approves a rollback decision before the maintenance window opens.

Before any upgrade or support engagement can be scoped, your team needs to make a set of inputs available. The most important of these is read access to the Helmfile environment and values repository, because the deployed state of openDesk is defined there: the environment files, the values overrides for each bundled application, and the pinned chart and image versions. Without it, a partner can only guess at what is running today. Confirm where that repository lives, who owns it, and whether the environment files reflect what is actually deployed or have drifted through manual changes. Second, the operator role needs cluster access. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, and the work touches the ingress controller, cert-manager, the RWO volume provisioner and the namespaces that hold each component. Confirm which of these your platform team can grant to a named operator role, under what approval, and whether production access is separated from staging. Also confirm that the Helm version in use is 3.17.3 or later but below v4, and that Helmfile is at 1.0.0 or later, since both affect how the upgrade is executed. Third, a staging environment that mirrors production is needed to rehearse each upgrade. A staging system that differs in external services, such as PostgreSQL 15, MariaDB 10, Redis 7, the SMTP relay, ClamAV over ICAP, object storage or the TURN server, can hide the very breaking changes the rehearsal is meant to catch. Ask whether the staging cluster runs the same external service versions as production and whether its data can be refreshed from production on a schedule your change process allows. Fourth, supply test accounts and a written test plan that covers the bundled applications your users depend on, such as Element, Nextcloud, OX App Suite, XWiki, OpenProject, Jitsi and Collabora. Pair these with the change calendar, the approval owners who can sign off a release window, and a current version inventory listing the deployed openDesk release and each component's version. Document the versions of the external services as well. Confirm the identity provider and directory configuration, including any OIDC federation and the Nubus Directory Importer settings, so the test accounts reflect real sign-in paths. Finally, name one owner for each bundled application who can answer functional questions and accept the result of testing. Before requesting a quote, walk through this list and mark each item as existing, partly existing or missing. Items that are missing usually add effort to the engagement and should be named in the written scope.