What an openDesk implementation plan covers
An openDesk implementation plan is not a single install. openDesk is a Helmfile and Helm based suite for Kubernetes that bundles several open-source components, including Element with Nordeck widgets, Nextcloud, OX App Suite, XWiki, Nubus, OpenProject, Jitsi, CryptPad and Collabora. The plan therefore has to cover four areas before any chart is deployed: the Kubernetes cluster, the external production services, the choice of components, and the identity layer. Each of these carries its own decisions, owners and lead times.
The usual triggers are a public administration or regulated body moving off a commercial workplace suite, or an organization standing up a sovereign workplace under its own control. In both cases the plan should name who owns the cluster after go-live, which services are hosted in the organization's data center or cloud accounts, and which bundled components are in scope for the first wave. A staged rollout with pilot groups is a better fit than a big-bang cutover, because each stage tests identity, storage, mail and chat against real users.
Short answer on in-house or partner: plan in-house when your platform team already runs production Kubernetes, has operated PostgreSQL, Redis and object storage at production grade, and can staff an identity project. Plan with a partner when those skills are thin, when the rollout is tied to a fixed date, or when the organization needs an independent scope and written deliverables. Confirm the cluster version, ingress choice and external service versions against the current openDesk requirements before you size either option.
What the planning and implementation work includes
A written openDesk scope should name each workstream below, the owner for each decision, and the deliverables the client keeps after handover.
Target architecture on Kubernetes
Planning fixes the cluster version, ingress controller, cert-manager, RWO volume provisioner and Helm and Helmfile versions before any install. openDesk requires a CNCF-certified cluster at v1.33 or later and is tested on kubespray clusters, not OpenShift. Confirm these prerequisites against your own platform in week one.
External production services
Production openDesk expects services it does not bundle: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each one needs a sizing decision, a backup owner and a hosting location inside your infrastructure. Ask who operates each service after go-live.
Component selection across the suite
openDesk bundles Element, Nextcloud, OX App Suite, XWiki, OpenProject, CryptPad, Jitsi and Collabora, and each keeps its own license, including AGPL-3.0, GPL-3.0 and MPL-2.0 terms. The scope should record which components are enabled, which are deferred and which license obligations your legal team must review.
Identity setup and federation
Decide early whether users come from your existing identity provider over OIDC, from LDAP or Active Directory through the Nubus Directory Importer, or from both. Entra ID needs Azure AD Domain Services for LDAP access. Confirm the attribute used to match accounts, such as username or mailPrimaryAddress.
Pilot groups and staged rollout
The scope should name pilot user groups, their entry criteria, the features they test and the exit criteria that allow wider rollout. Pilot feedback often changes naming, group mapping and mail or calendar settings, so the plan should reserve time for those changes before the broader wave starts.
Handover and operating model
Handover moves ownership of the running platform to your team. It covers the upgrade approach under openDesk's monthly minor releases, where only the latest minor is supported, and the choice between Community and Enterprise support. Agree in writing who receives access, training and on-call duties.
Deliverables the client receives
Expect a deployment plan, a configuration repository, runbooks for routine and failure procedures, and a pilot report with open findings. Ask the vendor to state the format of each deliverable, who owns the repository after handover, and whether the runbooks cover the external services as well as the openDesk charts.
What drives the cost and duration of an openDesk rollout
This table lists the factors a written quote for an openDesk rollout must reflect, why each one moves effort or duration, and how the client can keep each one under control.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| User count and tenant structure | Every user, group and tenant needs identity mapping, licensing checks, pilot testing and support. Multiple tenants or organizational units multiply configuration and role design work. | Start with a defined pilot group, reuse one tenant model where possible, and confirm how many tenants are truly needed before the build starts. |
| Bundled components in scope | Each component (for example Element, Nextcloud, OX App Suite, XWiki, OpenProject, Jitsi, Collabora, CryptPad) has its own configuration, integration points, testing and operations tasks. Dropping a component reduces scope at every stage. | Agree the component list in writing, phase in components that are not needed for the first wave, and confirm which bundled features the organization will actually use. |
| External services to build or connect | Production expects PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each service that does not already exist must be provisioned, sized, backed up and monitored. | Reuse existing managed or internally supported services where they meet the required versions, and confirm early which services the client already operates. |
| Identity source and federation model | Connecting an existing OIDC identity provider, syncing users from LDAP or Active Directory with the Nubus Directory Importer, or handling Entra ID through Azure AD Domain Services each adds design, testing and attribute-mapping work. | Decide the authoritative identity source early, confirm the matching attribute (such as username or mailPrimaryAddress), and avoid parallel identity stores. |
| Integrations with existing systems | Mail, calendar, file shares, HR data, ticketing and monitoring connections each need interface design, credentials, test cases and error handling. Each external system adds a separate owner to coordinate with. | List every required integration in the scope document, mark which are needed for go-live, and defer nice-to-have connections to a later phase. |
| Environments (evaluation, staging, production) | The evaluation deployment has low hardware minimums, but a production-like staging environment must mirror the external services and identity setup. Keeping three environments aligned adds build, test and change-control effort. | Use the evaluation environment only for learning, keep staging as close to production as the budget allows, and automate Helmfile deployments so environments stay consistent. |
| Edition choice: Community or Enterprise | ZenDiS recommends Enterprise Edition for production, which includes SLA-backed 2nd and 3rd level support, patches and Enterprise-only features. Community Edition has community support on openCode with no SLA, so the client carries more of the support and patch effort internally. | Compare the support model against the organization's internal skills and risk tolerance, and ask the vendor to confirm current Enterprise pricing and terms in writing. |
| Compliance evidence needs | Assessors may expect documented controls, image and chart signature checks, network policies, access reviews and patch records. Producing this evidence takes time on top of the technical build. DeployOpen prepares evidence but does not issue audit reports or certifications. | Ask early which control frameworks apply, agree the evidence list in the scope, and reuse openDesk's documented security settings rather than building custom documentation. |
Project phases and the output of each
The sequence moves from agreed requirements to a handed-over openDesk environment, with each phase closing on a named output that the client can check.
Run discovery and requirements workshops
DeployOpen meets your architecture, security, identity and business owners to record which openDesk components are in scope, expected user counts, data residency needs and existing systems to integrate. The phase closes with a signed requirements document that becomes the basis of the written scope and quote.
Check architecture and cluster readiness
The team checks your Kubernetes cluster against the supported version, ingress controller, cert-manager, RWO volume provisioner, Helm and Helmfile requirements, and confirms the external services you will provide. The output is a readiness report listing gaps, owners and the decisions still open, such as the ingress controller choice.
Deploy the evaluation environment
DeployOpen installs openDesk on the minimum evaluation hardware profile so that your team can test logins, the bundled applications and the deployment workflow before any production spend on external services. The output is a working evaluation instance with a list of findings that feed into the production design.
Build the production environment with external services
The team provisions the production-grade external services openDesk expects, including databases, cache, mail relay, antivirus, object storage and a TURN server, and configures openDesk against them with pinned chart and image versions. The output is a production build passing agreed smoke tests, with service ownership and backup responsibilities documented.
Configure identity and single sign-on
DeployOpen connects openDesk to your identity source, either through OIDC federation with your existing provider or through user provisioning from directory services, and tests attribute matching for every pilot user. The output is a tested login flow and a documented user lifecycle, including what happens when someone leaves.
Run pilot groups
A small set of named pilot users works in the production build for an agreed period, reporting defects, training gaps and integration issues against a tracked backlog. The output is a pilot report with resolved blockers, accepted limitations and a go or no-go recommendation for each wave.
Roll out in stages and hand over
Users move to openDesk in waves agreed in the scope, with support routes and runbooks in place for each wave. The phase closes with a handover package covering deployment repositories, Helmfile operations, monitoring, backup and restore tests, and the upgrade approach for your support model. Overall duration depends on the agreed scope, and the written plan will state the timeline.
Which parts teams keep in-house and which they outsource
The table compares the openDesk rollout work that the client's platform team usually keeps with the work partners often take on, and lists the skills each row needs so you can match them to your staff.
| Work area | Usually kept in-house | Often outsourced |
|---|---|---|
| Business owners and pilot users | Naming accountable owners, choosing pilot departments and deciding which teams move first. Needs change management and knowledge of the organization's processes. | Drafting the pilot communication plan and onboarding guides. Needs change management and technical writing for a public-sector audience. |
| Data decisions | Deciding what data moves, retention periods, classification and who may access which workspaces. Needs records management and data protection expertise. | Mapping the data model to openDesk components and scripting bulk loads. Needs Nextcloud, OX App Suite and XWiki administration. |
| Network and DNS approvals | Approving firewall rules, DNS zones, certificates and egress paths through your change board. Needs network security and internal governance knowledge. | Documenting required ports, ingress routes and TURN and SMTP endpoints for the approval request. Needs ingress controller and networking skills. |
| Day-to-day administration | Handling user tickets, password resets, group membership and routine app settings after go-live. Needs service desk and application administration skills. | Building runbooks and admin tooling for the team to use. Needs Helm and Helmfile operations and knowledge of the Nubus and Keycloak admin consoles. |
| Cluster hardening and sizing | Reviewing the security baseline and approving capacity decisions against your standards. Needs Kubernetes security review skills. | Setting up the CNCF-certified cluster, sizing nodes and applying network policies and pod security settings. Needs Kubernetes operations, kubespray and hardening experience. |
| Helmfile configuration | Confirming image sources, chart versions and release channel policy. Needs software supply-chain governance knowledge. | Writing and testing the Helmfile environment files and secrets handling. Needs Helm 3, Helmfile and GPG and cosign verification skills. |
| External service build | Choosing hosting model for PostgreSQL, MariaDB, Redis, object storage and SMTP, and owning their backup and recovery targets. Needs database and storage ownership. | Deploying and tuning PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, ClamAV and TURN for openDesk. Needs PostgreSQL administration, Redis and Cassandra operations. |
| Identity federation | Providing the existing identity provider, attribute choices and group mappings. Needs directory and identity governance knowledge. | Configuring OIDC federation to the openDesk Keycloak IdP and the Nubus Directory Importer. Needs identity protocols (OIDC, LDAP) and Keycloak administration. |
| Pilot coordination | Running the pilot calendar, collecting feedback and signing off each wave. Needs stakeholder management and programme governance. | Preparing test accounts, test scripts and defect triage for pilot groups. Needs test engineering and Kubernetes log analysis. |
What usually goes wrong and how to prevent it
Most openDesk delays trace back to platform prerequisites, sizing, identity ownership and pilot design that were settled late or not at all. Check each item before the implementation scope is signed.
Kubernetes below the v1.33 floor
openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later. Clusters built from an older standard image often reveal the gap only at deployment. Confirm the exact cluster version and distribution, including whether it is a kubespray-based build, before the quote is accepted, and scope a platform upgrade if the version falls short.
Ingress and cert-manager left unplanned
openDesk accepts haproxy-ingress or Ingress nginx, but Ingress nginx is deprecated, so choosing it creates a future migration. cert-manager, an RWO volume provisioner and the certificate authority also need a named owner. Decide the ingress controller, issuer and storage class during design, and record which team operates each one.
Production services sized from the evaluation profile
The evaluation minimum of 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk is meant for trying the suite, not for production. Production expects external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Ask for each service to be sized from user counts and concurrency.
Unclear ownership of the directory import
The recommended way to provision users from LDAP or Active Directory is the one-way Nubus Directory Importer. Because changes do not flow back to the source, someone must own deprovisioning, attribute mapping and the authoritative identity source. Microsoft Entra ID needs Azure AD Domain Services because it does not expose LDAP. Name the owner before the import is scheduled.
Pilots that skip production-like workloads
A pilot of a few enthusiastic users usually tests sign-in and chat but rarely tests large file transfers, shared document editing, mail volume or meeting load. Choose pilot groups that mirror the departments, file sizes and tools they will use, including the identity and mail flows they depend on. Agree in writing which scenarios must pass before each rollout wave starts.
Release cadence drift during rollout
openDesk ships minor releases monthly and supports only the latest minor version. A rollout that spans several months can fall behind, and skipping several minors may require intermediate steps. Schedule a named upgrade window in the rollout plan, track the current minor against the release notes, and confirm how upgrades are scoped in the quote.
How the rollout differs by starting point
A greenfield sovereign workplace starts with no Kubernetes platform, so the first phase builds the foundation that openDesk expects. The work is mostly platform engineering before any application configuration begins.
- Cluster build: Provision a CNCF-certified Kubernetes cluster at v1.33 or later, using a distribution your team can operate. The openDesk requirements list kubespray-tested clusters, and OpenShift is not tested.
- Supporting components: Install an ingress controller, cert-manager and an RWO volume provisioner, and confirm the Helm and Helmfile versions the release notes name.
- External services: Plan production PostgreSQL, MariaDB, Redis, Memcached, Cassandra, SMTP, ClamAV over ICAP, object storage and TURN from the start, since no bundled stand-ins are provided for production.
- Sizing: Ask the vendor or partner to size these services against your user count, not against the evaluation minimum.
An existing Kubernetes platform with spare capacity skips most of the platform build, but the main risk moves to shared-cluster boundaries and existing operating rules. The work centers on fit and isolation.
- Capacity check: Confirm that the spare capacity covers the openDesk workloads and their external dependencies, not only the application pods.
- Namespace and policy fit: Review existing network policies, pod security settings and admission controls, since openDesk documents its own requirements and these may conflict with current rules.
- Shared services: Decide whether existing PostgreSQL, Redis or object storage can host openDesk data, and who owns backup and restore for those services.
- Ingress and certificates: Check that the current ingress controller and certificate issuer match openDesk's expectations, or plan the change in a separate window.
A cluster that needs a distribution or version change first adds a platform project in front of the openDesk work. Its duration depends on the gap, so the first deliverable is a written list of differences.
- Version gap: Compare the current Kubernetes version with the v1.33 minimum. Plan the upgrade path on its own, and do not assume that a skipped version can be bridged in one step.
- Distribution gap: If the current distribution is not one the openDesk requirements list as tested, ask for a fit assessment before committing to a rollout date.
- Component gaps: Identify missing ingress, cert-manager or volume components, and decide whether they are added or replaced.
- Change control: Platform changes and openDesk installation usually need separate approvals, change windows and rollback plans, so the schedule should reflect both.
A deployment that must run in an air-gapped or restricted network depends on how images, charts and dependencies reach the cluster. Sourcing is the planning item that other starting points rarely face.
- Image and chart mirror: Plan an internal registry and chart repository that holds every pinned image and chart the release uses. openDesk pins images by tag and digest, so the mirror must preserve those references.
- Verification path: Confirm how GPG-signed charts and cosign-signed images are validated inside the restricted network, and who holds the keys.
- Update intake: Define how new monthly minor releases and on-demand patches are brought across the boundary, since the release model depends on it.
- External services: Confirm that SMTP, TURN, ClamAV and object storage are reachable only from approved internal addresses, and that no step depends on internet access during installation.
The Microsoft 365 or Exchange mail and file migration is covered on its own page, so it is not repeated here.
What the client needs to provide
Before work starts, the client must have a Kubernetes cluster that is CNCF certified at v1.33 or later. openDesk is tested on kubespray-built clusters and not on OpenShift, so an OpenShift estate needs a decision before scoping, not after. Confirm the distribution, version and conformance status with the vendor and your platform team. The operator workstation also needs Helm 3.17.3 or later (below v4) and Helmfile 1.0.0 or later. Confirm both versions against the openDesk release you plan to deploy.
The cluster also needs four platform pieces in place. Decide on the ingress controller early: haproxy-ingress, or Ingress nginx, which is deprecated. Install cert-manager and confirm it can issue the certificates your DNS plan requires. Provide a storage class backed by an RWO volume provisioner so stateful components can claim volumes. Name the team that will patch and upgrade the controller, the certificate issuer and the provisioner, because those upgrades affect every bundled service.
openDesk expects production-grade external services for its data layer. The list includes PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, object storage, ClamAV reachable over ICAP, an SMTP relay and a TURN server. For each service, name an owner, confirm the version and high availability model, and agree in writing who handles backups and restores. Confirm with the vendor which services your chosen component set requires, since the full list is not a bill of materials for every deployment. Record the owners in the scope before a quote is requested.
Identity and access need their own checkpoint. Confirm which identity source the rollout will use and whether the client can grant a read-only service account to the LDAP or Active Directory directory. Microsoft Entra ID does not expose LDAP, so an Entra-based estate needs Azure AD Domain Services or another agreed source. Name the DNS zone owners and the certificate authority. Finally, assign named business owners and a pilot group who can sign off acceptance before any user wave begins.
Questions buyers ask before hiring help
What drives the quote for an openDesk implementation?
The quote follows from the written scope, so the main drivers are the number of users and groups, how many bundled components you enable, the state of your Kubernetes cluster and external services, the identity integration, and the number of pilot waves and environments. Each one adds engineering time. Ask for one-time work (planning, build, pilot, cutover) and recurring work (upgrades, support, operations) as separate lines, along with the assumptions behind each line.
How long do planning and rollout usually take for openDesk?
Duration depends on scope, and no single figure fits every organization. Planning covers cluster readiness, external services, component selection and identity design. Rollout adds pilot groups and staged expansion. The biggest variables are how closely your cluster and services already match the requirements, how complex the identity federation is, and how many components and users sit in the first wave. Ask for a timeline in the written scope that lists milestones and the assumptions that could move them.
What must our organization provide before an openDesk project starts?
According to the openDesk requirements documentation, you need a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, and Helm and Helmfile at the supported versions. For production, you also need external services such as PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Add identity provider details, directory access, DNS, certificates, and named owners for decisions and testing.
Can our internal team deploy openDesk without an implementation partner?
Yes, a team with Kubernetes, Helm and identity skills can deploy it, since the deployment automation is Helmfile and Helm based and the project publishes its requirements and security documentation. The harder parts are usually the external services, identity federation, sizing, pilot coordination and upgrades. Minor releases arrive monthly, and only the latest minor version is supported. Assess whether your team can carry those tasks for the whole life of the platform, not just the first deployment.
Does Community or Enterprise support change the planning work?
Yes, mainly through who is accountable for production. The Community Edition is supported only by the community on openCode, with no SLA. ZenDiS recommends the Enterprise Edition for production, which includes SLA-backed 2nd and 3rd level support and patches, sold as SaaS or for on-premises installation. Enterprise also adds closed-source modules and features, such as Nextcloud Enterprise security patches, so plan the design around them. Confirm the edition and support terms in writing before the scope is fixed.
What does a fixed-scope openDesk agreement actually cover?
A fixed-scope agreement covers the work, deliverables and timeline written down before work starts, such as the components in scope, the environments, the identity integration, the pilot and the handover documentation. Work outside that written scope needs a change agreed in writing. Ask whether testing, documentation and training are included. Ongoing support, upgrades and continuous testing are available as separate retainers. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen scopes, delivers and hands over openDesk
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so an openDesk rollout runs in your cloud accounts, data centers or air-gapped network. Most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- The written scope lists the openDesk components in use, the Kubernetes target, and which external services you will run.
- We record the identity approach, such as federation with your existing identity provider or directory import, before any build begins.
- Pilot groups, rollout waves and acceptance criteria are written into the scope so you can see what a quote covers.
How we build
- We deploy the Helmfile and Helm configuration into your cluster and confirm prerequisites such as the ingress controller and cert-manager.
- We connect the external PostgreSQL, MariaDB, Redis, SMTP, ClamAV, object storage and TURN services that production requires.
- We test identity sign-in, component integrations and pilot-group access, and document each verification step we ran.
How we hand over
- You receive configuration, runbooks and documentation covering the deployment, the external services and the pilot rollout.
- We walk your operations team through upgrade steps, backups and Helmfile operations so the knowledge stays with your staff.
- Handover items are listed in the written scope, so you can check what was delivered against what was agreed.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover the monthly minor release cycle, since only the latest minor version of openDesk is supported.
- Ask any partner to confirm which support level your edition includes, and what response terms apply, before you sign.
