openDesk vs Nextcloud Hub

openDesk is a Kubernetes platform, so the hosting decision comes before any feature comparison. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not supported yet. That figure only covers a trial. The cluster must also run CNCF-certified Kubernetes at v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. openDesk is tested on kubespray clusters and not on OpenShift, so an existing OpenShift estate needs a separate decision before the pilot starts. For production, openDesk expects you to supply external services rather than run them inside the suite. The list includes PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each one is a component your platform team must provision, patch, back up and monitor. Ask who owns each service, which ones already exist in your environment, and which versions your operations standards allow. Nextcloud Hub, by contrast, can run on a single host with a conventional web server, PHP runtime and database, so the operational surface is much smaller if you only need files.

Confirm production sizing with ZenDiS and your platform team before you commit to a budget. No production sizing figure is supplied for openDesk, and the evaluation minimum does not scale linearly to your headcount. Ask ZenDiS for sizing guidance tied to your named user count, concurrent video use, file volume and recording requirements, and ask for the assumptions behind it. Then ask your platform team to check that the external services, storage classes and network paths can carry that load in your data center or public cloud account. Where the workload is mainly file sync, a Nextcloud Hub deployment sized to your user count may be the lighter choice, but you will still need to add mail, chat and video as separate systems with their own hosts. Treat the cluster as a long-lived commitment. openDesk plans major releases annually and only supports the latest minor version, and in-place upgrades between majors are not guaranteed. Build time for upgrade testing, Kubernetes version lifecycle work and staging capacity into your plan from the start. Confirm with ZenDiS which Kubernetes and Helm versions each openDesk release requires, and ask whether the Enterprise Edition support covers the cluster components or only the suite. The openDesk deployment README is the natural next read for the current component list.

The first question is where identity lives. In the openDesk stack, Nubus provides the portal and identity and access management layer, so user accounts, group membership and application access are brokered through the suite itself. openDesk also documents federation with an external identity provider, which lets your existing directory remain the source of truth while the suite consumes its identities. With Nextcloud Hub, you choose the identity model yourself. The LDAP app lets LDAP and Active Directory users appear in Nextcloud and sign in with their directory credentials, and Nextcloud also documents OpenID Connect and SAML user authentication backends. Mail, chat and video would each need their own login path, so you must map every component to the same directory before go-live.

Confirm three things in writing with ZenDiS or your implementation partner before you commit to either route. First, how federation with your external identity provider handles user attributes, group membership and any group sync that the suite expects, including which of those features sit in the Enterprise Edition. Second, how Nextcloud's LDAP or SAML configuration maps your directory groups to Nextcloud roles and group folders, and how the same groups reach Element, OX App Suite and Jitsi if you build those yourself. Third, offboarding: test that disabling a leaver in the directory removes access to every component, including active sessions, shared links and any local accounts left behind by a tool that was not federated.

Run a short proof of concept with a test directory containing a leaver, a mover and a contractor with a time-limited account. Record which application still accepts the leaver's session after the directory change. That result will often decide the identity design more than any feature list, and it gives your directory team a concrete acceptance test to repeat in your own environment.

The longest delays on either route rarely come from the application itself. They come from platform readiness: openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later, and it is tested on kubespray clusters but not on OpenShift. Confirm early whether your platform team already operates a cluster that meets these conditions, because cluster upgrades and ingress decisions can stall a project before any suite is installed. A Nextcloud route on a single virtual machine or the All-in-One method avoids that dependency, but a Kubernetes-based Nextcloud deployment (including the Helm chart referenced in the All-in-One project) brings the same cluster questions back.

The second driver is external service provisioning. openDesk expects production-grade PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server to be supplied outside the suite. Each one needs an owner, a backup policy and a network path. On the Nextcloud route, the equivalent work is choosing database engines from the supported matrix for Nextcloud 35, sizing caching, and adding mail, chat and video services as separate systems. Ask who will operate each external service after handover, and whether that team has been named in the plan. The third and fourth drivers are identity federation and the Enterprise support decision. openDesk relies on Nubus for portal and identity, and its federation with an external identity provider is a documented configuration path that should be tested against your directory before go-live. On Nextcloud, LDAP or Active Directory, OpenID Connect and SAML are separate configuration choices that must agree with each other. Decide early whether production will run on Enterprise editions, since ZenDiS recommends openDesk Enterprise Edition for production and Nextcloud Enterprise tiers carry their own minimums and support terms. Changing that decision after a pilot can mean reworking identity and patch processes.

On the Nextcloud route, the largest unplanned work is integrating separately sourced mail, chat and video. Nextcloud Hub gives you files and office features, but groupware, messaging and conferencing need their own selection, hosting, identity mapping, single sign-on and support contracts. Illustratively, if the mail platform, chat server and video bridge each come from a different vendor, every pair of systems needs its own tested integration and its own upgrade calendar. Nextcloud also requires one major version upgrade at a time, with backups and third-party app checks before each step, so every integration must survive those upgrades. Ask for a written integration inventory and an upgrade plan covering each component before the scope is fixed.

DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. For this decision that can mean scoping an openDesk deployment onto a CNCF-certified Kubernetes cluster and its required services, or building a Nextcloud Hub stack and connecting mail, chat and video to it. DeployOpen can also help you test the assumptions behind either path, such as whether your identity source, storage backends and upgrade calendar fit the option you pick. The choice itself stays with your team. DeployOpen does not favor either platform, and its work is the same whichever one you choose.

Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. A written scope should name the components in play, the Kubernetes or hosting footprint, the identity integration, the backup and restore approach, the upgrade path across major releases and who handles second and third level support. Ongoing support, upgrades and continuous testing are available as retainers, which matter most when you run a platform that moves between major lines on a published schedule. Ask any provider, DeployOpen included, to state which tasks sit in the fixed scope and which recur under a retainer, and to name the vendor support you still need to buy separately.

DeployOpen does not issue audit reports, attestations or certifications. Where your regulator or assessor expects evidence, DeployOpen can prepare systems, controls and documentation for an independent auditor or certification body to review, but the assessment outcome comes from that body. DeployOpen does not publish a price list. A quote follows from the written scope, so the useful next step is to bring your target architecture, user count, required editions and compliance obligations to a scoping conversation and compare the written proposals you receive.