Open-Xchange for the public sector: why agencies run their own email
OX App Suite can run as sovereign groupware in infrastructure the agency controls, either as a standalone deployment or as the groupware component inside openDesk. For an agency IT lead, the case starts with a plain requirement: email and calendar hold sensitive records, so the agency must show where that data lives, who can reach it and who operates the systems that hold it. Running the platform in the agency's own cloud accounts, data center or air-gapped network places those answers under the agency's control and documentation, where an auditor or oversight body can examine them directly.
The first change is operational. OX App Suite v8 is designed to run on Kubernetes and ships as Helm charts that reference container images, with Helm 3.17.0 or newer required. The platform supports Kubernetes versions N-1 and N-2 and requires Istio, with a basic ingress-nginx option where Istio cannot be used. The agency's platform team therefore takes on cluster lifecycle, service mesh upgrades and ingress decisions. Confirm early whether the agency's cluster standard already includes Istio, because that choice shapes hardening, monitoring and upgrade work for the life of the deployment.
The second change is identity. OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware. The agency must decide which identity provider is authoritative for mailboxes, how joiner and leaver events reach the platform, and how administrative access is separated from everyday user access. Storage is the third decision. Redis 7.4.x handles caching and session storage, MariaDB with the InnoDB engine holds primary data, and OX Drive files and PIM attachments need a distributed file system. Confirm whether the agency already operates NFS or object storage such as Ceph RadosGW or Scality RING, and who owns backup and restore for each tier.
The fourth change is release management, which becomes a standing duty rather than a one-time project. A standard release is supported for 12 weeks, ending with the availability of the third following release, while an LTS release is supported until the next LTS release plus six months. The current LTS is v8.47 (FCS 2026-03-18). An agency that wants fewer upgrade cycles should plan around LTS lines, test each release in a non-production cluster that mirrors its identity and storage setup, and write down who approves each change and who can roll it back.
If the agency also needs office editing, files, chat and video, openDesk bundles OX App Suite for groupware alongside other open-source components, and its deployment uses Helmfile and Helm on a CNCF-certified Kubernetes cluster at v1.33 or later. openDesk plans major releases annually in Q3 and minor releases monthly, and it supports only the latest minor version. Decide early whether the agency runs OX standalone or inside openDesk, because the release train, identity wiring and support model differ. Ask any implementation partner to confirm in writing which features each mode includes and which modules carry separate licensing terms.
Which public sector requirements shape the OX App Suite build
This table maps the public sector requirements most likely to affect an OX App Suite build, with the source of each and the design decision it creates. Read the rows as questions to answer before the architecture is fixed, because several depend on the agency's own data classification, impact level or hosting model. Where a row depends on classification, confirm the category with the agency before committing to controls.
| Requirement | Source | What it means for the OX App Suite build |
|---|---|---|
| NIST SP 800-53 baselines for federal-style controls | NIST SP 800-53 Rev. 5 and SP 800-53B | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements. The agency's impact level selects the baseline, so confirm it before design starts. |
| FedRAMP scope for cloud-hosted groupware | OMB M-24-15 (25 July 2024) | FedRAMP applies when a provider offers the service as a shared service. A single agency's own cloud deployment may be out of scope. Confirm the operating model first. |
| CJIS encryption and vulnerability scanning | FBI CJIS Security Policy v6.1, effective 26 June 2026 | CJI in transit and at rest outside physically secure locations needs FIPS 140-3 modules or AES with 256-bit keys, plus scanning at least monthly. Applies only if mailboxes or files hold CJI. |
| CUI safeguards for non-federal systems | 32 CFR 2002.14(h)(2) | Agencies apply NIST SP 800-171 to CUI on non-federal systems unless the CUI category sets other safeguards. Mail and Drive holding CUI need mapped controls, and the agency's category decides scope. |
| GDPR Chapter V transfers | GDPR Article 44; EDPB Guidelines 05/2021 (version 2.0) | Remote access from a third country and cloud storage outside the EEA count as transfers. Map hosting, backups, support access and vendor logins to locations before design is fixed. |
| Third-country authority access to data | EDPB Recommendations 01/2020; 18 U.S.C. 2713; GDPR Article 48 | Where a provider can access data in the clear and faces broad third-country powers, supplementary measures may be ineffective. Assess this before engaging processors or support providers. |
| Accessibility of web content and apps | 28 CFR 35.200 (ADA Title II) | WCAG 2.1 Level A and AA apply from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Test the web client, themes and portal extensions. |
Standalone OX App Suite or openDesk: choosing the deployment shape
The first decision is whether the agency needs OX App Suite as a standalone mail, calendar and contacts service or as the groupware component inside openDesk. A standalone deployment gives the agency one product to size, back up and upgrade, and it lets the agency choose its own identity integration, storage design and release channel. openDesk is a Kubernetes-based digital workplace suite for public administration, provided by ZenDiS GmbH, a federally owned German company that took over development in January 2024. It bundles OX App Suite with Nextcloud, Element, Collabora, Nubus and other components, and its deployment is driven by Helmfile and Helm. Settle the shape before design starts, because it determines which services the agency operates and which upgrade calendar it follows.
openDesk carries its own platform requirements on top of the OX requirements. It expects a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. For production it expects external services, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. A standalone OX deployment also needs Helm 3.17.0 or newer, Istio or the basic ingress-nginx option, Redis 7.4.x, MariaDB with InnoDB and a distributed file system for persistent data. Map both lists against your existing platform and ask ZenDiS which services openDesk shares across components and which must be dedicated to mail.
Component ownership is the first trade-off. In standalone mode, the agency owns the OX stack, the mailbox data path, the OIDC or SAML login configuration and every release decision. Inside openDesk, OX is one component of a composite release, so its version normally moves with the openDesk release rather than on a schedule set by the agency. Ask which OX App Suite version each openDesk release ships and whether the agency can pin or override the OX component on its own timetable. Check this against the Open-Xchange support commitment, under which a standard release is supported for 12 weeks and an LTS release is supported until the next LTS release plus six months. The answer decides who triggers a security patch for mail.
Upgrade coupling is the second trade-off. 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 need intermediate steps. For an agency, this means a monthly change cadence that touches mail, files, chat and office together, not mail alone. A standalone OX deployment lets the agency choose an LTS track and schedule upgrades into its own change windows, but it then has to track OX releases itself. Either way, keep a non-production environment on the chosen channel and rehearse each upgrade path before production, and bring the change board into the cadence early.
The Enterprise Edition question closes the decision. ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed 2nd and 3rd level support and patches, sold as SaaS or for on-premises installation. Enterprise-only features include OX S3 storage and advanced full-text search, which affect mail and file workloads. The OX Operations Guide also notes that some modules may carry separate fees set in the license agreement. Ask for the written list of Enterprise-only features, the license terms for each OX module and the support boundary between ZenDiS and the agency. Confirm the current openDesk release policy with ZenDiS before choosing a shape.
Which OX App Suite modules and settings matter for agencies
Agency deployments of OX App Suite v8 depend on a small set of modules and platform choices that are hard to change later. Each card names one decision, what it affects, and what to confirm with Open-Xchange before the scope is written.
Mail and calendar baseline
Email and calendar set the user model, mailbox provisioning and the mail flows that agency staff depend on from day one. Decide how mailboxes map to agency accounts and which inbound, outbound and relay paths run through your existing gateways. Confirm with Open-Xchange which mail backend and calendar capabilities the v8 release you plan to deploy supports in your environment, and which parts of mail operation remain your responsibility.
Documents, Drive and file storage
Drive stores user files and sharing data, and Documents edits office files, so both depend on the storage design. Decide whether files stay inside the agency's own data center or sovereign cloud, and whether the platform uses NFS for a smaller deployment or object storage such as AWS S3, Ceph RadosGW or Scality RING for a larger one. Confirm with Open-Xchange how Documents and Drive use that storage, and which backup and restore method covers those files.
Single sign-on tied to the agency directory
OX App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware. Decide which protocol the agency identity provider uses, and how group membership and account changes such as joiners, movers and leavers reach OX App Suite. Confirm with Open-Xchange which SAML configuration applies to the v8 release you plan to run, because the SAML operator guide cited for this topic belongs to an earlier 7.10.1 documentation set.
Redis 7.4.x and MariaDB versions
Redis 7.4.x handles caching and session storage, and MariaDB with the InnoDB engine is the primary data store. Decide whether Redis runs through the default littlered operator or a custom or unmanaged setup, and whether MariaDB runs as a single instance or as a Galera Cluster. Supported MariaDB lines are 10.6.x, 10.11.x, 11.4.x and 11.8.x. Confirm with Open-Xchange which line fits your support window and your agency's patching cadence before you fix the version.
Istio or ingress-nginx
OX App Suite v8 requires Istio, with the latest Istio release plus two prior versions supported, and a basic ingress-nginx option exists where Istio cannot be used. Decide whether your platform team already operates Istio, since that choice shapes traffic policy, certificate handling and the skills your operators need. Confirm with Open-Xchange which Kubernetes versions apply (N-1 and N-2 are supported), and that your Helm version meets the 3.17.0 minimum.
Licensing and separately priced modules
Open-Xchange's Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Decide which modules the agency needs beyond mail, calendar, contacts and tasks before the scope is written. Confirm with Open-Xchange which modules your license includes, which carry separate fees, and how these terms apply to deployment in your own infrastructure. Public source on GitHub does not settle which features your license covers.
How data residency and third-country access shape the design
Hosting OX App Suite in an EU data center does not settle the transfer question on its own. EDPB Guidelines 05/2021 (version 2.0) treat remote access from a third country as a transfer, even when the person only displays data on a screen for support or administration, and storage in a cloud outside the EEA is also a transfer. For an agency running mail, calendar and contacts, the design therefore has to cover who can reach the systems, from where, and under which law, not only where the disks sit. Map every support path, including vendor engineers' remote sessions into the Kubernetes cluster, the MariaDB and Redis tiers and the file storage holding OX Drive files and PIM attachments. Record each path as a transfer question before the platform goes live.
Three legal exposures shape that map. The CLOUD Act provision at 18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is located. A provider or administrator subject to US jurisdiction may therefore be compelled regardless of server location. GDPR Article 48 allows a third-country court judgment or administrative decision to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. The Data Act's Article 32 duty, set out in Regulation (EU) 2023/2854, adds a separate obligation for non-personal data held in the Union, requiring measures against third-country governmental access that would conflict with Union or national law.
Technical measures have a limit. EDPB Recommendations 01/2020 state that where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption therefore helps only when keys stay with the agency and no third-country party must see plaintext. In practice, the operating model carries more weight than the cipher. The agency should hold the cluster, the database and storage tiers and the key material, and the administrators with access should be named, EU-based and bound by EU-law contracts, with their sessions logged. Reducing the number of people who can see plaintext is the control that the Recommendations' reasoning points toward.
Narrowing exposure does not settle compliance. The agency's counsel must assess its own transfer position, including controller and processor roles, the contract with each party that touches the platform, the Chapter V mechanism relied on for any transfer, and the status of any US-linked supplier. Commission Implementing Decision (EU) 2023/1795 finds adequacy only for US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Ask the implementation partner to document in writing which entities hold administrative, support or data access, where each is located and under which jurisdiction, so counsel works from a verified inventory.
Compliance frameworks public agencies check against groupware
Public agencies usually answer to several frameworks at once, from federal control catalogs and criminal justice data policy to EU directives, accessibility law and data portability rules. Each card names one obligation and what to check in an OX App Suite deployment. DeployOpen prepares systems and evidence for assessments but does not issue audit reports, attestations or certifications, and independent assessors decide outcomes.
NIST SP 800-53 Rev. 5 baselines
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects control sets for low, moderate and high baselines: 149, 287 and 370 controls and enhancements respectively. Agencies often inherit these requirements through FISMA and OMB Circular A-130, and Inspectors General assess them independently. For an OX App Suite deployment, confirm which baseline your system categorization requires, then map each selected control to the mail backend, identity provider, Kubernetes cluster and storage layer that implement it. Ask your authorizing official which Release 5.2.0 profile applies.
FedRAMP scope under M-24-15
FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. OMB memo M-24-15 of 25 July 2024 sets that scope and rescinds the 2011 memo that created the program. Systems used only for one agency's operations on cloud infrastructure, and not offered as a shared service, fall outside it. A self-operated OX App Suite in the agency's own cloud account may therefore sit outside FedRAMP while still needing the agency's own authorization. Check whether the hosting arrangement is shared or single-tenant before assuming an exemption.
CJIS encryption and scanning
The FBI CJIS Security Policy sets minimum requirements for criminal justice information, and version 6.1 took effect on 26 June 2026. For CJI in transit and at rest outside physically secure locations, it expects FIPS 140-3 certified cryptographic modules or FIPS 197 AES with keys of at least 256 bits, up from 128 bits. It also requires vulnerability scanning at least monthly. For mail, check TLS termination, database and file storage encryption, backup encryption and the scanner scope across Kubernetes nodes, containers and middleware. Confirm module certificates with each component vendor.
NIS2 public administration scope
NIS2 lists public administration as a sector of high criticality and covers central government entities regardless of size. Member States may extend it to local public administration. It does not apply to entities working in national security, public security, defense or law enforcement, so an agency serving police or defense units may need a separate scope analysis. For an OX App Suite deployment, establish whether your organization is an in-scope entity under national transposition, then document incident handling, supply chain security and business continuity for the mail service. Confirm the national implementing law with counsel.
Data Act switching rights
The EU Data Act, applicable since 12 September 2025, gives customers of a data processing service the right to switch to another provider or to on-premises ICT infrastructure. Articles 25, 29 and 50 set a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. For an OX App Suite deployment, write exit obligations into the contract: export formats for mailboxes, calendars, contacts and Drive files, deletion evidence and cooperation during transition. Confirm which party holds the provider role before drafting these clauses.
WCAG 2.1 AA deadlines
Title II of the ADA requires state and local government web content and mobile apps, including content provided through contracts or licenses, to meet WCAG 2.1 Level A and AA. Under 28 CFR 35.200, the compliance date is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. An OX App Suite deployment includes a web client, so check your population threshold, the configured theme and any custom plugins. Request the vendor's accessibility conformance documentation before procurement, and test with assistive technologies in your own environment.
Rollout phases for an agency OX App Suite deployment
This sequence takes an agency from data classification to a handed-over OX App Suite deployment on infrastructure it controls. Each phase ends with a written output and a decision that gates the next phase, so residency, security and operations are settled before mailboxes move.
Scope and classify agency data
DeployOpen works with the agency's data owners to inventory mailboxes, calendars, contacts, Drive files and PIM attachments, then classify each by sensitivity and legal regime, including personal data and any criminal justice or controlled unclassified information. The agency provides data owners, current volumes, retention rules and the statutes and contracts that apply. The phase closes with a signed data inventory and classification register. That register decides the hosting zone and the control baseline, so the next phase cannot start without it.
Decide architecture and residency
The agency and DeployOpen settle the deployment shape: standalone OX App Suite or as part of openDesk, on-premises or in a sovereign cloud the agency selects, Istio or the basic ingress-nginx option, object storage or NFS for persistent data, and Redis and MariaDB topology including Galera Cluster if needed. Residency review covers remote support access from a third country, which the EDPB treats as a transfer, and exposure to third-country legal orders such as the US CLOUD Act. The agency provides approved hosting locations, network zones and support access rules. The output is an architecture decision record that the agency signs.
Build the cluster and dependencies
DeployOpen builds the Kubernetes cluster within the Kubernetes versions OX App Suite v8 supports, installs Helm 3.17.0 or newer, and deploys the mail backend services: Redis 7.4.x through the littlered operator, MariaDB on a supported 10.6, 10.11, 11.4 or 11.8 release, and the chosen distributed file storage. The agency provides nodes, cloud or data center accounts, DNS, certificates and identity provider access. Confirm the current LTS release, v8.47 at the time of research, before pinning versions. The phase closes when a staging deployment starts cleanly and a backup restore has been tested.
Integrate with the agency directory
DeployOpen connects OX App Suite to the agency directory through OpenID Connect or SAML, maps directory attributes and groups to mailbox and sharing roles, and designs how accounts are created, changed and removed. The agency provides the identity owner, attribute schema, federation metadata and test accounts, and confirms how multi-factor authentication is enforced upstream. The output is a test matrix showing sign-in, group-based access, password or session policy and deprovisioning, with every failed case logged and retested. Mailbox provisioning does not go live until the matrix passes.
Test security and collect control evidence
DeployOpen tests the staged environment against the agency's security requirements, covering application, API, cloud and infrastructure testing, and maps the configuration to the control baseline the agency has chosen, such as the NIST SP 800-53B low, moderate or high baseline. If criminal justice information is in scope, the review also covers FIPS 140-3 modules, encryption key length and at least monthly vulnerability scanning under the CJIS Security Policy. DeployOpen prepares control evidence, but independent auditors and accreditors issue any assessment. The agency provides control owners and an authorizing official. The phase closes when every finding is fixed or has a written risk acceptance.
Run a pilot with a small group
The agency selects a small pilot group representing the main user roles and works in OX App Suite for mail, calendar, contacts, Drive sharing and Documents for a defined period agreed in advance. DeployOpen monitors performance, logs defects and tracks support requests, while the agency's help desk handles user questions. The agency provides pilot users, a feedback owner and named support contacts. The output is a pilot exit report listing defects, fixes, accessibility observations against WCAG 2.1 AA where web content applies, and a signed go or no-go decision.
Migrate mailboxes in controlled waves
DeployOpen moves mailboxes from the source system in waves, with coexistence and mail routing set up before each wave, DNS and MX changes scheduled with the agency, and a rollback path for each wave. Every wave ends with a reconciliation check that compares item counts and sample content between source and target. The agency provides source system access, cutover windows, a communication plan for users and sign-off on each wave. The phase closes with a reconciliation report per wave and a decommissioning plan for the old system.
Hand over with operations runbooks
DeployOpen hands the environment to the agency's operations team with runbooks for upgrades, Redis and MariaDB failover, backup and restore, certificate and secret rotation, incident response and user lifecycle tasks. Upgrade runbooks follow the Open-Xchange support commitment, which supports a standard release for 12 weeks and an LTS release until the next LTS plus six months. The agency provides named operators, on-call coverage and training attendance. The output is accepted runbooks, a restore test witnessed by the agency and a named owner for each runbook. Ongoing support or upgrades can be placed under a retainer.
Release channel and support windows for agency operations
An agency running OX App Suite v8 has to choose between standard releases and LTS releases, and the support commitment sets how long each one stays supported. A standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. At the time of research, v8.47 (first customer shipment 2026-03-18) is the current LTS. v8.35, the first v8 LTS (FCS 2025-03-12), is discontinued. v8.53, with first customer shipment on 2026-09-23, is the newest release listed in the commitment. Confirm these dates with Open-Xchange before you set a channel, because the list changes as new releases ship.
The choice mostly comes down to how often your team can afford to upgrade. Standard releases keep you close to current code, but each one has a short support window, so a team on standard releases must upgrade on a steady cycle or fall out of support. Each upgrade carries a cost that is easy to underestimate. Helm charts and container images must be validated against your Kubernetes version (OX App Suite v8 supports N-1 and N-2), your Istio release (the latest plus two prior versions) and your Redis 7.4.x and MariaDB versions. Staff time for test environments, change approvals and rollback drills recurs with every release, whether it is done in house or under a retainer.
LTS releases reduce that cycle, and that matters when an agency has to hold a stable configuration for an assessment. Frameworks such as the control baselines in NIST SP 800-53 and the CJIS Security Policy expect a documented system state that assessors can test. Every version change can reopen evidence for the controls it touches, including configuration records, vulnerability results and change logs. An illustrative case: an agency whose assessment cycle runs longer than a standard release window would prepare evidence for one version, then face an upgrade before the assessment ends. Plan the release channel around the length of your assessment or authorization cycle, not only around feature needs.
Before you plan, ask Open-Xchange to confirm the current LTS, the status of any release you intend to run, and the end of support date for your chosen version. Ask whether your license agreement covers every module in scope, because the Operations Guide notes that some modules may carry custom packaging or separate fees. Write an upgrade calendar that names the test window, the approval owner and the rollback path for each release. Ask any partner quote to include upgrade testing, evidence updates and the cost of a forced move if support ends earlier than your plan assumes.
Questions agencies ask before hiring a partner for OX App Suite
What does an OX App Suite public sector implementation cost, and what drives the price?
The cost is set by the written scope, and DeployOpen does not publish a price list. Agencies pay for planning, cluster and platform preparation, identity and mail integration, data migration, testing, hardening and handover. Open-Xchange's Operations Guide notes that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so confirm license entitlements before scoping. Recurring costs include the infrastructure you run in your own cloud or data center, storage, backup, patching and any support retainer. Ask for a quote that lists each deliverable, the environments in scope, user and mailbox volume, integrations, and which items are one-time and which recur.
How long does an OX App Suite deployment take for an agency?
Duration depends on scope, and no standard timeline applies to every agency. The main drivers are the number of environments, whether you already operate a suitable Kubernetes cluster, the storage model for OX Drive and PIM attachments, the identity integration (OpenID Connect or SAML), the volume of mail and calendar data to migrate, and how many approval cycles your security and change boards require. Work usually runs in phases: design, build in a non-production environment, migration rehearsal, cutover and stabilization. Ask for a written timeline with a dependency list. Confirm which steps depend on procurement, network changes or certificate issuance, since those often set the critical path.
What must the agency's own team provide before a deployment starts?
Your team supplies the infrastructure and decisions the platform depends on. Confirm the following: a Kubernetes cluster and Helm 3.17.0 or newer; a service mesh decision, since OX App Suite v8 requires Istio (supporting its latest release plus two prior versions), with a basic ingress-nginx option where Istio cannot be used; Redis 7.4.x, deployed by default through the littlered operator unless you supply your own; MariaDB on a supported version (10.6.x, 10.11.x, 11.4.x or 11.8.x), with Galera Cluster as an option; a distributed file system for persistent data, such as NFS for small to mid-size deployments or object storage for larger ones; identity provider access; DNS, certificates and SMTP routes. Name owners for security approval, change control and user acceptance testing.
Can our internal team deploy OX App Suite without an outside partner?
A skilled internal team can deploy it if it already runs Kubernetes, Helm, a relational database and a distributed file system at production standard. The difficult part is usually the operation after the first install: upgrade planning against Open-Xchange's release and support windows, backup and restore testing for the database and file storage, Redis operations, certificate and identity lifecycle, and monitoring. Open-Xchange supports a standard release for 12 weeks and an LTS release until the next LTS release plus six months, so the team needs a repeatable release process. Assess skills across Kubernetes, storage, database administration, identity, mail protocols and security testing. Many agencies keep operations in house and buy design, build or a retainer from a partner. Ask any partner for a written handover plan.
Is openDesk cheaper to run than standalone OX App Suite?
Neither option is cheaper by default, because running cost depends on what you need. openDesk is a suite of many components, including Element, Nextcloud, OX App Suite, XWiki, Nubus, OpenProject, Jitsi and Collabora, so it adds more services to operate, upgrade and monitor. Its requirements are also heavier: a CNCF-certified Kubernetes cluster at v1.33 or later, cert-manager, an ingress controller, and external production services such as PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, object storage and a TURN server. ZenDiS recommends openDesk Enterprise Edition for production, which adds SLA-backed support and is sold as SaaS or for on-premises installation. Standalone OX App Suite covers mail, calendar and contacts with fewer components. Ask both options for a multi-year cost model that covers licenses, support tiers, infrastructure, staff time and upgrade effort.
What does DeployOpen do to prepare an OX App Suite system for compliance assessment?
DeployOpen does not make a system compliant, and it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen can plan, build, harden and document the system so an assessor can review it, including control mapping, configuration baselines, access controls, logging, backup evidence and change records. The applicable framework depends on your data and mission. For example, NIST SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. The FBI CJIS Security Policy v6.1 requires FIPS 140-3 validated modules or AES with 256-bit keys for criminal justice information. Your legal and compliance team should set the applicable baseline before the scope is written.
Which OX App Suite release should a public agency standardize on?
Standardize on a supported release and plan upgrades before go-live. Open-Xchange documents that a standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. According to the support commitment, v8.47 (first customer shipment 2026-03-18) is the current LTS, and v8.35 is discontinued. Agencies that cannot upgrade every few months usually prefer LTS. Confirm the release status on the support commitment page on the day you sign, because the newest listed release changes. Document an upgrade procedure that includes a staging environment, Helm chart version checks, and database and Redis version alignment before each move.
How DeployOpen scopes and delivers agency OX App Suite work
DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports Open-Xchange for the public sector inside the agency's own infrastructure, whether that is its cloud accounts, data centers or air-gapped networks. Each engagement starts from a written scope agreed before work begins, so agencies know what is delivered and how it will be checked.
How we scope
- The written scope names the OX App Suite version, target cluster and Helm chart release.
- Scope covers Redis, MariaDB and distributed file storage choices, checked against the OX App Suite requirements.
- Fixed-scope engagements are agreed in writing, and ongoing support can follow as a retainer.
How we build
- Deploy OX App Suite v8 as Helm charts on Kubernetes, with Istio or ingress-nginx where Istio cannot be used.
- Configure SSO through OpenID Connect, and SAML login for the middleware where the agency requires it.
- Test backups, restores and upgrade steps in the agency's environment before go-live.
How we hand over
- Handover documents the deployed versions, Helm values, Redis and MariaDB topology and storage layout.
- Runbooks cover upgrade paths, including the Open-Xchange support windows for standard and LTS releases.
- Evidence packs for compliance readiness list controls and configurations, prepared for independent assessors to review.
How we support
- Retainers can cover ongoing support, upgrades and continuous testing of the deployed OX App Suite.
- Ask which OX App Suite release line your agency will track, standard or LTS, before signing.
- Ask how licensed modules and separate fees are set out in the license agreement before scoping.
