OX App Suite AI integration: what it changes for your mail and where the model runs
A regulated organization that wants AI compose and summarization in OX App Suite usually has to answer one question before any feature question: where does the message text go when the model runs? The integration comes down to two choices, the model backend and the network path between App Suite and that backend. A backend inside your own cluster or data center keeps prompts and mail content inside infrastructure you control. A hosted model service sends them outside it. The documentation we work from covers the App Suite v8 platform and the model-serving options, but it does not give a per-release list of AI features. Confirm with Open-Xchange which AI features your release includes, which model endpoints each one calls, and whether the feature set changes between the releases you plan to run.
Teams usually need a self-hosted backend in three situations: mailbox content is sensitive enough that a third-party processor needs formal review, data residency rules require processing in a named jurisdiction, or AI use must be auditable, meaning you can show which model handled which request, under which user identity, and what was logged. The supplied material also notes that some App Suite modules may be licensed separately and subject to custom packaging or fees set in the license agreement. An AI capability may therefore carry commercial terms even when the model runs on your own hardware. Ask for those terms in writing as part of the scope, not after the design is approved.
The model-serving options expose different controls. vLLM, licensed under Apache-2.0, serves an OpenAI-compatible API through its server command, and its security documentation states that the --api-key option does not protect every endpoint, including metrics and health checks. It recommends a reverse proxy that allowlists only the endpoints users need. Its multi-node communication is insecure by default and must be placed on an isolated network. Ollama, licensed under MIT, binds to 127.0.0.1 on port 11434 by default and its local API requires no authentication. Exposing it to App Suite means changing the bind address deliberately and placing an authenticating proxy in front of it. Setting OLLAMA_NO_CLOUD=1 turns off its cloud features. In both cases, the network design is part of the integration, not an afterthought.
A self-hosted backend is not the right first step for every organization. If your mail is not sensitive and a contracted provider already meets your residency and audit requirements, a hosted option may be simpler to run. If you have no accelerator capacity and no team to operate a model server, the cost sits in hardware, implementation and ongoing operations, and the model server becomes a new production service with its own patching, capacity planning and monitoring. Before you scope the work, ask Open-Xchange and your model provider three things: whether the AI feature can point at a self-hosted OpenAI-compatible endpoint, what data is logged on the App Suite side, and what is logged on the model side.
Which model backend fits your data rules
This table compares three ways to supply the model behind OX App Suite AI features. Read each column against your data residency rules, who may operate the model, and how much infrastructure your team will run. Confirm supported backends and licensing terms with Open-Xchange before you choose, because the choice determines where mail content is processed.
| Decision point | Vendor-hosted AI service through Open-Xchange | Model endpoint in your cluster or data center | Public cloud model API from your account |
|---|---|---|---|
| Where prompts and mail content are processed | In the vendor's hosted service, outside your cluster. Confirm processing location and retention in writing. | Inside your cluster or data center, on hardware you operate. Mail content stays on your network if the endpoint is isolated. | In the cloud region you select within your own account. Confirm which regions and retention settings apply to each model. |
| Who operates the model | The service provider runs the model. Confirm the operator and any sub-processors with Open-Xchange. | Your team, or a partner you engage, runs the serving software, accelerators, scaling and updates. | The cloud provider runs the model. Your team manages keys, quotas, access and logging. |
| What to confirm before you choose | Supported backends, licensing terms and processing regions for the AI features, as stated by Open-Xchange. | Which model serving software Open-Xchange supports, the license of each model you plan to use, and the hardware it needs. | Which providers Open-Xchange supports, the data processing terms in your contract, and the region options for each model. |
| Main trade-off | Least infrastructure for your team to run, but the least control over where data is processed. | Most control over data location, but your team carries capacity planning, patching and operating cost. | Managed model capacity without running hardware, but mail content leaves your infrastructure for processing. |
| When it fits | Your data rules allow processing by the vendor under a signed agreement with defined terms. | Mail content must remain inside your boundary and you can fund and staff accelerator capacity. | Your rules permit processing in an approved cloud region and you prefer managed model capacity. |
How prompts and mail content move through the integration
The part of this integration you need to map is the AI request path: the route a prompt takes from the App Suite middleware to a model endpoint and back to the user. The persistent stores stay in your environment under either backend pattern. Drive files and PIM attachments sit on the distributed file system, and primary data sits in MariaDB. What moves is the content the middleware places in each AI request, which can include the user's instruction, the text of the selected message or document passage, attachment content if the task uses it, and the model's output. Ask Open-Xchange to confirm exactly which fields each request type (compose, summarization and multi-step tasks) sends, because that list determines what your security team must approve.
In a self-hosted pattern, the path stays on your network. The user's action goes from the browser to the App Suite middleware. The middleware calls a model server you run, for example a vLLM server exposing OpenAI-compatible endpoints such as /v1/chat/completions, or an Ollama instance on port 11434. The model server runs inference on your hardware and returns the output through the middleware to the browser. Ollama binds to 127.0.0.1 by default, so the middleware can only reach it after you change OLLAMA_HOST and open a controlled network path. vLLM's --api-key option does not cover /metrics or /health, so place a reverse proxy in front that allowlists only the endpoints the middleware needs.
In an external pattern, the request leaves your network. The middleware sends the prompt and selected text to a provider's endpoint over the internet, and the output returns the same way. Ollama's direct cloud inference, for instance, requires an API key sent as a Bearer token, and cloud features can be disabled with OLLAMA_NO_CLOUD=1. Each provider's retention, training use, data location, subprocessors and log retention are set by its own terms, so get those in writing before any content is sent. Also confirm where the API key is stored and who can rotate it. Once a draft is saved, it is stored in your mail environment, but any copy the provider keeps remains outside your control.
Check logging on both sides before go-live. On the App Suite side, confirm the middleware log level and whether request or response bodies are written to application logs, and where those logs are shipped. On the model side, review the model server's request logs, any reverse proxy access logs, Kubernetes log collection and the provider's logs if you use one. Metrics endpoints such as vLLM's /metrics expose request counts, token throughput, latency and cache use, so confirm they carry no prompt text and restrict who can read them. Ask each party to state its retention period for each log in writing.
Before you choose a backend, draw the flow with Open-Xchange and your security team. Mark every hop, each field sent, each place content or output is stored or logged, the retention period at each point, and who holds each credential. For a multi-node vLLM deployment, add the node-to-node traffic, which the vLLM security documentation describes as insecure by default and requiring an isolated network. Record the sign-off in your change record, and repeat the review when you add a model, change the log level or update the middleware.
How to set up AI features in OX App Suite v8, step by step
This sequence takes an App Suite v8 installation from a written feature and licensing check to a controlled rollout of AI compose and summarization. Each step ends with a check the team can record, so the pilot and wider rollout rest on documented evidence.
Confirm AI feature licensing for the target release
Ask Open-Xchange, in writing, which AI features your target v8 release includes and whether they fall under your license agreement. The Operations Guide notes that some modules or features may carry custom packaging, limitations or separate fees set in that agreement, so procurement and the platform lead should own this step together. Done when a written statement names the feature set, the release and any additional fees, and the platform team has filed it with the project record.
Confirm the App Suite release line and prerequisites
Choose the App Suite release line, either the current LTS or a standard release still inside its support window, and confirm the release status against the current support commitment before you commit. Check that your Kubernetes version falls within the supported N-1 or N-2 range, that Istio is the latest release or one of its two prior versions (or that ingress-nginx is an accepted basic option where Istio cannot be used), that Helm is 3.17.0 or newer, and that Redis 7.4.x, a supported MariaDB line and a distributed file system are ready. Done when the platform team signs off a checklist built from the requirements page.
Choose the model backend pattern
Decide where the model runs and who operates it. Self-hosted vLLM, licensed under Apache-2.0, exposes OpenAI-compatible endpoints and needs accelerator capacity sized to your models and expected concurrency. Ollama, licensed under MIT, is often simpler for smaller models and binds to localhost by default. Confirm with Open-Xchange which endpoint types the AI feature supports in your release before you choose. Done when a decision record names the backend, the hardware, the operating team and the data path, and security has signed it.
Provision the model endpoint on an isolated network
Deploy the runtime in a network segment that only App Suite workloads can reach. The vLLM security documentation states that communication between nodes in a multi-node deployment is insecure by default and must be protected by an isolated network. Pin a tested runtime version, since vLLM ships minor releases about every two weeks. For Ollama, keep the bind address on loopback or an internal interface through OLLAMA_HOST, and set OLLAMA_NO_CLOUD=1 if inference must stay local. Done when a test pod inside the App Suite namespace reaches the endpoint and a pod outside it cannot.
Configure authentication and network policy
Protect the endpoint at two layers. The vLLM --api-key option covers the /v1 routes but not /metrics, /health or /invocations, and the documentation advises against relying on it alone. Place a reverse proxy in front of the runtime that allowlists only the routes App Suite calls, and add Kubernetes network policy that admits only App Suite workloads. Ollama's local API has no authentication, so the proxy must supply it. Done when an unauthenticated request is rejected, an allowlisted request succeeds and /metrics is unreachable from user networks.
Enable the feature for a pilot group
Enable the AI feature for a small pilot group using non-sensitive test mailboxes and documents. Follow the configuration steps that Open-Xchange confirms for your release, and record which users, which features and which endpoint address are active. Pilot users run compose and summarization tasks on test mail and report wrong, missing or unexpected output. Done when pilot users complete the agreed test scenarios and the security lead confirms that no production mail reached the model.
Verify output, logs and metrics
Check output quality, logs and metrics before anyone else gets access. Compare generated text with the expected result for each test case, then trace one request from App Suite through the proxy to the endpoint. Scrape vLLM's Prometheus-format metrics at /metrics for request counts, token throughput, latency and KV cache use. For Ollama, review the parallel and queue settings, which default to one parallel request per model and 512 queued requests, and adjust them to the pilot load. Done when dashboards show pilot traffic and a deliberately failed request appears in the logs.
Widen rollout in controlled waves
Expand access one group at a time, with a go or no-go decision recorded at each wave. Recheck capacity and concurrency against the pilot metrics before each expansion. Plan runtime and App Suite upgrades in advance, keeping in mind that vLLM minor releases arrive frequently and App Suite standard releases have a fixed support window. Done when each wave has a recorded decision, the rollback path has been rehearsed and a named owner runs the endpoint for ongoing operation.
Security controls to plan before any AI request leaves App Suite
Each control closes a path by which mail content could reach a model or stay longer than intended. Plan them together, because the proxy allowlist, caller identity, network isolation, and logging decisions each assume the others are in place.
Restrict the model endpoint to user-facing paths
Model servers expose more than the routes applications call. The vLLM security documentation recommends a reverse proxy that allowlists only the endpoints meant for users, because the --api-key option does not cover paths such as /metrics, /health or /invocations. Check from outside the cluster that only the paths App Suite needs respond, and that every other route is refused.
Authenticate every caller, not just the key
An API key alone is not enough. Serving engines may leave endpoints or inter-node traffic unauthenticated by default, so the key should be one layer behind a proxy that also verifies the calling service. Confirm which identity App Suite presents to the model endpoint, that the key is held in a secrets store, and that it can be rotated without a full redeployment.
Isolate inter-node model traffic
In a multi-node vLLM deployment, communication between nodes is insecure by default, with no authorization or encryption. The vendor's security guidance says to protect it by placing nodes on an isolated network. Check that node-to-node ports accept traffic only from other model nodes, that App Suite pods and external networks cannot reach them, and that network policy enforces this in a test you can repeat.
Control who can enable AI features
Turning on AI compose, summarization or multi-step tasks sends mail content to a model endpoint, so the switch is a data flow decision. Decide which administrators may enable features for which tenants or user groups, and keep ordinary users from enabling them. Check that each change is logged and reviewed, and confirm the setting names in the App Suite release you plan to deploy.
Decide what prompt and output logs capture
Logs help with debugging and audit, but they also copy mail content into another store. Decide which fields are recorded, such as request ID, user, model name and timestamp, and whether message bodies are included. Check the App Suite and model server logs for full prompts and outputs during a test run, and confirm what the serving engine writes by default in the version you plan to run.
Set retention for prompts and outputs
Retention decides how long copies of mail content survive. Set a period for prompts, outputs and logs separately, and make deletion cover backups and any log shipping targets. Check that the periods appear in the security plan, that a deletion job runs and produces evidence, and that the periods match the data classification your compliance team applies to mail. Derive them from your data policy and confirm them against the defaults of the chosen components.
How support windows and release changes affect your AI setup
Your AI setup changes on two release clocks: the OX App Suite release you run and the model serving engine behind it. Under the Open-Xchange support commitment, a standard App Suite release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. The current LTS named in the supplied support commitment is v8.47, with first customer shipment (FCS) on 2026-03-18. Choose your release channel with these windows in mind, because a standard release can leave support before a planned upgrade is complete, and the AI features you tested may stop being supported on that release at the same time.
AI features in App Suite can change between releases. The changes may affect the prompts and request format sent to the model, the actions offered to users in compose, summarization and multi-step tasks, the settings that control them, and the Helm values that configure the integration. Do not assume that behavior validated in one release will carry over unchanged to the next. Before you schedule an upgrade, ask Open-Xchange which AI capabilities and configuration keys differ between your current release and your target release, and which of those changes need action from your team. Ask the same question for any release you might skip, because support windows make skipping releases a common choice.
The model endpoint has its own cadence. The vLLM project ships new minor releases about every two weeks, for example v0.28.0 on August 26, v0.29.0 on September 9, v0.30.0 on September 22 and v0.31.0 on October 5, 2026. Each release can change defaults, supported model architectures, response details of the OpenAI-compatible endpoints such as /v1/chat/completions, and the Prometheus metrics you may already scrape from /metrics. Ollama also ships frequent releases. Pin the engine version you have tested, record it alongside the App Suite release in your change log, and assign one person to watch the release feed of each component and to decide when a change needs a test cycle.
Plan both sides together. Keep a staging environment that matches production in App Suite release, Helm chart version and model endpoint version. Maintain a fixed test set for compose, summarization and multi-step tasks, and record the expected outputs in a form your reviewers can compare (illustrative: the same source email summarized before and after an upgrade). For each change, decide the order: test the model endpoint first, then App Suite, or the reverse if the App Suite release requires a newer endpoint. Keep the previous model image and the previous chart version available so you can roll back. Confirm with Open-Xchange and your engine vendor which combinations they support before you commit to a schedule.
Limits and what to confirm in your environment
The public documentation does not settle every question about AI features in OX App Suite. The cards below list the open items that affect scope, cost, data handling and sizing, and say who can answer each one before a fixed-scope plan is agreed.
Which AI features ship in your release
Compose, summarization and multi-step tasks may not all be available in every v8 release line, and availability can differ between the LTS release and standard releases. Ask Open-Xchange which of these features are included in the exact release you plan to run, whether each is on by default or needs configuration, and which features depend on others. Then compare that list with the release your team intends to deploy on Kubernetes.
Which model backends Open-Xchange supports
Ask Open-Xchange whether the AI features call specific providers, a generic OpenAI-compatible endpoint, or both. Self-hosted servers such as vLLM expose OpenAI-compatible routes, and Ollama exposes a local API with no authentication by default, but neither is confirmed here as a supported backend for OX App Suite. Get written confirmation of each backend, the versions tested, and how access is restricted between the mail platform and the model service.
Separate fees under the license agreement
Open-Xchange's Operations Guide notes that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask whether AI features are covered by your license or billed separately, and whether any charge is one-time or recurring. Also ask your own team to budget the model backend separately, since a self-hosted backend has infrastructure and operations costs even when its software carries no license fee.
Languages and data residency
Confirm which languages the AI features handle well and which are out of scope for your user base. For data residency, map every step where mail content, prompts or generated output are sent or stored, including any cloud model call, logging service or telemetry channel. Ask Open-Xchange to document whether the full flow can run inside your network, and have your compliance lead verify the data path against your residency obligations.
GPU and accelerator sizing
Accelerator needs depend on the model, the backend, the number of concurrent users and the length of prompts and outputs, and none of these are settled by the product documentation. vLLM supports NVIDIA CUDA, AMD ROCm, Intel XPU and CPU targets, while Ollama defaults to one parallel request per model. Ask Open-Xchange which model and backend they tested, then run a load test in your own environment before choosing hardware.
AI output in mailbox audit trails
Determine whether AI-generated drafts, summaries and multi-step actions are recorded in mailbox audit trails, and whether the record shows that an AI feature produced the content and which user triggered it. Ask Open-Xchange what is logged, where the log is stored, how long it is kept and whether it can be exported. Then have your security or compliance team check the answers against your audit logging requirements and retention rules.
Questions buyers ask before hiring help with OX App Suite AI
What drives the cost of an OX App Suite AI integration?
The cost is driven by four components: licensing under your agreement with Open-Xchange, model hosting capacity, network and security work, and the people who operate the endpoint. Licensing depends on what your agreement covers. Open-Xchange's Operations Guide states that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so confirm early whether the AI functions are included in your entitlement. Model hosting is usually the largest variable if you run a model yourself. vLLM has no paid edition, so its cost comes from accelerator capacity, surrounding infrastructure and operations. Ollama's self-hosted use on your own hardware is listed as unlimited, but hardware and staffing still apply. Network and security work covers isolation of inference nodes, access control and logging. In a quote, ask for each component as a separate line, marked as one-time or recurring, with the party responsible for each line.
Can our own team build the OX App Suite AI integration in-house?
Yes, if your team already runs Kubernetes, Helm and the App Suite stack and has capacity to own a model service. The core platform is delivered as Helm charts that reference container images, and v8 requires Helm 3.17.0 or newer. It also needs Istio or the basic ingress-nginx option, Redis 7.4.x and MariaDB. The AI part adds a model backend that needs its own GPU or CPU capacity, an API layer, secrets handling and a reverse proxy that exposes only the endpoints users need. vLLM's security documentation notes that its API key does not cover every endpoint and recommends allowlisting through a reverse proxy. It also states that node-to-node traffic in multi-node runs is insecure by default. Teams without experience in those areas often bring in a partner for design and hardening, then operate the result themselves. List the skills you lack and scope that gap in writing.
How long does an OX App Suite AI integration take to deliver?
Duration depends on the scope agreed in writing, and no single timeline fits every environment. The main drivers are the model backend you choose, the security review your organization requires and the size of the pilot. A hosted model API that your policy allows involves less work than a self-hosted vLLM cluster, which needs accelerator procurement, multi-node networking and isolation. A security review covering architecture, data flows and access approvals adds review cycles that depend on your governance calendar. A pilot with a small group of mailboxes is quicker to validate than a rollout across the whole tenant. Platform prerequisites also come first. If the Kubernetes cluster, Istio and shared storage are not ready, that work sets the start date. Ask for a schedule with milestones for design, build, pilot and handover, and mark which dependencies sit with your own teams.
What does the integration need from our team before work starts?
Plan to provide architecture owners, network and identity access, and a test mailbox set, and name the person who holds each role before kickoff. Architecture owners decide the target design, including the mail backend, the identity provider and where model inference runs. Network access covers routes between the App Suite cluster, the model service and your identity provider, along with firewall changes approved by your network team. Identity matters because App Suite supports single sign-on through OpenID Connect, and SAML login is documented for the middleware, so your identity team must supply client registrations and group mappings. A test mailbox set with representative content lets the team check compose, summarization and multi-step tasks before any user sees them. Confirm these inputs in the written scope, so delays appear early and cost the least.
Can OX App Suite AI features run in an air-gapped environment?
It can be planned for an air-gapped environment, but the answer depends on the model backend, the packages you can move in and how updates reach the disconnected network. DeployOpen covers the air-gapped installation of OX App Suite v8 in a separate topic that describes the registry mirror, local Helm charts and the update path. For the AI layer, a self-hosted model runtime is the usual route, because a cloud-hosted model API sends prompts outside your network. Ollama states that when it runs locally it does not see your prompts or data, and cloud features can be turned off with OLLAMA_NO_CLOUD=1. vLLM can be deployed inside an isolated network, though multi-node traffic must be protected by that isolation. Model weights also have to be transferred in, so treat that transfer as a controlled process. Confirm with your security team which model files are permitted and how they are checked before import.
How are OX App Suite upgrades handled when AI components are added?
Upgrades follow Open-Xchange's support commitment for the App Suite release, and the AI components need their own version plan. A standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months, and v8.47 is the current LTS. Choose a release track that matches how often your organization can test. For the AI layer, track the model runtime separately. vLLM ships new minor releases about every two weeks, so pin versions and test each one against your prompts and endpoints before promotion. Ollama also releases frequently. Ask for a written upgrade method that covers staging, rollback, model version changes and who approves each step. Also ask whether ongoing maintenance is a retainer or a separate fixed scope.
Should we choose vLLM or Ollama as the model backend?
Choose vLLM when you need a shared, multi-user inference server on accelerators, and Ollama when you need a simpler runtime for smaller deployments or workstations. vLLM is Apache-2.0 licensed, has no paid edition and exposes OpenAI-compatible endpoints such as chat completions and embeddings, so existing clients can point at it. It runs on NVIDIA, AMD and Intel GPUs and supports multi-node runs, and it exposes Prometheus metrics at /metrics. Ollama is MIT licensed and exposes a REST API on port 11434. It binds to 127.0.0.1 by default, and its local API requires no authentication, so exposing it to users needs a proxy with access control. Concurrency is also limited by defaults, such as one parallel request per model unless you change OLLAMA_NUM_PARALLEL. Run a short load test with your own prompts on both before you decide.
How DeployOpen works on this
DeployOpen scopes OX App Suite AI integration as a written, fixed-scope engagement covering the assistant features, the model backend and the network path between them. Work runs in infrastructure you control, so the chosen model server, its API keys and its logs stay under your governance. Ongoing support and upgrades are available as a retainer.
How we scope
- The written scope lists which AI features are in play, such as compose, summarization and multi-step tasks.
- We confirm with Open-Xchange which AI capabilities your target App Suite release actually ships before estimating build work.
- Model backend choice is recorded: a hosted API you approve, self-run vLLM, or local Ollama, each with its data path documented.
How we build
- Deploy the model server in your cluster, with accelerator capacity sized to the chosen model.
- Front the endpoint with a reverse proxy that allowlists only user-facing routes, because the API key alone is insufficient.
- If you run multi-node, isolate traffic on a private network, since inter-node communication is unauthenticated and unencrypted by default.
How we hand over
- Written runbook covering model server configuration, endpoint allowlists, secrets handling and the App Suite connection settings.
- Test evidence for each AI feature, including response behavior, timeouts and what happens when the model backend is unavailable.
- Metrics and logging wired into your monitoring, including the vLLM /metrics endpoint where vLLM is used.
How we support
- Support and upgrade work can be covered by a retainer, scoped in writing alongside the initial build.
- Model server and App Suite upgrades are re-tested against the feature list before they reach production.
- Confirm the release channel with Open-Xchange, because support windows for standard and LTS releases differ.
