What OX App Suite Switchboard adds to a v8 installation
OX App Suite Switchboard is the component that handles presence, live events and web push notifications for users who are offline from the browser. Teams need it when they want colleagues to see who is online and want people to be notified about activity when they are away from the browser. It is an addition to a v8 installation, so it extends an existing platform rather than replacing any part of it. Plan it as a deliberate scope item in the same way you plan the base install, with its own owner, change record and test plan.
Your starting point is a v8 deployment on Kubernetes, delivered as Helm charts that reference container images, with Helm 3.17.0 or newer. The base platform already brings its own dependencies: Istio, or the basic ingress-nginx option where Istio cannot be used, Redis 7.4.x for caching and session storage (deployed by default through the littlered operator), and MariaDB as the primary data store. Switchboard runs on this foundation. Before you commit to a design, confirm in the Open-Xchange documentation for your release which of these dependencies Switchboard uses, whether it needs its own Redis or database objects, and how its traffic should pass through your ingress and service mesh.
Switchboard also changes what your infrastructure must allow. Web push delivery reaches browsers through push services that run outside your cluster, so your network team needs to know which outbound paths the component requires and how they are approved under your egress policy. Presence and live event traffic is a different pattern, and it depends on how long-lived connections behave through your load balancers and proxies. Ask Open-Xchange for the exact endpoints, ports, certificate requirements and any key material that web push needs, and record the answers before you size the cluster. Do not assume these details carry over from the base install.
Three checks belong in the plan before any build work starts. First, confirm that the Switchboard version matches the v8 release you run, because support follows release timing: standard releases are supported for 12 weeks, and LTS releases are supported until the next LTS release plus six months. v8.47 (FCS 2026-03-18) is the current LTS. Second, ask Open-Xchange for the resource requirements for Switchboard in your deployment size, and ask whether Switchboard is covered by your license, since the Operations Guide notes that some modules may be packaged or priced separately. Third, agree the upgrade path with your release calendar, so Switchboard moves with the platform rather than falling behind it.
Which Switchboard decisions to make before installation
This table lists the configuration decisions to settle before installing Switchboard, with the situations where each option fits and what to confirm with Open-Xchange. Read it before the architecture review, because ingress and outbound traffic choices change the cluster design. The main takeaway is to settle presence scope and the ingress path first, since they shape the rest of the rollout.
| Decision | When it fits | What to confirm with Open-Xchange |
|---|---|---|
| Presence for all users or a pilot group | A pilot group fits a first rollout, so you can watch load and client behavior before wider enablement. All users fits when presence is an expected standard across the tenant. | Which users and clients Switchboard serves, and how presence is enabled for a subset of users. |
| Web push to offline users in scope | Fits when users expect notifications while the browser tab is closed. Leave it out if notifications should only reach active sessions. | Whether offline web push is supported in your v8 release, and which browsers and prerequisites apply. |
| Path for browser push traffic out of the network | Fits when browsers must reach an external push service. Map this path early, because it affects firewall rules and any proxy design. | Required outbound destinations, proxy support, and whether traffic leaves through the cluster egress path. |
| Ingress for long-lived connections | Istio is required for v8, so it is the default choice. The basic ingress-nginx option fits only where Istio cannot be used. | Whether Switchboard follows the same Istio route, the connection timeout settings, and any ingress-nginx limits for persistent connections. |
| Owner of push and notification policy | Fits when a named team decides which events notify users and how often. Assign the owner before the pilot so changes have a reviewer. | Where notification policy is configured, who may change it, and which settings need change control. |
| Dependence on the v8 Redis deployment | The default v8 Redis is deployed through the littlered operator. A custom or unmanaged Redis fits if your team already operates one that meets the requirements. | Whether Switchboard depends on the same Redis instance, and which Redis topology and version it supports. |
How presence, live events and web push reach users
Switchboard adds three functions to an OX App Suite v8 installation, and each one reaches the user by a different route. Presence shows whether a contact is online. Live event delivery updates an open session, such as a new message or a changed calendar entry, without a page reload. Web push notifies a user whose browser is closed or in the background. Platform teams should plan these as separate paths, because each has its own connection pattern, failure mode and network rule.
For an open browser session, the path runs from the browser to the App Suite middleware, which hands events to Switchboard, which then delivers them back over the session the browser already holds. For a closed browser, Switchboard sends the notification outbound to the push service run by the browser vendor, and that service holds it until the browser picks it up. The cluster therefore needs both inbound paths for live sessions and an outbound path for push. Map these flows on a diagram before you size anything, and show the ingress, the middleware pods and Switchboard as distinct boxes.
The dependency list is the item most likely to change your cluster plan. Confirm in the Switchboard documentation which Redis, database or storage components it reads from and writes to, and whether it needs its own instances or can share the ones used by App Suite. The App Suite requirements page is the baseline for the cluster itself: Kubernetes versions N-1 and N-2, Istio or the basic ingress-nginx option, Redis 7.4.x for caching and session storage, and MariaDB with InnoDB. Check how your chosen ingress handles long-lived connections, since live delivery depends on them staying open.
Push adds two decisions that are easy to overlook. First, outbound egress from the cluster to browser push services must be allowed by your firewall, proxy or network policy, and some restricted or air-gapped networks cannot allow it at all, so decide early whether push is in scope for each environment. Second, push delivery involves endpoint identifiers that pass through external services, so have your security and privacy owners review what metadata leaves your infrastructure. Verify each path with two browser sessions, a closed browser and a deliberate failure of one component, and record what each user sees.
How to deploy Switchboard on a v8 Kubernetes cluster
This sequence takes a v8 installation from version checks to working presence, live events and web push in your own cluster. Each step ends with a check that shows it is complete, so the team can fix a gap before the next layer depends on it.
Confirm the App Suite release and Helm version
The platform engineering lead confirms that the target is App Suite v8 and that the Helm client on the deployment machine is version 3.17.0 or newer, the minimum stated in the OX App Suite requirements. Check the release bundle you plan to deploy against the requirements page for that release, and record the chart and image versions in the change ticket. Done when the Helm version check reports 3.17.0 or newer and the bundle version matches the release your team has approved for production.
Check the Kubernetes version against the supported range
The cluster owner confirms that the Kubernetes minor version falls within the N-1 or N-2 range that App Suite v8 supports, as listed on the requirements page for the release. Confirm node capacity, storage class and network policy against the same page, and ask the vendor which Kubernetes features the release depends on. Done when the cluster version sits inside the supported range and a dry-run install renders without API errors.
Settle the routing layer with Istio or ingress-nginx
The network architect decides between Istio and the basic ingress-nginx option. App Suite v8 requires Istio and supports the latest Istio release plus two prior versions, while ingress-nginx is the option where Istio cannot be used. Record the decision, the Istio version if chosen, how TLS certificates are issued, and how the controller routes traffic to the middleware and Switchboard endpoints. Confirm with the vendor documentation that the controller passes the long-lived connections Switchboard uses. Done when a test route resolves inside the cluster through the chosen controller.
Prepare the Redis and MariaDB backends
The database and platform team confirms the backends the installation already uses. App Suite v8 uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator, and MariaDB with the InnoDB storage engine as its primary data store. Supported MariaDB versions are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Confirm the versions in use, backup coverage and the distributed file system for persistent data. Done when the Redis and MariaDB versions appear on the supported list and a connection test from the target namespace succeeds.
Deploy Switchboard from the release bundle
The platform engineer installs Switchboard with the Helm charts and container images from the same release bundle as the core App Suite installation, so chart and image versions stay aligned. Pull images through your internal registry according to your mirror process, set values that reflect the routing and backend choices made earlier, and run the install in a staging namespace first. Done when all Switchboard pods report ready, the rollout finishes without configuration-related restarts, and the health endpoint named in the release documentation responds.
Enable presence for a pilot group first
The service owner turns on presence for a small pilot group so problems appear before the whole user base depends on it. Choose pilot users who can sign in from two browsers, record the group in the change record, and agree with them what correct presence looks like. Check that presence updates across two browsers: a status change in one browser should appear in the other within the window the release documentation describes. Done when the pilot group sees correct presence in both browsers with no duplicate or stale status.
Enable web push with the provider settings
The messaging owner adds the push provider settings and enables web push once presence is stable for the pilot group. Confirm the provider, credentials and sender identity against the vendor documentation, and store the credentials in your secrets manager rather than in plain configuration files. Keep the rollout limited to the pilot group until the checks pass. Done when the provider accepts the configuration and the service logs show no authentication or certificate errors after restart.
Verify presence, live events and closed-browser push
The QA lead runs the final checks in order: presence updates across two browsers, a live event reaching an open session, and a test push reaching a closed browser on each client type in scope. Record the client types, browser versions and result of each check. Confirm the list of client types in scope with your support team, since it depends on how your organization uses the platform. Done when all three checks pass for every client type in scope and the results are attached to the change record.
Routing long-lived connections through Istio or ingress-nginx
Routing live event traffic is the ingress decision that most affects whether Switchboard behaves correctly after go-live. Presence and real-time events depend on connections that stay open for long periods, sometimes with little traffic on them. An ingress tuned for ordinary page loads, with short request timeouts and aggressive idle cutoffs, will close these connections while they are still in use. The symptoms are intermittent reconnects, delayed presence updates and missed events. They are hard to diagnose because each individual request still looks successful in the access logs.
The v8 requirements call for Istio, and they state that the supported range covers the latest Istio release plus two prior versions. Your team would own the mesh, the ingress gateway, the routing objects that send Switchboard traffic to its services, and the timeout and connection settings applied to those routes. Where Istio cannot be used, the requirements document a basic ingress-nginx option. That path is more familiar to many platform teams, but it is documented as basic, so you should confirm what it covers before you commit to it. Make this choice before the cluster design is frozen, because changing the ingress layer later touches DNS, certificates and load balancer configuration.
The trade-off is mainly about skills and what is supported. Istio brings a larger operational surface: upgrades, traffic policy, certificate handling and troubleshooting across sidecars and gateways. Teams without mesh experience will need time to build that competence, and it recurs with each Istio upgrade within the supported range. ingress-nginx is simpler to operate, but you will set the long-lived connection behavior by hand, and the upgrade path and feature coverage may differ from the Istio path. Ask Open-Xchange which features each path supports for Switchboard, including presence, real-time events and web push delivery, so you do not find a gap during testing.
Before you build, get three answers from Open-Xchange in writing: which routing path the Switchboard release you plan to deploy supports, which timeout and connection settings it expects at the gateway and at any upstream load balancer, and whether those expectations change between releases. Then test the chosen path with an idle connection held open longer than your default proxy timeout, a forced server restart and a client reconnect. Cloud load balancers often have their own idle timeouts, so include them in the test. Record the settings in your runbook, because a later change to a timeout in any layer can reproduce the same silent drops.
Securing presence data, push subscriptions and session access
Switchboard handles data that is sensitive in ways a typical application log is not: who is online, when, and which devices can be woken. The cards below cover the decisions a security team should make before enabling presence and web push, and the controls that keep them enforceable. Each item is a design decision to settle with the Open-Xchange documentation and your own environment, not a default to accept.
Decide who can see presence
Presence data reveals working patterns, such as when a person starts, stops, or is away from their desk. Decide which users can see whose status before rollout, and whether visibility follows directory groups, mail domains, or only direct contacts. Test the visibility rules with accounts from different departments and confirm in the Switchboard documentation how presence is scoped and whether users can opt out.
Store and rotate push subscriptions
A web push subscription contains an endpoint and key material that let a server send messages to a specific browser. Treat these values like credentials: restrict who and what can read the subscription store, keep it out of logs and backups where access is looser, and define how stale or revoked subscriptions are removed. Ask the vendor how subscriptions are encrypted at rest and how rotation of the server's push keys would be handled.
Keep message content out of push payloads
Push notifications pass through browser push services operated by third parties, so the payload should not carry message subjects, bodies, or attachment names unless the design has been reviewed. A common safe pattern is a generic alert that points the user back to the App Suite session. If your policy allows richer payloads, record that decision, the data classes involved, and who approved it before enabling the feature.
Allow and log outbound push traffic
Switchboard sends web push requests to the push services used by each browser vendor. Add an explicit egress rule for those destinations from the Switchboard workload rather than opening general outbound access, and log the requests and failures at the egress point. Confirm in the vendor documentation which destinations are required, whether they can be restricted by name or address, and how proxies affect delivery.
Apply the App Suite SSO and session policy
Access to Switchboard should follow the same single sign-on and session rules as the rest of App Suite, including identity provider policy, multi-factor requirements, and session lifetime. Check that a user disabled in the directory also loses presence visibility and push delivery, and that a session revoked in App Suite stops Switchboard connections. Test these paths explicitly, because a separate login route is a common gap.
Confirm encryption, retention and logging
Do not assume how presence records, subscriptions, and event logs are encrypted, how long they are retained, or what is written to logs. Ask Open-Xchange for the documented behavior for each data type, map it to your data classification and retention schedule, and confirm that logs do not contain push endpoints or message content. Record the answers as part of the implementation evidence, since assessors will ask for them.
Operating Switchboard across App Suite upgrades
Ongoing work on Switchboard starts with a monitoring baseline taken in the first weeks after go-live. Track three signals: the number of open connections for presence and real-time events, the rate of web push delivery failures to offline users, and the latency between an event being raised in App Suite and the client receiving it. Record these values during normal usage so later changes are easy to read. Set alerts on sustained deviations and agree in advance who receives them. Each alert should link to a runbook entry that tells on-call staff whether the fault sits in Switchboard, in the push delivery path or in the App Suite middleware. Confirm with the vendor which metrics each Switchboard version exposes, because metric names can change between releases.
Release timing sets the pace for Switchboard upgrades. Under the Open-Xchange support commitment, a standard release is supported for 12 weeks, ending when the third following release becomes available. An LTS release is supported until the next LTS release plus six months. At the time of the supplied commitment, v8.47 is the current LTS and v8.53 is the newest release listed. A team on a standard release has a much shorter support window than a team on an LTS line, so the release channel you choose also determines how often upgrades must happen. Record the support end date for your App Suite release in the operations calendar and review it at each planning cycle.
Plan Switchboard upgrades inside the same change window as the App Suite upgrade. Treat them as one change with one approval, one rollback point and one verification pass, because presence, real-time events and push delivery only work reliably when both components match the release you are moving to. Before each move, check the compatibility of the Switchboard version with the chosen App Suite release against the vendor documentation. If the pairing is not confirmed in writing, hold the change. The App Suite charts are delivered as Helm charts, so keep the previous Helm release revision available and rehearse the rollback in a staging cluster that mirrors production. Note the Helm 3.17.0 minimum in the runbook.
Ask a partner to price the ongoing work as a separate line from the initial build. A quote should state which monitoring, alert tuning, release tracking and upgrade rehearsals are included, how many upgrade cycles are covered, and who acts when a Switchboard release lags the App Suite release you plan to move to. Ask whether any Switchboard capability is licensed separately, since the Open-Xchange Operations Guide notes that certain modules or features may be subject to custom packaging, limitations or fees set in the license agreement. Retainers are available for ongoing support and upgrades, so compare that option with keeping the work in-house and carrying the on-call load yourself.
What to confirm about Switchboard in your environment
The supplied facts do not settle several points that determine whether Switchboard fits your deployment. Each card below is a question to put to Open-Xchange or to check in the release notes before you commit to a design.
Switchboard release for your App Suite version
Ask Open-Xchange which Switchboard release ships with the App Suite v8 version you plan to deploy, and whether it is pinned in the Helm chart or chosen separately. Confirm that the release is in the support window you need, since standard releases are supported for 12 weeks and LTS releases for a longer period. Record the exact chart and image versions in your change plan so upgrades stay matched to the middleware.
Supported browsers and mobile clients for push
Ask which browsers and mobile clients receive web push notifications from Switchboard, and which minimum versions they require. Check whether mobile push depends on a separate app or on the browser layer, because that changes what your users must install and what your device policy has to allow. Test the list against the browsers and devices your organization actually manages.
Push provider and outbound internet access
Confirm which push provider or delivery service Switchboard uses for web push and mobile notifications, and whether it calls an external endpoint. If it does, ask for the exact destinations, ports and protocols so your network team can allow them through egress controls and proxies. Also ask whether message content leaves your cluster or only a notification signal does.
Web push in air-gapped deployments
Ask Open-Xchange whether an air-gapped installation can use web push at all, given that browser push services usually sit on the public internet. If it cannot, find out what real-time events and presence still work without outbound access, and whether a local fallback exists. Document the answer before the air-gapped design is approved, because it changes what users in disconnected sites receive.
Presence scaling limits for your user count
Ask for the documented limits on concurrent users, sessions and presence updates per Switchboard instance, and how these scale when you add pods. Share your expected peak user count and ask whether a load test or reference figure exists for a comparable size. Do not size the rollout from marketing claims about mailbox counts, because presence load depends on concurrent sessions rather than total accounts.
Resource sizing for Switchboard pods
Request the CPU and memory requests and limits for Switchboard pods, the number of replicas recommended for high availability, and any connection requirements to Redis. Ask how these values change with user count and whether the Helm chart sets defaults you must override. Confirm the sizing with a test deployment before you set node pool capacity.
Licensing and separately packaged features
Ask Open-Xchange whether Switchboard, presence or push features are included in your license or subject to custom packaging, limitations or separate fees under your agreement. Get the answer in writing with the module names and the terms that apply, since the Operations Guide states that some modules or features may be licensed separately. Include this in the quote so the scope and recurring costs are clear before implementation starts.
What buyers ask before bringing in a partner for Switchboard
How much more effort is Switchboard than a base App Suite install?
Switchboard is added work on top of a working OX App Suite v8 installation, so the base platform must be healthy first. That base includes the Kubernetes cluster, Helm 3.17.0 or newer, Istio or the basic ingress-nginx option, Redis 7.4.x, MariaDB and a distributed file system for persistent data. Switchboard then adds its own ingress paths, real-time event and presence traffic that must be tested through those paths, and push notification egress from the cluster to the push services your users' devices depend on. Most of the extra effort sits in network design and testing, not only in the chart install. Ask any partner to split its written scope into base platform checks, Switchboard components and verification, so you can see which parts your existing team already covers.
What drives Switchboard cost up or down?
The main cost drivers are user count, the number of ingress paths, push scope, air-gapped constraints, change windows and the state of your existing App Suite build. A larger user count and more ingress paths increase design and test effort. A wider push scope, meaning more clients, device types and notification types, adds testing and sign-off. Air-gapped networks add mirroring and egress design work. Strict change windows lengthen calendars even when the technical work stays the same. A clean, documented base build reduces discovery time. Cost splits into design, build, testing, documentation and handover, which are one-time, plus any ongoing support or upgrade retainer, which recurs. Ask for a quote with those lines separated and with the assumptions for each driver written out.
How long does a Switchboard engagement run and what sets it?
The duration is set by the written scope agreed before work starts, because most DeployOpen engagements are fixed-scope with agreed deliverables and timelines. The scope determines how many ingress paths, push flows and environments are in play, and how many test cycles are needed. Timing also depends on external factors you control: approvals from network and security teams for push egress, the availability of cluster access and DNS and certificate changes, and the dates of your change windows. Delays often come from waiting on approvals rather than from the build itself. Ask the partner to name each dependency in the scope, the party responsible for it and the date it must be resolved, so the schedule can be checked against your calendar.
What must our team provide before a partner starts Switchboard work?
Your team needs to provide several items before the build starts. Cluster access must be granted to the people and pipelines that will deploy the Helm charts. DNS records and TLS certificates must be ready for the Switchboard hostnames. A test user group is needed so presence, real-time events and web push can be verified with real accounts before go-live. Network approvals are required for push egress, so the cluster can reach the push services your devices use. Finally, name an owner for each area: platform, network, identity, mail operations and the business sponsor who signs off. Missing owners cause the most schedule slippage, so confirm them in the written scope.
Can our own platform team deploy Switchboard without outside help?
Yes, your own team can deploy Switchboard if it has working skills in Kubernetes, Helm and ingress, and enough time to test. Those skills cover reading and editing Helm values, managing Istio or ingress-nginx routes, handling secrets and certificates, and debugging pods and network policies. Testing is often the larger commitment, because presence, real-time events and push delivery must be checked across browsers, devices and failure cases. Teams with these skills but no spare test capacity often bring in a partner for design review or verification only. DeployOpen can plan, implement and document the work, or support your team through a retainer. Compare the two options using the same written scope and your team's named owners.
Does an air-gapped network change the Switchboard scope and cost?
An air-gapped network changes the scope because the cluster may not reach the external push services that web push normally depends on. Confirm early whether your push design relies on services outside your network, and whether any approved relay, proxy or egress path exists under your security policy. Image and chart delivery also changes, since the registry mirror and local Helm charts must carry the Switchboard components, and updates must reach the environment through an approved route. Each of these adds design, approval and test work that a connected install does not need. Ask any partner to list the egress assumptions in writing, because the push design decides whether Switchboard can meet the requirements you set for offline users.
Which App Suite v8 versions and dependencies should we confirm first?
Confirm the platform versions before scoping, because Switchboard runs on top of the v8 stack. OX App Suite v8 supports Kubernetes versions N-1 and N-2 and requires Istio, supporting the latest Istio release plus two prior versions. Helm 3.17.0 or newer is required. Redis 7.4.x is used for caching and session storage, and MariaDB with InnoDB is supported in versions 10.6.x, 10.11.x, 11.4.x and 11.8.x. Persistent data must sit on NFS for small to mid-size deployments or on object storage for larger ones. The current LTS is v8.47 (FCS 2026-03-18), and the newest release listed in the support commitment is v8.53. Check each version against the Switchboard release your partner plans to deploy before the scope is signed.
Who keeps Switchboard supported after go-live and across upgrades?
Your organization keeps ownership of the running service, and the support model must be agreed in writing. Open-Xchange supports a standard release 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. That means upgrades must be scheduled against these windows, and Switchboard must be checked at each App Suite upgrade. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can cover monitoring of push delivery, chart upgrades and regression checks. Ask for the handover documentation, the runbook for presence and push failures, and the named owners who will receive alerts and approve changes.
How DeployOpen scopes and delivers a Switchboard rollout
DeployOpen plans, implements, hardens and documents OX App Suite Switchboard and push notifications inside your own infrastructure, on top of an OX App Suite v8 installation delivered as Helm charts on Kubernetes. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names which Switchboard capabilities are in use: presence, real-time events and web push to offline users.
- Scope records the v8 installation it extends, including Kubernetes cluster, Helm chart version and Redis dependency.
- Engagements are fixed-scope, and ongoing support is available as a retainer once the rollout is live.
How we build
- A non-production environment comes first, so presence and push behavior are checked before users see them.
- Routing for Switchboard traffic is configured through your chosen ingress, Istio or ingress-nginx, and tested.
- Push notification credentials, secrets and browser subscription data are handled under your key management and retention rules.
How we hand over
- Deliverables include deployment code, configuration, a verification checklist and runbook for Switchboard operators.
- Test evidence covers presence updates, real-time event delivery and web push to a device with no open session.
- Your team receives documentation for upgrades, rollback, and how Switchboard changes when the App Suite release channel moves.
How we support
- Upgrades follow Open-Xchange's support commitment, where standard releases are supported for 12 weeks.
- Upgrade planning starts from the LTS release in effect when scoping, confirmed against Open-Xchange's support commitment.
- Ask the license terms for Switchboard during scoping, since some OX modules carry separate fees.
