Infrastructure requirements for a self-hosted digital workplace suite

Infrastructure requirements for a self-hosted digital workplace suite start with the platform underneath

A regulated or public body that must run files, office, mail, chat, video, wiki and projects in its own infrastructure needs to settle the hosting layer before choosing applications. The production footprint of openDesk is set by a supported Kubernetes cluster plus a set of external services, and the evaluation hardware is not the production design. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm and Helmfile. It is tested on kubespray clusters and not on OpenShift, so an OpenShift estate is a decision to make early, not a detail to resolve during rollout.

The infrastructure decision comes first because it determines what the suite can run on, who operates it and how upgrades will happen. openDesk ships monthly minor releases and only the latest minor is supported, so the cluster lifecycle, the Kubernetes upgrade calendar and the team that owns both must be agreed before go-live. Confirm with ZenDiS which Kubernetes minor version the current openDesk release targets, and check that your platform team can keep pace with that cadence. The Nextcloud-centred alternative shifts the weight toward the same questions: Nextcloud Server is AGPL-3.0 and can be deployed on several hosting models, so the same requirements for database, cache, storage and identity still apply, but the Kubernetes dependency is a design choice rather than a fixed requirement.

The fastest way to surface gaps is an inventory of the external services openDesk expects in production, each with a named owner. The list includes PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Assign each one to the platform team, the messaging team or a managed service provider, and write down who patches it and who restores it. Ask your implementation partner how the Enterprise Edition support boundary applies to these services and which ones remain your responsibility, since support terms for the external layer are often where production readiness stalls.

Which infrastructure requirements apply and where they come from

This table lists each platform requirement openDesk expects, the source that sets it, and what it means for your build. Read it as a checklist: the first rows are hard prerequisites for the cluster, and the later rows are external services that you must provide, host and operate yourself for production.

Requirement	Source and value	What it means for the build
Kubernetes version	openDesk requirements docs: CNCF-certified cluster at v1.33 or later	Pick a conformant distribution on a supported minor. Confirm the upgrade path from your current version, since skew rules require one minor version at a time.
Ingress controller	openDesk requirements docs: haproxy-ingress or the deprecated Ingress nginx	Choose haproxy-ingress for new builds. Plan TLS termination and certificate handling for every public hostname.
cert-manager	openDesk requirements docs	Automates certificate issuance inside the cluster. Confirm who owns the internal CA or public issuer and the renewal process.
RWO volume provisioner	openDesk requirements docs	Provides ReadWriteOnce storage for stateful pods. Confirm backup and snapshot support with your storage team before go-live.
Helm and Helmfile	openDesk requirements docs: Helm 3.17.3 or later below v4, Helmfile 1.0.0 or later	Deployment is driven by these tools. Pin versions in your pipeline and mirror charts if the network is disconnected.
PostgreSQL	openDesk requirements docs: PostgreSQL 15	An external, production-grade database service. Your DBA team or managed service provider runs backups, failover and patching.
MariaDB	openDesk requirements docs: MariaDB 10	Required for components that use MariaDB. Assign an owner for backups and version lifecycle alongside PostgreSQL.
Redis and Memcached	openDesk requirements docs: Redis 7 and Memcached	Session and cache layers sized to concurrent users. Plan monitoring and memory limits, and confirm high availability needs.
Cassandra	openDesk requirements docs	A separate distributed datastore that adds operational load. Confirm with the openDesk release notes which components depend on it in your version.
SMTP relay	openDesk requirements docs	Outbound mail for notifications and invitations. Confirm the sending domain, SPF, DKIM and DMARC records, and who manages the relay.
ClamAV over ICAP	openDesk requirements docs	Scans uploaded files. Size it for peak upload volume and decide how scan failures are handled for file sharing and mail paths.
Object storage	openDesk requirements docs	Holds bulk file data for components that use it. Confirm the S3-compatible product, encryption at rest, and where data physically resides.
TURN server	openDesk requirements docs	Relays media for calls behind restrictive networks. Plan public or internal reachability, and firewall rules for the relay ports.
ARM and OpenShift	openDesk requirements docs: ARM not supported yet; tested on kubespray clusters, not OpenShift	Build on x64 nodes with a kubespray-style distribution. Ask any partner to confirm support for other distributions in writing before you commit.

Evaluation hardware versus production design

The evaluation deployment is the smallest footprint the openDesk requirements describe: 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk. ARM hardware is not supported yet, so the evaluation cluster must run on x64 nodes. This footprint is useful for confirming that the components install, that the identity layer and portal start, and that a team can work through the Helmfile and Helm flow on a test cluster. It is a functional check, not a sizing basis.

Functional proof only: It shows that the bundled components deploy and talk to each other on your chosen Kubernetes version.
Single small cluster: All services share one small pool of nodes, so resource contention is not representative of production.
Bundled or lightweight data services: Evaluation setups do not replace the external production services that openDesk expects.
No backup or restore test: A successful install says nothing about how etcd, databases or object storage would be recovered.
No upgrade rehearsal: Monthly minor releases must still be applied and tested before production.

Before relying on this footprint, confirm with ZenDiS or your implementation partner which components are included in the evaluation profile and what user count it was intended to exercise.

Which platforms fit this infrastructure and why

The right platform depends less on feature lists than on what your infrastructure can host and operate. The cards below compare the full openDesk stack on Kubernetes with a narrower Nextcloud-centred stack, then show how the components openDesk bundles each carry their own license and support model.

openDesk as the full stack

openDesk is a Kubernetes-based suite covering files, office, chat, video, wiki, project management and identity under one portal. It fits organizations that can run a CNCF-certified cluster at v1.33 or later and want one deployment pipeline for the whole workplace. Check whether your platform team already operates ingress, cert-manager and an RWO volume provisioner, and whether you can run the external PostgreSQL, MariaDB, Redis, object storage and TURN services it expects in production. Plan for monthly minor releases, since only the latest minor version is supported.

Nextcloud-centred stack for files and office

A Nextcloud-centred stack covers files, sync, sharing and browser-based office with a smaller set of services than the full openDesk footprint. It suits organizations without a Kubernetes platform team, or those that need to add file and office capabilities to an existing workplace first. Confirm which sync clients, office engine and identity connector you need, and whether the operating model can absorb a separate chat, video and project stack. Nextcloud Server is licensed under AGPL-3.0, so review how modifications you distribute are handled.

Nextcloud and Nubus under AGPL-3.0

Nextcloud and Nubus, which handles portal and identity in openDesk, are both licensed under AGPL-3.0. The network-use clause of that license matters when users reach these services through a portal you modify or host for others. Ask your counsel to review whether any internal change to these components creates source obligations. Check the Nubus identity layer against your directory plan before committing to federation design.

OpenProject and XWiki under open licenses

OpenProject is licensed under GPL-3.0 and covers project and portfolio management. Its Enterprise add-ons are sold separately and are not part of the open core. XWiki supplies the wiki inside openDesk, and its Pro apps are Enterprise-only. Before sizing storage and database capacity, list which of these add-ons your teams need, because they change both support scope and the licensing you sign.

Element, Jitsi and Collabora for real-time work

Element provides chat and Jitsi provides video, and Collabora serves as the web office component. Collabora is licensed under MPL-2.0 and Jitsi Meet under Apache-2.0. Real-time traffic depends on TURN, SMTP relay and network paths you control, so confirm bandwidth, firewall rules and TURN placement with your network team. Enterprise-only features include Collabora branding and automatic load scaling, so check whether you need them before finalizing capacity.

Open core and Enterprise editions

openDesk is Apache-2.0 for its deployment automation, and each bundled component keeps its own license. ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules and SLA-backed second and third level support, sold as SaaS or for on-premises installation. Ask which Enterprise-only features your deployment depends on, such as GroupSync, Admin Console and the Nextcloud Guard app, and confirm which support tier covers each component.

Who operates each external service

openDesk in production depends on a Kubernetes platform plus several external services that the suite expects you to provide. Each one needs a named operator, a clear failure mode that users will notice, and a check against your own environment before the design is final.

Kubernetes control plane and etcd

openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, so the control plane and its etcd members must be run by a team that can upgrade them one minor version at a time. Take etcd snapshots with etcdctl snapshot save and test restores with etcdutl, because a lost etcd member without a tested backup removes the cluster state the suite depends on. Also confirm that Kubernetes Secrets are stored unencrypted in etcd by default, so encryption at rest must be configured before any openDesk credentials are created. Confirm who holds the on-call duty for control plane incidents.

Databases and caches

Production openDesk expects external PostgreSQL 15, MariaDB 10, Redis 7, Memcached and Cassandra services rather than in-cluster test instances. Ask whether your database team will provide these as managed or self-run services, who performs patching and point-in-time recovery, and whether backups are tested. If a cache or database is unavailable, users see failed logins, stalled file operations or lost edits across several apps at once, so map each database to the applications that depend on it.

Object storage

Files, attachments and some office data need object storage outside the cluster, and the storage team must agree on bucket layout, access keys, retention and encryption before rollout. Confirm whether the storage platform is operated by your infrastructure team, a cloud provider or a storage vendor, and who rotates the credentials. Losing or misconfiguring this service stops uploads and downloads, and it can make restored backups incomplete if the database and bucket copies drift apart.

SMTP relay and mail flow

openDesk expects an SMTP relay for notifications and outbound mail from its applications. Decide whether your mail team, an existing relay or a managed provider owns sending domains, SPF, DKIM and DMARC records, and bounce handling. The failure that reaches users is silent: password resets and meeting invitations never arrive, and the help desk hears about it before the platform team does. Confirm that the relay accepts traffic from the cluster network and that its logs are retained for your audit needs.

ClamAV over ICAP

File uploads in the suite are scanned through ClamAV reached over ICAP, so antivirus is a runtime dependency, not an optional add-on. Confirm who keeps the signature database current, who sizes the scanning service for peak upload volume, and whether your security operations team receives its detections. If the scanner is down or unreachable, the upload path can fail for users, and a scanner that is bypassed creates a malware entry point that auditors will ask about.

TURN server for calls

Video and audio sessions in the suite need a TURN server so that participants behind restrictive firewalls or NAT can connect. The network team usually owns the public address, port ranges and TLS certificates, while the platform team owns the configuration that the suite uses. Confirm the firewall rules, the certificate renewal process and whether traffic stays inside your borders. When TURN fails, calls connect for some users on the office network and fail for remote or guest users, which is hard to diagnose from the application side.

Which Kubernetes version and tooling to standardize on

Standardize on a CNCF-certified Kubernetes cluster at v1.33 or later, because that is the floor openDesk currently requires. Kubernetes ships roughly three minor releases a year, about 14 weeks apart, and the project supports only the three most recent. As of September 2026 those are 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Pick a version inside that window that your distribution vendor supports, and confirm with the vendor that the chosen distribution passes CNCF conformance and is tested with openDesk. The openDesk requirements list kubespray-based clusters as the tested path and does not list OpenShift, so an OpenShift estate needs explicit confirmation before any commitment. Also confirm the 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.

Plan the upgrade path before go-live. The version skew policy requires kube-apiserver to move one minor version at a time, ahead of kube-controller-manager, kube-scheduler and kubelets, and kubelets may run up to three minors behind the API server. That gives you room, but openDesk ships monthly minor releases and supports only the latest minor, and in-place upgrades between majors are not guaranteed. Each openDesk minor may pull a newer Kubernetes API expectation, so track both release trains together. Rehearse every upgrade in a non-production cluster, and ask the implementation partner how skipped minors and intermediate steps are handled. For the control plane, the kubeadm guide describes a stacked topology (etcd on the control plane nodes) or an external etcd cluster. Use at least three control plane nodes behind a TCP load balancer on port 6443, and run etcd with an odd member count, five members in production per Kubernetes guidance. Back up etcd with etcdctl snapshot save and rehearse restores with etcdutl. Administrators authenticate with X.509 client certificates, OpenID Connect or other bearer tokens, webhook token authentication or an authenticating proxy, and Kubernetes does not manage ordinary users as objects. Decide early whether admin access flows through your central IdP, enable encryption at rest for Secrets (they are unencrypted in etcd by default), and restrict list and watch rights with least-privilege RBAC.

How the infrastructure rollout runs in phases

The rollout moves from requirements and sizing to a hardened cluster, external services, an evaluation deployment and finally a production build that has passed a restore test and an upgrade rehearsal. Each phase produces a signed-off artifact, so the production environment is only declared ready once its backups and upgrade path have been proven.

Run the requirements and sizing workshop
DeployOpen and your architects, identity owners, security team and service owners agree which openDesk components are in scope, the expected user count, the edition decision (Community or Enterprise), the hosting location and the operating model for each component. The workshop also records who operates the Kubernetes platform, the databases, object storage, SMTP, ClamAV and TURN. The output is a signed requirements register with a sizing sheet and a responsibility matrix that names an owner for every external service. Confirm the sizing figures against the current openDesk requirements documentation before you commit to hardware.
Build and harden the Kubernetes cluster
Your platform team, with DeployOpen support, builds a CNCF-certified cluster at the Kubernetes version that the openDesk requirements specify, with the required ingress controller, cert-manager, an RWO volume provisioner, Helm and Helmfile. For production, the control plane is designed as a highly available topology with a load balancer in front of the API server and an etcd plan that includes snapshot backups. Namespaces get Pod Security Standards labels, Secrets encryption at rest is enabled, and the cluster is checked against the CIS Kubernetes Benchmark as a reference. The output is a cluster that passes the conformance checks and a hardening report listing each deviation and its accepted risk.
Provision external services and connect them
The external services that openDesk expects are provisioned in your environment: PostgreSQL, MariaDB, Redis, Memcached, Cassandra, object storage, an SMTP relay, ClamAV reachable over ICAP and a TURN server. Each service is deployed with its own backup schedule, access controls and monitoring, and the cluster can reach it over private network paths only. Credentials are created and stored in your secrets manager, not in chart values. The output is a connectivity test per service, a backup job that has run at least once for each stateful service, and a list of owners and escalation paths.
Deploy the evaluation environment
DeployOpen deploys openDesk into a non-production namespace or cluster using the Helmfile-based deployment, then runs the functional checks for files, office editing, mail, chat, video, wiki, projects and the identity layer. Identity federation is tested with a small set of test accounts before real users are involved. The team logs the test results, the error findings and any configuration decisions that will carry into production. The output is a passing functional test report and a list of configuration changes that the production build must reproduce exactly.
Build the production environment with backups
The production cluster is built from the same versioned Helmfile and chart configuration that passed the evaluation, with production values, certificates, DNS and external service endpoints set for your domains. Backups cover the Kubernetes etcd data, the stateful openDesk services and object storage, with retention periods that match your policy. Monitoring, log forwarding and alerting are wired to your security operations team. The output is a production environment with a configuration baseline in version control and a backup inventory that lists what is protected and where copies are stored.
Run the restore test
The team restores the most recent backups into an isolated environment and checks that the restored services start, that data is readable and that identity, files and mail work together. For the etcd layer, the restore follows the documented snapshot and restore procedure. The restore is timed and each failed step is recorded as a finding with an owner. The output is a restore test report signed by the service owners, with a documented recovery sequence. Until this report exists, the environment should not be treated as production-ready.
Rehearse the upgrade path
Because openDesk publishes minor releases monthly and only supports the latest minor version, the team rehearses an upgrade in a staging copy of production before the first live change. The rehearsal follows the openDesk release management guidance, checks Kubernetes version skew rules, and includes intermediate steps if several minor versions are skipped. The team confirms that the upgrade runbook, rollback approach and change window are approved by your operations owners. The output is a tested upgrade runbook, a rollback procedure with its own check, and an agreed cadence for applying future releases.

Infrastructure evidence auditors and regulators ask for

This table maps each piece of evidence an assessor is likely to request to the component that produces it, and to the regulatory reference it supports where one applies. Read it as a checklist of what to export, retain and test before an assessment, not as a statement that any control is met. DeployOpen prepares these systems and records, while independent auditors and certification bodies decide whether the evidence is sufficient.

Evidence	Produced by	Regulatory reference	What to confirm
Cluster configuration and RBAC exports	Kubernetes API server and cluster admin tooling	General access control expectations in NIS2 and ISO-aligned audits	Export roles, bindings and service accounts on a schedule and store them outside the cluster
etcd snapshot and restore records	etcdctl snapshot save and etcdutl restore runs	Backup and recovery expectations in operational resilience reviews	Snapshot timestamps, storage location and a restore test log from a separate cluster
Secrets encryption configuration	Kubernetes encryption at rest settings and any external secrets store	Protection of credentials at rest in access control reviews	Encryption provider configuration, key rotation records and who can read Secrets
API server audit logs	Kubernetes audit policy and log backend	45 CFR 164.312(b) audit controls where ePHI is hosted	Audit policy scope, log retention period and the process for reviewing entries
Application audit records for ePHI, files and chat	openDesk components such as Nextcloud, Element and Mail services	45 CFR 164.312(b) audit controls and 17 CFR 240.17a-4(b)(4) for retained communications	Which apps log access and changes, whether logs leave the cluster, and retention settings
TLS configuration for mail and chat	Ingress controller, SMTP relay and TURN server certificates	45 CFR 164.312(e)(1) transmission security for ePHI	Protocol versions, cipher settings, certificate expiry tracking and internal service encryption
Image and chart pinning records	Helmfile and Helm lock files, mirrored registry manifests and image digests	Supply chain expectations in NIS2 risk-management measures	Pinned chart versions and image digests, signature verification steps and the mirror source for each release
Retention settings for regulated mail and chat	Mail server, chat server and archive storage	17 CFR 240.17a-4(b)(4) preservation of business communications for not less than three years, where broker-dealer rules apply	Retention periods per mailbox or channel, immutability controls and proof of restore

How the cluster identity connects to the workplace identity layer

Two identity paths run through a self-hosted openDesk cluster, and they should be designed separately. End users sign in to the workplace through Nubus and any federated identity provider, while the people who operate the cluster authenticate to the Kubernetes API. Kubernetes does not store normal users as API objects. It accepts X.509 client certificates, bearer tokens (including OpenID Connect and JWT), webhook token authentication or an authenticating proxy, so a user who can sign in to Nextcloud has no cluster access by default. Decide which mechanism your platform team uses for kubectl and Helmfile runs, for example OIDC through your corporate identity provider with short-lived tokens, and confirm with the cluster distribution vendor how group claims map to RBAC bindings. Keep break-glass credentials for the control plane outside the workplace identity layer, so that a failed Keycloak or Nubus deployment does not lock out the people who must repair it.

Secrets need the same separation. The openDesk deployment carries database passwords, SMTP credentials, object storage keys and TURN secrets, all of which Kubernetes stores as Secrets. Per the Kubernetes secrets good practices, Secrets are stored unencrypted in etcd by default, so confirm that encryption at rest is configured for the API server before any production data lands. Restrict list and watch on Secrets to the smallest set of service accounts and operators, because reading a Secret through those verbs exposes every value in the namespace. Where your security team already runs an external vault, the Secrets Store CSI Driver can mount values from that store into pods instead of copying them into etcd. Confirm with ZenDiS and your distribution which bundled charts accept externally sourced secrets, since that determines how much of the design you can change without forking the deployment.

What do buyers ask about hosting openDesk in production?

What does it cost to run openDesk in production and what drives the cost?

The cost comes from four places: the Kubernetes cluster and its underlying compute and storage, the external production services openDesk expects, the people who operate it, and any Enterprise subscription. The cluster and external services are largely recurring infrastructure costs you pay to your cloud provider or data center. Operations staffing recurs every year. ZenDiS recommends openDesk Enterprise Edition for production, which adds SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation, so ask whether the quote includes it. Ask any implementation partner for a written breakdown that separates one-time work (design, installation, hardening, migration) from recurring items (infrastructure, licenses, support, upgrades). Costs rise with user count, number of components enabled, high availability requirements and the number of environments.

How long does a production openDesk deployment take?

The timeline depends on drivers you can assess before signing: whether the Kubernetes platform already exists and meets the required version, how many external services must be provisioned from scratch, how identity is connected to your existing directory, how many components are enabled, and how much data must be migrated from current tools. Approval processes in regulated organizations, change windows and the availability of staff from identity, network and storage teams often matter as much as technical work. Ask for a fixed-scope plan with milestones and dependencies written out, and confirm which items you must provide, such as hardware, DNS, certificates and directory access.

Can our own platform team run openDesk without an outside partner?

A capable platform team can run openDesk, but it needs to own a broader set of skills than a single application. The deployment is Helmfile and Helm based, runs on Kubernetes, and expects you to operate PostgreSQL, MariaDB, Redis, Memcached, Cassandra, an SMTP relay, ClamAV, object storage and a TURN server. Many organizations split this work: their own team runs the cluster and day-to-day operations, while a partner handles installation, customization, integration, hardening, backup design and upgrade rehearsal. Decide which parts you will staff in-house before choosing between build, partner or a mixed model, and confirm this in writing with any partner.

What skills, network, storage and identity does openDesk need from our team?

openDesk needs 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. Your team should be able to operate:

Kubernetes control plane, etcd backups and node upgrades, including the version skew rules
Storage classes, backups and restore tests for stateful services
Network design for ingress, DNS, TLS certificates and outbound access to a TURN server
Identity integration, including OIDC or directory federation with your existing identity provider
Secrets management, since Kubernetes stores Secrets unencrypted in etcd by default unless you configure encryption at rest

Confirm each item against the current openDesk requirements before purchasing hardware.

Does openDesk run on OpenShift?

Not as a tested configuration. The openDesk requirements state that it is tested on kubespray clusters and not on OpenShift. If your organization standardizes on OpenShift, treat this as a design question to resolve early: ask the partner and ZenDiS what changes would be needed, who would validate them, and whether those changes would be covered by support and by future upgrades. Do not assume that an OpenShift cluster is supported because it is Kubernetes based.

What happens when openDesk releases a new minor version every month?

openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, in-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps. This makes a repeatable upgrade process essential: a staging environment that mirrors production, a documented rollback plan, and a set schedule for applying minors. Ask your partner whether upgrades are included in a retainer, how they test each release against your bundled components and integrations, and how long a rehearsal takes in your environment. Also check the Kubernetes side, since the cluster must stay within supported minor versions.

Questions to ask an implementation partner about production hosting

The first question a CIO or platform lead should put to a partner is which Kubernetes distributions the partner has deployed openDesk on, and whether that work was done on kubespray clusters or on CNCF-certified distributions. openDesk is tested on kubespray clusters and not on OpenShift, and it needs Kubernetes v1.33 or later with an ingress controller, cert-manager and an RWO volume provisioner. Ask the partner to name the distribution, the Kubernetes minor version it will run, and who is responsible for the cluster itself, since that choice decides which of the requirements are the partner's problem and which are yours. Confirm in writing that the cluster build sits inside the written scope or is excluded from it.

The second group of questions covers the external services that openDesk expects in production: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. For each one, ask how the partner will provision it, who holds its backups, and what restore test it has run. Ask for an etcd backup and restore demonstration using etcdctl snapshot save and etcdutl, performed on a non-production cluster, and ask whether the same proof will be repeated after each upgrade. A partner that cannot show a restore has not shown a backup.

The third group concerns Enterprise Edition, upgrades and on-call. Ask whether the partner recommends openDesk Enterprise Edition for production, which ZenDiS describes as the supported path with 2nd and 3rd level support, and how the partner handles the Enterprise-only registry and license file. Ask how often the partner rehearses upgrades against monthly minor releases, and whether skipped minor versions are tested. Finally, ask for a named on-call owner for each service, including the database tier, TURN and antivirus, and confirm in the written scope which of those owners are the partner and which are your own staff.

How DeployOpen scopes and runs the production infrastructure

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an openDesk production cluster, that means turning the Kubernetes, external service and operating requirements into a written scope before any build work starts.

How we scope

Written scope listing the Kubernetes version, ingress, certificate and volume components your cluster must provide
Inventory of external PostgreSQL, MariaDB, Redis, object storage, SMTP, antivirus and TURN services, with an owner for each
Agreed decisions on evaluation or production sizing, edition and which team operates each component

How we build

Deployment of the Helmfile and Helm based openDesk stack onto your own Kubernetes cluster, with configuration recorded per environment
Hardening of cluster access, secrets handling and encryption at rest for etcd and Kubernetes Secrets in line with the agreed scope
Testing of backup and restore for etcd and the external databases, and of each service's connection to the others before go-live

How we hand over

Runbooks covering installation, upgrade steps between minor releases, backup schedules and restore procedures for each service
Documentation of which services run in your environment, their licenses, versions and the evidence each one produces
Handover session with your platform, database, mail and security teams, recorded against the written scope

How we support

Fixed-scope engagements with deliverables and timelines agreed in writing before work begins
Ongoing support, upgrades and continuous testing available as a retainer, including planning for openDesk minor releases
Quotes follow from the written scope, so ask for line items covering cluster, external services and operations

Infrastructure requirements for a self-hosted digital workplace suite