Why a self-hosted email platform for telecoms is a service-provider decision, not a mail server choice
For an ISP, telco or hosting company that resells branded mailboxes to its own customers, the platform choice is a service-provider decision. OX App Suite is the most direct fit for white-label groupware at this scale, and Stalwart and mailcow are smaller-footprint alternatives for providers serving fewer tenants or running a narrower service. The OX App Suite material positions the product as a white-label platform that scales to millions of mailboxes, but that claim only means something once the provider has tested its own tenancy model, release cadence and storage design against its own numbers.
The decision turns on four things rather than on feature lists: how tenants, domains and administrators are separated inside the platform, how the provider plans its release lifecycle, how persistent data is stored at volume, and what evidence exists that the design holds under load. Mailbox protocols and webmail features are largely similar across candidates, so the reader should focus on the architecture underneath. The OX App Suite requirements call for a distributed file system for Drive files and PIM attachments, with NFS for small to mid-size deployments and object storage for larger ones, so storage capacity and growth need to be modeled before any hardware is ordered.
Once the provider resells the service, customer-facing deliverability and abuse handling become its own operational responsibility. Its customers will judge the service by whether their mail reaches Gmail and Outlook, and a single compromised tenant can damage the reputation of every shared outbound address. Before committing, the reader should ask a partner and the vendor to confirm how sending limits, outbound abuse detection and blocklist response are handled per tenant, and how the provider's support commitments line up with OX's standard and LTS release windows.
What a hosting provider or telecom must build for, and where each requirement comes from
This table maps each OX App Suite v8 requirement to what it means for capacity planning and day-to-day operations when you offer branded mailboxes to your own customers. Read each row as a design input: confirm the version and support window with Open-Xchange before you size hardware or sign a contract.
| Requirement | What it asks for | Impact on capacity planning and operations |
|---|---|---|
| White-label branding per tenant | OX App Suite is positioned as a white-label platform, so each customer brand can be presented on the webmail front end | Branding customization must be scoped and tested per tenant; ask whether theme and logo changes need custom packaging under the license agreement |
| Kubernetes and Helm delivery | v8 runs on a Kubernetes cluster and is delivered as Helm charts that reference container images | Your platform team owns the cluster lifecycle, image registry and chart upgrades; plan a separate staging cluster for upgrade testing |
| Helm version floor | Helm 3.17.0 or newer is required | Pin the Helm client version in your build pipeline and check it during every chart upgrade |
| Kubernetes version window | Supports Kubernetes versions N-1 and N-2 | Your cluster upgrade cadence must stay inside this window or the platform falls outside supported versions; schedule cluster upgrades against the App Suite release calendar |
| Istio or ingress-nginx for traffic | Requires Istio, supporting the latest Istio release plus two prior versions; a basic ingress-nginx option exists where Istio cannot be used | Service mesh adds operational skills and certificate handling; if you cannot run Istio, confirm in writing what ingress-nginx option covers your traffic and scale |
| MariaDB with InnoDB | Primary data store; supported versions 10.6.x, 10.11.x, 11.4.x and 11.8.x | Database sizing grows with mailbox count and metadata; define a version policy and test minor upgrades in staging |
| Galera Cluster option | Galera Cluster is supported with MariaDB | Multi-node writes add replication latency and failover testing; decide whether your availability target needs it before buying hardware |
| Redis 7.4.x for sessions | Used for caching and session storage, deployed by default through the littlered operator; unmanaged or custom Redis is configurable | Session volume rises with concurrent logins across tenants; monitor memory and failover, and confirm which Redis setup is supported for your design |
| Distributed file storage | Drive files and PIM attachments need NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones | Storage choice is the main capacity decision; attachment growth per tenant drives cost, and backup scope must include this layer |
| Support window for standard releases | A standard release is supported for 12 weeks, ending with the availability of the third following release | Standard releases are short-lived; plan to upgrade often or move to an LTS line to avoid running an unsupported build |
| LTS release planning | An LTS release is supported until the next LTS release plus six months; v8.47 (FCS 2026-03-18) is the current LTS and v8.35 is discontinued | Set a documented LTS adoption and migration calendar per year, and confirm the next LTS date with Open-Xchange before committing to a customer SLA |
| Licensing limits on modules | The right to use certain modules or features may be limited by custom packaging or separate fees set in the license agreement | Before offering a feature to customers, confirm in the contract which modules you may resell or expose per tenant, since this affects pricing and product design |
Which platforms fit a provider's branded mailbox service and why
OX App Suite is positioned by Open-Xchange as a white-label platform that scales to millions of mailboxes, and it bundles email, calendar, contacts, Documents, Drive and Tasks. It can run on premises, in a public cloud or as the managed OX Cloud service, which lets a provider choose whether it operates the stack itself or buys it as a service. Version 8 is designed for Kubernetes and is delivered as Helm charts, which means the platform team needs container, ingress and storage skills in addition to mail administration.
- Delivery model: Helm 3.17.0 or newer is required, and the chart references container images. Istio is required in the standard design, with ingress-nginx as a basic option where Istio cannot be used.
- Data layer: MariaDB with InnoDB is the primary store, with supported versions 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Redis 7.4.x handles caching and sessions.
- Storage: Drive files and PIM attachments need a distributed file system, NFS for smaller deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones.
- Release cadence: Standard releases are supported for 12 weeks. LTS releases are supported until the next LTS plus six months, and v8.47 (FCS 2026-03-18) is the current LTS.
- Module terms: Some modules may be subject to custom packaging or separate fees set in the license agreement.
Confirm with Open-Xchange which modules your tenants need, how multi-tenant isolation and per-tenant branding are implemented, and what scale results they have validated for your mailbox profile.
Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV. It is licensed under AGPL-3.0, with an optional Enterprise License from Stalwart Labs, and v0.16.26 was published on October 11, 2026. Its appeal for a smaller provider is the footprint: a single server product can handle mail, calendars and contacts without a separate groupware layer, which reduces the number of components to patch and monitor.
- Protocol coverage: IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV are included, so the provider can offer standards-based clients without a proprietary front end.
- Footprint: A consolidated server suits a provider with a modest number of tenants and a small operations team.
- Licensing: AGPL-3.0 obligations apply to modified network-facing code, so legal review is needed if you change the server. The Enterprise License is a separate commercial option.
- Web interface and white-label scope: Confirm whether the built-in administration and webmail can be branded per customer, and what tenant separation the server provides.
- Scale evidence: Ask for test results at your target mailbox count, queue volumes and failover behavior, rather than relying on general statements about performance.
Confirm which edition your support requirements call for, how tenant administrators are delegated, and how backups and restores are tested across tenants.
mailcow-dockerized is a Docker-based mail stack licensed under GPL-3.0, with release 2026-09a published on October 6, 2026. It bundles the common components a small hosting company needs for a single server deployment, which makes it a practical starting point for providers with a limited number of domains and a small customer base. The trade-off is that its design centers on one installation rather than a multi-tenant service platform, so growth beyond a single server requires an architectural change.
- Single-server stack: The package is built around Docker Compose on one host, which keeps installation and updates straightforward for a small team.
- Groupware: Mailcow uses SOGo for webmail, calendars and contacts, so customers get a familiar interface without additional licensing.
- Domain model: Multiple domains and mailboxes can be managed from one installation, but the administrative model is not designed as a reseller platform with strict per-customer isolation.
- Growth path: Plan the point at which a second server, separate storage or a different architecture becomes necessary, and document the migration path in advance.
- Update discipline: Frequent releases mean a defined patching cadence and a tested rollback procedure are part of operations.
Confirm how customer-level administration, quotas and branding are handled, what tenant isolation you need in contracts, and how the stack performs under your peak mail volume before you commit customers to it.
How a multi-tenant OX App Suite deployment is laid out on Kubernetes
This sequence turns a provider's tenancy model into a documented Kubernetes layout, showing where each customer's mail, branding, DNS, sending path and login sit before any customer is onboarded.
Confirm the tenancy model with the vendor
Before any cluster is built, the provider and Open-Xchange agree in writing how tenants are separated: which objects are shared across the platform, which are per customer, and how contexts and users map to the provider's own customer accounts. The provider's engineers and DeployOpen review sizing against expected mailbox counts, peak concurrency and growth. Done means a signed tenancy and sizing note that names every shared component and the vendor's written position on each. Ask the vendor to confirm this in writing, because the separation model determines the rest of the layout.
Build the Kubernetes cluster and Helm release
The platform team provisions the Kubernetes cluster that the vendor's supported version range allows, then installs OX App Suite v8 as Helm charts that reference the vendor's container images. Helm 3.17.0 or newer is required, and the release values file is kept in version control so every environment is reproducible. Confirm the Kubernetes version against the vendor's N-1 and N-2 support statement before provisioning. Done means the release deploys to a non-production namespace with pods healthy and the chart version pinned.
Choose the service mesh or ingress path
OX App Suite v8 requires Istio, and the vendor supports the latest Istio release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option exists, but the provider should confirm in the vendor's documentation which features and tenant routing patterns that path supports before committing. Traffic for each customer domain is routed to the correct tenant entry point at this layer. Done means a test request to each branded hostname reaches the expected tenant and returns the expected login page.
Place the database, cache and file storage
MariaDB with the InnoDB storage engine serves as the primary data store, using a supported version line such as 10.6.x, 10.11.x, 11.4.x or 11.8.x, and Galera Cluster is supported for high availability. Redis 7.4.x handles caching and sessions and is deployed by default through the littlered operator, with custom Redis configurations possible. Drive files and PIM attachments must sit on a distributed file system: NFS for smaller deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Done means a failover test of the database and a restore test of an attachment both complete with the expected result.
Separate branding, DNS and SMTP egress per tenant
Each customer's branded hostnames, logos, login pages and sender identities are configured per tenant, so one customer's theme and domains never appear on another's pages. DNS records for each customer domain, including MX, autoconfiguration and SPF, DKIM and DMARC records, are created and tracked. Outbound mail leaves through an SMTP egress path that the provider owns, with sending IP reputation, reverse DNS and TLS handled as a shared service. Done means each tenant's test message passes SPF, DKIM and DMARC alignment and no tenant's mail uses another tenant's sending identity.
Connect customer login to the provider identity layer
The provider's existing identity layer is connected through OpenID Connect or SAML, so customers sign in with their provider-issued accounts while the mailbox itself stays in OX App Suite. The integration points are the OIDC and SAML configurations per tenant, the claims that map users to contexts, and the logout and session lifetimes. The vendor's OpenID Connect and SAML operator guides describe the options, and the exact fit should be confirmed for the provider's identity product. Done means a customer signs in through the provider's login, lands in the correct tenant, and is denied when disabled upstream.
Test scale and tenant isolation before onboarding
Before the first customer is moved in, the provider runs scale and isolation tests agreed with the vendor: concurrent login and mail traffic at the expected peak, failover of nodes and the database, and attempts to reach one tenant's data or branding from another. Ask the vendor for the test profile, the sizing assumptions behind it and the results it considers acceptable. Done means a written test report shows the platform met the agreed targets and the isolation checks passed, and it becomes the baseline for later upgrades.
How LTS release planning and the support window shape upgrade work
Open-Xchange's support commitment sets the upgrade clock for a hosting provider. A standard OX App Suite release is supported for 12 weeks, ending with the availability of the third following release, so a provider that stays on standard releases must move roughly every few months. An LTS release is supported until the next LTS release plus six months, which gives a longer window but still requires a planned move. The current LTS is v8.47 (FCS 2026-03-18), v8.35 is the first v8 LTS and is now discontinued, and v8.53 has been shipping to customers since 2026-09-23. Confirm the exact dates for your branch in the support commitment before you commit to a cadence.
Plan the upgrade process around the branch you run, not the newest version. Keep a staging environment that tracks the current LTS in the same Kubernetes and Helm layout as production, including the MariaDB, Redis 7.4.x and Istio versions that the requirements page lists, so that chart changes are tested before they reach your customers. Schedule one change window per upgrade, communicate it to tenants in advance, and write down the rollback path for each step: the Helm release revision, database backup and restore points, and how you would revert a Redis or MariaDB change. Ask your implementation partner to show these steps working on staging before the first production change, and agree who signs off on the window.
Put the entitlement question into the contract before signing. Ask Open-Xchange or your reseller which release branch your license covers, whether an LTS subscription includes access to the LTS releases through their end of support, and whether moving between branches carries a fee. The Operations Guide notes that some modules may be subject to custom packaging or separate fees set in the license agreement, so confirm which features your white-label offer depends on are included. Ask for the support end dates in writing, and for the lead time Open-Xchange gives before a branch is discontinued, so your upgrade calendar never depends on memory.
What evidence a provider's customers and auditors will ask for, and which component produces it
This table maps each piece of evidence a hosting provider or telecom will be asked for to the component that generates it. Read it as a checklist to agree with your platform team before go-live, since the evidence is only as good as the logging and test records behind it. DeployOpen prepares this evidence for your assessors but does not issue audit reports or attestations.
| Evidence item | What it shows and who asks for it | Component that produces it |
|---|---|---|
| Tenant isolation test results | Proof that one customer's mailboxes, calendars and shared data cannot be reached by another tenant. Customers and auditors ask for test scope, dates and retest after changes. | Test plan and reports from DeployOpen security testing, plus OX App Suite context and access configuration records |
| Scale and load test reports | Evidence that the platform performs at the mailbox counts and peak sessions you have contracted. Confirm the test profile matches your largest planned tenant. | Load test tooling run against the OX App Suite cluster, with MariaDB, Redis and file storage metrics captured during the run |
| Backup and restore test logs | Records that backups can be restored for mailboxes, calendar data and Drive files, not only that jobs completed. Ask for restore timings and the scope of each test. | Backup software job logs and documented restore exercises against MariaDB and the distributed file store (NFS or object storage) |
| Release and patch records tied to the LTS | Shows which OX App Suite release runs in production, when it was installed and that it stays within the vendor's support window. Check the current LTS line in the support commitment before planning. | Change records from the deployment pipeline (Helm chart versions and container image tags), plus the Open-Xchange support commitment as the reference for support dates |
| Administrative and mailbox access logs | Records of who administered the platform and which mailboxes were accessed, needed where a customer is a covered entity under the HIPAA audit controls (45 CFR 164.312(b)). | OX App Suite middleware and admin audit output, Kubernetes API audit logs and identity provider login records, forwarded to a central log store |
| Sender authentication monitoring | Evidence that SPF, DKIM and DMARC are published, aligned and reviewed for every customer domain, and that failures are investigated. | DMARC aggregate and forensic report collection, DKIM signing service logs and DNS change records for each tenant domain |
What do hosting providers and telecoms ask before building white-label mail?
What drives the cost of a white-label OX App Suite deployment?
The biggest cost drivers are the license terms, the infrastructure you run, and the people who operate it. OX App Suite can be deployed on premises, in a public cloud, or as the managed OX Cloud service, so the cost split changes with the model you choose. Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so ask for every module, white-label right and per-mailbox or per-tenant term in writing. One-time costs include design, initial build, integration with your identity and billing systems, and migration. Recurring costs include licenses or support, Kubernetes clusters, storage, database and cache capacity, backups, monitoring, and the staff who patch and upgrade the platform. Ask any quote to separate these lines and to state which costs scale with mailbox count.
How long does a white-label mail deployment take?
The timeline depends on scope, your existing platform, and how many integrations must be finished before the first customer goes live. No fixed duration applies to every provider, so treat any single number as a claim to verify. The main variables are whether a Kubernetes platform, Istio service mesh, and storage backend already exist, how many domains and tenants are onboarded in the first phase, how much branding and provisioning automation must be built, and how long your team needs for acceptance testing. Migration of existing customer mailboxes usually adds the most uncertainty. DeployOpen works from a written, fixed scope, so the schedule and deliverables are agreed before work starts. Ask for the phase breakdown, the dependencies each phase needs from your team, and the acceptance criteria that close each phase.
What must our team supply before the deployment starts?
Your team must provide the platform and skills the deployment runs on, because OX App Suite v8 is designed to run on Kubernetes and is delivered as Helm charts that reference container images. Helm 3.17.0 or newer is required. Plan for the following:
- Kubernetes operators who can manage clusters at N-1 or N-2 supported versions and an Istio installation, or a basic ingress-nginx option where Istio cannot be used.
- Storage: persistent data such as Drive files and PIM attachments needs NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones.
- MariaDB with InnoDB, Redis 7.4.x for caching and sessions, and backup tooling for both.
- DNS control for customer domains, certificates, and an identity provider using OpenID Connect or SAML.
Confirm each item against the current OX requirements before sizing the build.
Can our team run the platform ourselves, or do we need a partner?
A capable platform team can run OX App Suite in-house, but the decision depends on whether that team already operates Kubernetes, Helm, databases and mail protocols at production scale. Partners are most useful for the first build, hardening, the integration of provisioning and billing, and the upgrade path, which is where internal teams most often lose time. Build, partner, or managed service are three distinct options, and the right answer also depends on who carries the on-call duty for customer mailboxes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and ongoing support is available as a retainer. Ask any partner to show who holds each operational duty after handover.
What should scale testing prove before go-live?
Scale testing should prove that the platform holds your target mailbox count, login rate, and message volume on the infrastructure you will run, not on a vendor's reference hardware. Open-Xchange positions OX App Suite as scaling to millions of mailboxes, but your own numbers must come from your test. Require tests for concurrent sessions, IMAP and ActiveSync or JMAP-style client behavior at peak, database failover on a Galera or replicated MariaDB setup, storage performance under the chosen NFS or object storage backend, Redis failure behavior, a rolling upgrade inside the cluster, and a tenant onboarding run that creates many domains at once. Each test should have a written pass threshold agreed before the run.
How do we handle deliverability for customer domains?
Deliverability for customer domains depends on DNS records, sending IP reputation, and outbound policy, and none of these is solved by the groupware platform alone. Each customer domain needs correct SPF, DKIM and DMARC records, aligned signing, reverse DNS, and TLS on outbound connections. Decide whether your own outbound IP ranges will be used or whether a smarthost relays mail, since shared or new IP space can be blocklisted quickly. Set up feedback loops and DMARC report processing, and define who responds to a blocklisting and how customers are told. Ask your team and any partner to show a written process for onboarding a customer domain and a monitoring view that shows reputation per tenant.
How often do we need to upgrade, given the support window?
Upgrade frequency depends on whether you run a standard release or an LTS release, because the support windows differ. Open-Xchange supports a standard release 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. The current LTS is v8.47 (FCS 2026-03-18), and v8.35 is discontinued, which shows how quickly older lines fall out of support. The newest release listed in the support commitment is v8.53, with first customer shipment on 2026-09-23. For a hosting business, the usual planning choice is to standardize on LTS and schedule upgrades inside that window. Ask for the upgrade calendar, the test environment that precedes each upgrade, and the rollback plan.
Who is responsible when a customer mailbox is affected?
Responsibility for a customer mailbox is split between the platform layer, the tenant configuration, the network, and the customer's own devices, so write the split down before launch. Define which team handles platform incidents, which handles tenant-level issues such as DNS or provisioning errors, and what service levels, if any, you offer your customers. DeployOpen does not publish SLAs, so any service level must be agreed in the written scope of the engagement or in a support retainer. Confirm the escalation path with the vendor and your partner, and test it during scale and failover testing.
What to ask an implementation partner before signing
Start with tenancy. Ask the partner how customer domains, mailboxes and administrative roles are separated inside one OX App Suite installation, and which test cases prove that one customer cannot see another customer's mail, calendar or Drive files. Ask for the written isolation test plan and the results from the last run, not a general statement that multi-tenancy is supported. Ask which Helm values and middleware settings define the context boundaries, and who can change them after handover. Next, ask which OX App Suite branch and LTS release they will target and how they will move between releases inside the support window. The support commitment describes standard releases as supported for 12 weeks and LTS releases as supported until the next LTS plus six months, so ask for the upgrade calendar, the rollback method for a failed Helm upgrade, and the test environment used before each change. Confirm the release you are buying is still within its support period on the signing date.
Ask how the partner sizes MariaDB, Redis 7.4.x and the distributed file system for your target mailbox count. Request the sizing worksheet, the assumed connections and session counts, the InnoDB buffer pool and storage growth figures, and the reason for choosing NFS or object storage such as Ceph RadosGW or Scality RING at your scale. Ask which MariaDB version and whether Galera Cluster will be used, and how Redis failover is handled if the littlered operator is replaced with a custom setup. Finally, ask what scale test they run, what load profile it uses (IMAP, JMAP, ActiveSync and CalDAV concurrency, delivery rate and mailbox count), and what evidence they will hand over. Also ask how they handle sender reputation and blocklisting for customer domains, including who holds the SPF, DKIM and DMARC records, and who owns the Helm values and Istio configuration after handover. Confirm in writing which modules and features are licensed, because the Operations Guide notes that some may carry separate fees.
How a provider moves from pilot tenants to general availability
The sequence turns a branded groupware offer into a platform that can host paying customer tenants on a supported release line. Each phase produces a written artifact that the next phase depends on, so scope, scale evidence and operating procedures are settled before customers are moved in.
Agree tenancy model and written scope
The provider and DeployOpen define how tenants are isolated, how many mailboxes each tenant and the platform as a whole must carry, which branding each customer can change, and how identity federates with each customer's directory. Both sides sign a fixed-scope document covering these decisions and the deliverables. The step is complete when the tenancy model, mailbox targets, branding limits and identity design are written down and agreed by the provider's product and security owners.
Build the lab on Kubernetes with Helm
The team deploys OX App Suite v8 into a non-production cluster using the supplied Helm charts, with the Istio or ingress-nginx option chosen against the provider's network design. It also sets up MariaDB with InnoDB, Redis, and a distributed file system for Drive files and attachments, using NFS or object storage depending on the target size. Helm must be at 3.17.0 or newer, and Kubernetes versions must fall within the N-1 or N-2 range the product supports. The step is done when a clean install reproduces from version-controlled manifests and a test tenant can log in, send and receive mail, and sync calendars.
Run scale and failure tests with recorded results
The team loads the lab with synthetic mailboxes at the target count, drives realistic protocol traffic, and measures login, mail delivery and calendar response times under load. It then injects failures such as a node loss, a database failover, a Redis restart and a storage interruption, and records how long each service takes to recover. Test results, configuration versions and any tuning changes go into a signed test report. The step is complete when the provider accepts the report against its own targets, and any gaps have a remediation plan with an owner.
Harden the platform and confirm licensing
Before customers arrive, the team applies security baselines to the cluster, secrets management, network policies and database access, and reviews audit logging for administrative and tenant actions. The provider confirms in writing which modules, features and tenant limits its license covers, since the vendor's operations guidance says some modules may be packaged or charged separately. The step is done when the security review findings are closed or accepted in writing and the licensed feature list matches what the pilot will use.
Pilot with a small set of customer tenants
A limited group of customer tenants is provisioned on the production cluster with agreed branding and identity integration. The team builds and tests migration tooling for moving existing mailboxes, calendars and contacts from the customer's current system, and verifies message counts and folder structure after each run. Customer support staff use the runbooks drafted in the earlier phases during the pilot. The step is complete when pilot tenants have migrated without data loss in checks the provider accepts, and support issues are logged with root causes.
Write runbooks and set up monitoring
The team documents operational procedures for tenant onboarding and offboarding, quota changes, backup and restore, incident response and certificate renewal, then tests each runbook against the lab. Monitoring and alerting cover service health, queue depth, storage growth, database replication and per-tenant error rates, with thresholds agreed with the provider's operations team. The step is done when the runbooks have been executed once by the provider's own staff and alert routes reach a named on-call rota.
Open general availability on a supported LTS calendar
The provider opens the service to all customers and publishes a upgrade calendar based on the vendor's support commitment, which distinguishes standard releases from LTS releases and states when each one ends support. The team schedules upgrades in the lab first, repeats the scale tests on the new release when the change is material, and keeps a rollback plan for each upgrade. The step is complete when the provider has a dated upgrade plan, a named owner for each release line, and a signed handover of the platform, runbooks and test evidence.
How DeployOpen scopes and supports a provider's mail service
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the provider's own infrastructure, whether that is its cloud accounts, data centers or private networks. For a hosting provider or telecom, that means the OX App Suite deployment, its Kubernetes cluster, the Istio or ingress layer, the MariaDB and Redis data tier and the distributed file storage for mailbox attachments all run on infrastructure the provider controls. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a written statement that names the OX App Suite release line, the Kubernetes and Helm versions, the tenancy model and each component the work covers, and that states which items are excluded, such as mailbox migrations for end customers or outbound relay operation.
Operating a white-label mail service is an ongoing commitment, so DeployOpen also offers retainers for upgrades, ongoing support and continuous testing. The practical question is how upgrades will be tested against the release cadence in the Open-Xchange support commitment, where standard releases have a short support window and LTS releases are supported until the next LTS release plus six months. A retainer should define who plans each move to a supported release, who validates it in a staging cluster, how rollbacks are handled and what response is expected when a security update lands. Confirm these terms in writing rather than assuming them from the general service description.
Security testing of the service is a separate, scoped engagement. It can cover the public web and API surfaces of the webmail and provisioning portals, the cloud and infrastructure layer, and the tenant isolation controls that keep one customer's mailboxes and address books out of another's view. DeployOpen does not publish prices, does not issue audit reports or attestations, and is not an official OX partner, reseller or certified provider unless that status is confirmed in writing for a specific engagement. Ask any provider to state its partner status with Open-Xchange and to supply a quote built from your scope.
