What customization means for OX App Suite
Customizing OX App Suite v8 covers four layers, and each carries a different amount of risk when the platform moves to a new release. The first is white-label branding: logos, color themes, product names and login and legal text that make the suite look like the operator's own service. The second is UI plugins built against the frontend (appsuite-frontend), which change screens, menus or workflows inside the web client. The third is middleware configuration, which sets how the appsuite-middleware behaves for login, mail, calendar and file handling. The fourth is Helm values per environment, which control image tags, replica counts, ingress, Redis and database references across development, test and production clusters.
Three triggers drive most of this work. A hosting provider reselling the suite under its own brand needs branding and tenant-level settings that match its contracts. A telco or ISP typically needs its own look and a specific feature set, which can mean both branding and plugins. An enterprise adjusting the client to internal workflows usually needs plugins and middleware settings tied to its identity and records processes. In each case, decide early which changes must survive every Helm chart upgrade and which can be rebuilt on each release.
In-house versus partner is largely a question of which layer you are changing. A platform team with Kubernetes experience can often handle branding assets and Helm value changes, provided they keep them in version control per environment. Plugin work that touches frontend internals and middleware behavior is harder to keep compatible with standard and LTS releases, so a partner often helps with the first build and the regression harness, then hands over the runbook. Confirm the frontend and middleware versions you will target before estimating either path.
Licensing sets the boundary, not the code mirrors. Open-Xchange publishes the appsuite-frontend and appsuite-middleware code on GitHub under AGPL-3.0, but the Operations Guide states that certain modules or features may be subject to custom packaging, limitations or separate fees in the license agreement. Before you plan any customization, ask Open-Xchange which modules your agreement covers and whether any customization requires a separate license. Read your contract, not the public repository, to know what you may use and redistribute.
What the customization work includes
Each work package produces artifacts you keep in your own repositories and environments. The exact extension points are confirmed against the OX App Suite version in use before the design is signed off.
White-label branding and theming
Logos, color schemes, login page content and other branding elements are set through theme configuration and assets that you own. Confirm which branding settings the installed release exposes and which need code changes. Agree in writing on the trademark and legal text you will supply before the design is approved.
UI plugin development
Frontend plugins extend the App Suite UI only through the extension points the installed release supports, so the design starts from a confirmed list of those points for your version. Plugins are built in your repository and rechecked against each new release before rollout. Confirm the list before design sign-off.
Middleware configuration and server-side extensions
Middleware settings, login configuration and any server-side extension are set per environment and tested against the authentication and provisioning paths you use. Check whether a server-side change touches code covered by the AGPL-3.0 mirrors or by separate license terms in your agreement before building it.
Helm values and environment overlays
Customizations are expressed as Helm values and per-environment overlays, so development, test and production differ only where intended. The overlays must work with Helm 3.17.0 or newer and with the Kubernetes and Istio versions the release supports. Reviewers can inspect the rendered manifest differences before each change is applied.
Regression suite for each release
A regression suite runs the branding, plugin and middleware checks against each new release before you upgrade, so breakage appears in test first. Ask which checks are automated and which stay manual, and who owns triage when a check fails. Standard releases are supported for 12 weeks, so plan the test cadence around that window.
Documentation and handover
The handover includes a runbook for applying custom work during an upgrade, with the rollback steps for each change and a current inventory of extension points in use. Ask for named owners on your side and a walkthrough with your platform and development teams. The documents stay in your repository after the engagement ends.
What drives customization cost and duration
This table lists the factors that move the effort of an Open-Xchange customization, why each one matters and how to keep it contained, so you can compare them against a written scope rather than a generic estimate.
| Driver | Why it moves the effort | How to keep it down |
|---|---|---|
| Surfaces changed | Branding only touches theme assets and strings. New screens, menus or workflows need frontend code, design review and separate testing for each one. | Limit the first phase to branding and configuration, then add screens as separate, scoped items. |
| Depth of frontend changes versus configuration | Settings in middleware and Helm values are reversible and easier to upgrade. Changes to the App Suite UI code must be rebased whenever the upstream code changes. | Prefer configuration and documented extension points, and keep UI modifications small and isolated. |
| Number of brands or tenants | Each brand or tenant can need its own logos, colors, domains, login pages and settings, which multiplies both build and verification work. | Define a shared base theme with per-brand overrides, and confirm in writing exactly which brands are in scope. |
| Middleware changes and their testing | Server-side changes affect mail, calendar and file behavior, so each one needs functional tests and a review of its effect on other clients and integrations. | Keep middleware changes minimal, document each one, and agree on the test cases before the build starts. |
| Licensing review for modules or features | The Operations Guide notes that some modules or features may carry custom packaging, limitations or separate fees in the license agreement. Customizing a feature you do not license can add rework or cost. | Confirm with Open-Xchange which modules the customization depends on before the design is final. |
| Number of environments needing overlays | Each environment such as test, staging and production can need its own Helm values and overlays, and drift between them causes failures that are slow to diagnose. | Keep one base configuration with a small, version-controlled overlay per environment. |
| Release train cadence and regression coverage | Custom work must be checked against each release taken. Frequent releases with little automated regression testing mean more manual verification per upgrade. | Agree which release channel you will follow, automate regression tests for custom screens, and plan upgrade testing into each cycle. |
| Compliance or accessibility evidence required | Evidence such as test records, accessibility checks, change logs and configuration baselines takes time to produce and must be kept current for each release. | Define the evidence list in the scope up front and collect it as part of each change rather than at audit time. |
Customization project phases
The sequence keeps every custom change inside licensed features, tested against the release you run and the next one, and documented so your team can rebase it onto future releases.
Confirm licensing and feature scope
Before any design work, we review your license agreement with you to confirm which modules and features the customization may use, since some may be subject to custom packaging, limitations or separate fees. The output is a written list of permitted modules and features, signed off by your license owner. The phase is complete when every planned customization maps to a licensed capability.
Build a customization inventory
We catalog every planned change: white-label branding, UI plugins, middleware configuration and Helm values. Each item records its purpose, the files or settings it touches, its dependencies and the design decision behind it. The output is an inventory your owners can review line by line, and the phase closes when each item has an approved design decision.
Build in version-controlled branches
Developers implement each inventory item in version-controlled branches, keeping customizations separate from upstream code. Environment-specific settings are delivered as Helm overlays per environment, so development, test and production differ only where intended. The phase is complete when every change is reviewed, merged and reproducible from the repository.
Run regression tests on two release targets
We test the build against the release currently installed and against the next standard or LTS release, so problems surface before an upgrade is scheduled. Test results are recorded per target and per inventory item. The phase closes when both targets pass or every failure has a documented fix or accepted risk.
Obtain acceptance from your owners
Your business owners and platform team review the customized system in the test environment against the agreed scope and inventory. Acceptance is recorded in writing, with any deviations logged and resolved. The phase is complete when your named owners sign off, and the timeline for this stage is set out in the written scope.
Hand over with a rebase procedure
We deliver the repository, Helm overlays, test results and documentation to your team, along with a step-by-step rebase procedure for applying future releases to the custom branches. Your engineers run a rebase rehearsal with us before handover closes. The phase is complete when your team has performed the procedure successfully on a test environment.
What stays in-house and what goes to a partner
This table shows who usually owns each part of OX App Suite customization and which skills each part needs, so you can decide what your team keeps and what a partner builds.
| Work part | Who usually owns it | Skills it needs |
|---|---|---|
| Brand assets and style decisions | In-house marketing or design, with platform owners approving changes | Brand guidelines, design tokens, asset production, review against the UI theme structure |
| Helm values and GitOps pipelines | Platform engineering, kept in your own repository | Helm 3.17.0 or newer, per-environment values, GitOps tooling and change review |
| Frontend plugin development | Partner builds first plugins, then your engineers take over maintenance | JavaScript and the App Suite UI framework, plugin packaging, upgrade-aware code reviews |
| Middleware configuration and server-side extensions | Partner designs and writes the first extensions, platform team operates them | Java and middleware configuration, Istio and Kubernetes awareness, logging and troubleshooting |
| Licensing and contract review | Procurement and legal, with the vendor agreement as the reference | Contract review, understanding of separately licensed modules and customization rights |
| Regression testing across releases | Partner builds the test harness, QA with test automation runs it each release | Test automation, API and UI test design, staging environment management |
What goes wrong in customization projects
Most Open-Xchange customization problems come from a small set of avoidable decisions. Each card names the failure mode and the control that prevents it.
Custom code that depends on internals
Plugins or patches that call undocumented middleware or UI internals often break when a new standard or LTS release lands. Pin the release in your chart values, and keep a regression suite in the pipeline that runs your customizations against each candidate release before it reaches production.
Customizing an unsupported release
A standard release is supported for 12 weeks, and an LTS release until the next LTS plus six months. Building customizations on a release that has left its support window leaves you with fixes you cannot get and an upgrade you must do under pressure. Check the support commitment before design starts and plan the upgrade path as part of the build.
Features outside the license terms
Open-Xchange's Operations Guide notes that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Customizing a feature you are not entitled to use can force redesign late in the project. Run a licensing review with the vendor before design, and record which features each design element depends on.
Branding that differs between tenants
White-label deployments often serve several tenants, and logos, colors and login text drift when each is edited by hand. Keep branding as versioned overlays with one shared base, and add a check in the pipeline that compares rendered branding for every tenant against the approved template.
Changes that bypass the pipeline
Hand-edited container images and secrets written into values files both move configuration out of review. Build customizations through overlays on the official charts, store secrets in an external secrets manager referenced by name, and block commits that contain plaintext credentials or edited image references.
Middleware changes that cannot be reversed
A middleware configuration change that only one engineer understands, with no runbook and no tested rollback, becomes a single point of failure. Document each change with its purpose and owner, and rehearse rolling back every customization in a staging environment before it is released to production.
How customization differs by starting point
White-label resale means one code base serves many brands, so customization is governed by contract as much as by engineering. Decide early which settings sit at the tenant level and which stay with the platform team.
- Tenant boundaries: which branding, logos, default settings and feature toggles each reseller can change without a platform change
- Contract terms: what resellers and end customers may modify, and who approves exceptions
- Licensing: whether any module you plan to resell carries separate fees or packaging limits under your license agreement
- Configuration control: how tenant settings are versioned, reviewed and rolled out across brands
- Release impact: how each brand's overrides are retested before every platform release
An organization adapting OX App Suite for its own brand and workflows has fewer tenants to manage, but the same release discipline applies. The main choices are how far branding and workflow changes go and who owns them after go-live.
- Branding scope: logos, themes, login page text and help content, and where each is set in Helm values or middleware configuration
- Workflow changes: which UI plugins or middleware settings support your processes, and which need custom development
- Ownership: a named owner for each customization and a short record of why it exists
- Identity: how sign-in pages and branding interact with your OIDC or SAML configuration
- Questions to ask: which changes survive a chart upgrade without rework, and how long your test cycle takes before each rollout
Customizations built for OX App Suite 7.10 or earlier were written for a different deployment model. Moving them to v8 on Kubernetes is a migration decision, so this tab covers only what changes for customization. The full steps are in the migration topic.
- Inventory: list every custom file, plugin, configuration override and branding asset from the 7.10 environment
- Fit: sort each item into keep as is, rebuild as a plugin or chart value, or retire in favor of standard functionality
- Packaging: v8 is delivered as Helm charts that reference container images, so custom work must be built into images or set through values
- Tooling: confirm your cluster tooling meets the Helm 3.17.0 minimum required for v8
- Questions to ask: who owns each item after cutover, and how each one is tested against the current support window
In an air-gapped network, customization depends on what you can bring in and rebuild internally. Nothing is pulled from public registries or code hosts at build or run time, so every input must be mirrored and versioned inside the network.
- Code sources: mirror the appsuite-frontend and appsuite-middleware repositories, which Open-Xchange publishes under AGPL-3.0, and record the exact versions you build from
- Container registry: mirror every image the Helm charts reference, including those for supporting services such as Redis
- Build pipeline: run image builds for custom work on internal runners with no outbound access
- Update path: define how security patches and release drops are reviewed and imported through your approved transfer process
- Questions to ask: which artifacts and licensing terms your agreement covers for mirroring, confirmed with Open-Xchange
What you need to provide
Before scoping starts, the client supplies the inputs that determine how much customization work is possible and how long each change takes. Access comes first: a kubeconfig or equivalent role on the Kubernetes cluster where OX App Suite runs, read and write access to the Git repository holding the Helm values, and a non-production namespace where custom work can be tested. Without these, every change has to be proposed in writing and checked by someone else, which adds rounds and time to the work.
Brand and interface inputs drive the design effort. Provide logo files, color tokens, typography, and a style guide that names who approves design decisions. Also supply a written list of required features with their licensing status confirmed against the license agreement. Some modules may be subject to custom packaging, limitations or separate fees, so a feature that depends on a licensed module can change the scope before any code is written.
Environment and tenant detail shapes the number of deployments to build and test. List each environment (development, test, staging, production) and which tenants or brands each one serves. Add test accounts with the mailbox, calendar and Drive permissions needed to reproduce issues, plus sample data that reflects real contexts and folder structures. Confirm the release calendar and the support window your organization has committed to, because custom work must be retested against every release you adopt.
Finally, name the people who can approve design, acceptance and production changes. Approvals that take weeks to obtain extend the schedule more than any technical task. Confirm who signs off each stage, how long reviews are expected to take, and who holds the change window for production. Ask the partner to put these inputs into the written scope, so that delays caused by missing items are visible and handled through agreed change control.
Frequently asked questions about OX App Suite customization
What drives the cost of OX App Suite customization?
The cost follows the written scope, so the main drivers are how many changes you request, how deep they go into the code, and how many environments must carry them. Branding and value changes need less work than UI plugins, middleware changes or custom test harnesses, which need design, development and testing. Recurring cost comes from keeping each change working across monthly releases. Ask any quote to list each item, the environments it covers, and the testing and rebase work included. DeployOpen does not publish prices.
How long does an OX App Suite customization project take?
No duration can be stated before scope is fixed. Timing depends on how many customizations are in scope, how many environments they reach, and how long approvals take from your change board and from Open-Xchange where a license or support question arises. Most engagements are fixed-scope, so the start, deliverables and timeline are agreed in writing before work begins. Ask for the timeline as milestones tied to testing and approval gates.
Can our own team customize OX App Suite without a partner?
Yes, for many branding and value changes, provided your team has the skills to build, test and deploy them through Helm values and configuration. A partner is often used for UI plugins, middleware changes and test harnesses, where code design, regression coverage and upgrade work add effort. Your team can start with the parts it already knows and bring in outside help for the rest. Agree the split in the scope document so ownership of each custom item is clear before build begins.
Does customizing OX App Suite affect support or AGPL licensing?
The answer depends on your license agreement and on how you run and share the modified code. Open-Xchange publishes mirrors of the App Suite UI and middleware on GitHub under the AGPL-3.0 license, so modified copies carry obligations under that license. Support and commercial licensing terms come from your license agreement, and some modules may carry separate fees or packaging limits. Confirm in writing with Open-Xchange which custom changes your support covers and how AGPL-3.0 applies to your hosting and distribution model, and have counsel review it.
How do custom changes survive new OX App Suite releases?
They survive when they are kept in version control, packaged as overlays or isolated configuration where possible, and covered by regression tests that run on every candidate release. Each monthly release then goes through a rebase step, where custom code is merged onto the new upstream version and the tests are rerun in a staging environment before rollout. Keep Helm values per environment in the same repository so changes are reviewed and traceable. Confirm the exact upgrade sequence and chart version rules with Open-Xchange for your target release.
What must we provide before an OX App Suite customization starts?
Your team should provide a named business owner, the requirements for each change written as acceptance criteria, and access to a staging environment that matches production. You also need the Kubernetes, Istio, Redis, MariaDB and storage platform the deployment runs on, along with source control, test accounts and a change approval path. Early access to brand assets, identity settings and existing Helm values avoids rework. Ask the partner to list every input and dependency in the written scope.
How DeployOpen delivers OX App Suite customization
DeployOpen plans, builds, tests, documents and supports OX App Suite customization inside your own infrastructure, so branding, UI plugins and middleware changes are designed around the Helm charts and the monthly release train from the start. Each engagement is fixed-scope, with the written scope agreed before work begins.
How we scope
- We confirm which customizations are in scope: white-label branding, UI plugins, middleware configuration and Helm values.
- We record the target OX App Suite v8 version, the release channel and the Kubernetes and Istio versions the platform runs.
- We identify which modules or features may need separate licensing terms, which the written scope should state before build starts.
How we build
- We keep customizations separate from upstream code and Helm values so each change can be reviewed, versioned and rebuilt.
- We test each change against the release train, checking compatibility with the planned release before it reaches production.
- We validate changes in a non-production environment that mirrors your cluster, storage and identity configuration before rollout.
How we hand over
- We deliver the code, configuration and Helm value files with documentation covering build, deployment and rollback steps.
- We walk your platform and operations teams through each customization, its dependencies and the upgrade checks it requires.
- We provide a record of tests performed and open items, so your team knows what has been verified and what still needs review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover retesting custom work against each new release within the Open-Xchange support window.
- We can help your team plan and test Helm chart upgrades so custom work stays compatible as the platform moves forward.
