Why a private LLM chat rollout for thousands of employees is a different project
A pilot that ran on one server for a small group will not carry thousands of staff, and the rollout is decided by four things: concurrency, shared state, identity groups and measurement. The pilot tells you the assistant works. It does not tell you how many people can send prompts at the same moment, which component holds sessions when a second Open WebUI replica starts, or how access will follow the directory as it changes. For most organizations the working split is Open WebUI as the chat interface, vLLM for shared, concurrent serving of the main model, and Ollama for smaller or departmental use where a few people or one team need a model on modest hardware. Which engine carries the workforce depends on the sizing, not on preference, so treat the choice as the output of the concurrency work described below.
Licensing also changes at this stage. The Open WebUI License forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. A pilot under that threshold can ignore the clause, but a workforce rollout cannot. Confirm the license position with the vendor and your legal team before the first wave, and budget for the enterprise option if you want custom branding or vendor support. Ask your implementation partner to show, in writing, how the sizing, the state stores and the license terms will be checked before each wave opens to more users.
Requirements that shape a rollout past the pilot
This table compares the platform requirements that change once a staff assistant moves from a pilot to thousands of users, with the source for each and what it means for the build. Read it as a list of decisions to make before the first wave, not as a feature checklist. The main takeaway is that database, shared state, identity and endpoint protection must be designed for multiple replicas and gated access from the start.
| Requirement | Source | What it means for the build |
|---|---|---|
| Multi-replica Open WebUI needs PostgreSQL | Open WebUI scaling guide | SQLite handles concurrent writes poorly across processes, so move the database to PostgreSQL before adding a second replica. |
| Redis for sessions and websockets | Open WebUI scaling guide | Redis holds sessions, websocket connections and application state shared by all replicas. Plan it as a stateful dependency with its own high availability. |
| Shared file storage for uploads and knowledge | Open WebUI scaling guide | Uploads and knowledge bases must be reachable from every replica. Confirm the storage type and access mode with the vendor before the pilot ends. |
| SSO through OIDC or LDAP with SCIM 2.0 groups | Open WebUI features docs | Group-based waves depend on SCIM 2.0 provisioning. Confirm which group attributes sync and how removed users lose access. |
| Branding clause above 50 users | Open WebUI License docs | Above 50 users in any rolling 30-day period, branding may not be altered or removed without an enterprise license or written permission. Confirm terms before wave one. |
| vLLM endpoint protection | vLLM security docs | The --api-key option does not cover /metrics, /health or /invocations. Place a reverse proxy in front that allowlists only the endpoints users need. |
| Log retention where in scope | EU AI Act Articles 12(1) and 19(1) | If the assistant is high-risk, logs must be recorded automatically and kept at least six months. Confirm applicability with counsel before setting retention. |
Ollama or vLLM for thousands of users: how concurrency differs
Ollama is a straightforward runtime for running models on a single host, and its concurrency controls are set by environment variables rather than by a serving architecture. The defaults matter most for a rollout. OLLAMA_NUM_PARALLEL defaults to 1 parallel request per model, so a model that has not been tuned will handle one generation at a time. OLLAMA_MAX_LOADED_MODELS defaults to 3 times the number of GPUs, or 3 on CPU, which limits how many models stay resident in memory. OLLAMA_MAX_QUEUE defaults to 512 queued requests, and requests beyond that are refused. The local API at port 11434 requires no authentication and binds to 127.0.0.1 by default, so it must be deliberately exposed through a proxy that enforces identity.
- Parallel requests: Raising
OLLAMA_NUM_PARALLELis a configuration change, but it also multiplies memory use for context, so it has to be tested against your prompt lengths. - Loaded models: Several models served at once compete for the same GPU memory, which affects latency for every user.
- Queue depth: A queue of 512 can hide overload, since users wait instead of receiving an error.
- Authentication: The local API has no login, so the gateway or reverse proxy in front of it carries all access control.
- Exposure: Changing
OLLAMA_HOSTto a network address makes the endpoint reachable from other hosts.
Confirm with your platform team the parallel limit, loaded model count and queue depth they have set, and how each is measured under peak load.
vLLM is an inference and serving engine designed to run a model as a shared service. Its server, started with vllm serve, exposes OpenAI-compatible endpoints including /v1/chat/completions, /v1/responses and /v1/embeddings, so existing applications and an assistant front end can point at it with little change. It exposes Prometheus-format metrics at /metrics, covering request counts, token throughput, latency histograms and KV cache use, so capacity can be watched during the rollout. For models too large for one GPU, it supports tensor parallelism within a node and pipeline parallelism across nodes, and it uses Ray or its own multiprocessing backend for multi-node runs.
- Compatible endpoints: Chat, completions, responses and embeddings share one serving process and one model configuration.
- Metrics: KV cache use is the signal most teams watch, because it shows when new requests begin to wait.
- Parallelism: Tensor parallelism splits a model across GPUs in one server, while pipeline parallelism spans nodes.
- Multi-node security: Communication between nodes is insecure by default, without authorization or encryption, so nodes must sit on an isolated network.
- Endpoint exposure: The
--api-keyoption does not cover/metrics,/healthor/invocations, so a reverse proxy should allowlist only the user-facing endpoints.
Confirm the GPU count, interconnect and node layout with your hardware team, and whether the metrics endpoint is scraped only from the monitoring network.
Neither engine produces a usable sizing answer from its name alone. Capacity for a staff assistant depends on three measured inputs: the number of users who are active at the same moment, the token length of typical prompts and responses including uploaded files, and the GPU memory left after the model weights are loaded. Those inputs interact, so a configuration that works for short questions may fail when staff paste long documents. Pilot logs and a load test using realistic prompts give the numbers that a serving configuration should be built from.
- Concurrency: Count simultaneous generations at peak, not the total number of licensed users.
- Token length: Record input and output lengths separately, since long context changes memory use sharply.
- Memory headroom: Measure how much GPU memory remains after the model loads, and keep room for the cache.
- Load tests: Run tests against the same gateway and interface staff will use, so the results include authentication and queuing.
- Acceptance thresholds: Agree on latency and error targets in writing before the first wave expands.
Ask your team to show the measurements behind their chosen parallel limit or tensor layout, and which peak scenario they tested.
The choice between the two engines usually follows the shape of the rollout rather than a single feature list. Ollama fits a small number of models on a few hosts, a team that values simple local operation, and an environment where the built-in controls are enough once a proxy is added. vLLM fits a shared service with many concurrent sessions, multiple GPUs per model, and an operations team that will scrape metrics and manage a Kubernetes or multi-node layout. Some organizations use both, for example a local model for a small group and a shared vLLM endpoint for the wider staff population. Any mixed design needs one gateway and one identity model so users see a consistent service.
- Scale profile: A single host with a handful of models suits Ollama, while many simultaneous sessions push toward vLLM.
- Observability: Built-in Prometheus metrics in vLLM simplify capacity reviews during each wave.
- Operations skills: Confirm which team will tune, patch and upgrade each engine, since both release often.
- Network design: Multi-node vLLM needs an isolated network, which affects where the cluster can be placed.
- Exit path: Both expose OpenAI-compatible APIs, which keeps the front end and gateway replaceable.
Ask the implementation partner to document which engine serves which users, and how traffic is routed between them.
Phasing the rollout in SSO group waves
This sequence takes a staff assistant from a load-tested pilot to full population in waves, with each wave gated by measured capacity, identity mapping and acceptable-use results. The output is a rollout plan where every expansion has a recorded go or no-go decision.
Establish the capacity baseline on the serving engine
Engineers set the expected concurrency, prompt and response lengths and target models, then run a load test against the chosen serving engine. For Ollama, the test must cover the OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE settings, which default to 1, three times the GPU count (or 3 on CPU) and 512 queued requests. For vLLM, it must cover the throughput and latency under KV cache pressure. The step closes when the team has a written number of concurrent users each GPU pool can serve within the latency target, with the test profile recorded. Confirm GPU sizing with the hardware vendor and the serving engine's current documentation before you commit to a purchase.
Build the shared state layer and replicas
The platform team moves Open WebUI off SQLite to PostgreSQL, adds Redis for sessions, websocket connections and application state, and places uploads and knowledge on shared file storage reachable from every replica. External vector storage is provisioned if retrieval is in scope. The step closes when two or more replicas serve the same chat, file and knowledge data after a restart of any single replica, and failover is tested under the load profile from the previous step. Confirm the supported vector database list in the Open WebUI documentation before selecting one.
Integrate SSO, SCIM groups and RBAC mapping
Identity engineers connect OIDC or LDAP, enable SCIM 2.0 provisioning of users and groups, and map each directory group to an Open WebUI role and permission set. Model access, knowledge collections and tool permissions are scoped by group, not by individual. The step closes when a test account in each group sees only the models and resources it should, and when deprovisioning a test user in the directory removes access in the application. Document the mapping as a controlled configuration with an owner.
Run a staging group for model and release updates
Before any production wave, a small staging group of named users receives new Open WebUI releases and model versions first. Serving engine and interface releases ship frequently, so the update cadence should be set with the security team and tested against the same load profile. The step closes when the staging group has used each release for an agreed period, the regression checks pass, and the team has a rollback path to the previous image and model digest.
Decide branding and license terms before crossing 50 users
Legal and procurement confirm the Open WebUI License position before any deployment could exceed 50 end users in a rolling 30-day period. Above that threshold, branding may not be altered or removed unless the organization holds an enterprise license or written contributor permission. The decision is made with the vendor, based on the expected seat count, and recorded. The step closes with a signed decision and, where an enterprise license is chosen, a quote that follows from the written scope.
Launch the pilot wave and measure every gate
A pilot group drawn from one directory group runs real work under agreed acceptable-use rules. Before each wave, the team reviews queue depth, latency, KV cache use (for vLLM), error rate, token throughput, support tickets and acceptable-use incidents, using the metrics exposed by the serving engine and the chat platform. Each gate needs a stated threshold set in advance by the sponsor and the operations owner. The step closes with a go or no-go record for the next wave.
Expand in SSO group waves with go or no-go gates
Each following wave adds one or more directory groups, with a defined size and the same gate review as the pilot. A no-go holds the wave and triggers a capacity or configuration fix before retesting. Waves should be scheduled around peak business periods that the team has identified in advance. The step closes when every wave has passed its gate and the total concurrency has been checked against the load test baseline, with the final population and any excluded groups documented.
Which open-source platforms fit a thousands-of-users rollout
A staff assistant at thousands of users needs three decisions made separately: the chat interface, the model serving layer and, optionally, a gateway that controls access and spend. The options below differ mainly in how they handle concurrent users, identity integration and licensing, so each card names what to check in a proof of concept before committing to a rollout wave.
Open WebUI as the chat interface
Open WebUI brings SSO through OIDC and LDAP, SCIM 2.0 provisioning, role-based access with groups, and retrieval over 13 vector database options, which covers most of what a staff rollout needs from the front end. It installs through Docker, Helm or pip. Multiple replicas require PostgreSQL, Redis and shared file storage, so the front end is not a single-server choice at this scale. Because the code is under the Open WebUI License, branding changes above 50 users in any rolling 30-day period need an enterprise license or written permission. Confirm those terms with the vendor before the first wave.
LibreChat as an alternative interface
LibreChat is an MIT-licensed chat interface that avoids the branding clause in Open WebUI's license, which can matter for organizations that want to rebrand the assistant for all staff. Its latest tagged version is v0.8.8. It is a credible alternative to evaluate, but multi-replica operation, SSO group mapping and how sessions are shared across replicas are not settled facts in this context. Ask the team to demonstrate group-based SSO and a two-replica deployment with a load balancer during the proof of concept.
vLLM for shared concurrent serving
vLLM is the serving layer to evaluate when many staff share the same model at once. It exposes OpenAI-compatible endpoints, reports Prometheus metrics at /metrics and supports tensor and pipeline parallelism across GPUs. vLLM has no paid edition, so the recurring cost sits in accelerator capacity, the surrounding infrastructure and the people who run it. Its API key does not cover every operational endpoint, so a reverse proxy that allowlists only user-facing paths is required. Confirm throughput for your model and peak concurrency on your own GPUs before sizing a wave.
Ollama for small or local use
Ollama is an MIT-licensed runtime that is quick to stand up on a workstation or a single server. Its defaults limit shared use: OLLAMA_NUM_PARALLEL allows one parallel request per model by default, and OLLAMA_MAX_QUEUE holds up to 512 queued requests. Its local API has no authentication, so it must sit behind a proxy that enforces identity. Set OLLAMA_NO_CLOUD=1 to disable cloud features in regulated environments. Ollama fits pilots, departmental tools and developer testing more often than a company-wide service, so measure queue times before using it for thousands of users.
LiteLLM as an optional gateway
LiteLLM sits between the chat interface and model endpoints to handle routing, virtual keys, budgets, load balancing and request logging. It is MIT licensed except for its enterprise directory, so confirm which features your deployment needs fall outside that directory. A gateway is useful when several backends, departments or budgets must be controlled from one place, and it adds an operational component that needs its own high availability plan. Ask the team whether budget and key controls are required on day one or can follow the first wave.
Evidence the rollout should produce for auditors and regulators
This table lists the records each rollout wave should generate, which component produces them and who inside the organization or its assessors uses them. DeployOpen prepares this evidence during the rollout, but independent auditors and certification bodies assess it and decide what it proves. Use the table to agree the evidence set before the first wave, not after the last one.
| Evidence | Produced by | Who uses it |
|---|---|---|
| Load test results and capacity baseline | Load test runs against the vLLM or Ollama endpoint and the Open WebUI replicas, with Prometheus metrics from /metrics | Platform engineering to justify GPU sizing; risk owners to confirm the approved concurrency limit |
| SSO group-to-role mapping export | Open WebUI group and role configuration fed by the identity provider through OIDC or SCIM 2.0 provisioning | Identity and access reviewers checking that each group maps to the approved role and model access |
| Chat and API log records with retention settings | Open WebUI chat history database in PostgreSQL, gateway or proxy access logs and inference server logs, with retention settings documented per store | Compliance and legal for retention decisions; auditors sampling records; incident responders. Where the system is high-risk, Article 12 and Article 19 logging duties under the EU AI Act apply and need confirmation with counsel |
| vLLM and Open WebUI version records | Deployment manifests and image tags recorded at each wave, aligned with the release cadence of vLLM and Open WebUI | Change managers and vulnerability management teams tracing which version served which users on which date |
| Branding and license decision record | Written decision on whether Open WebUI branding is retained, changed or covered by an enterprise license, tied to the user count per rolling 30-day period | Legal and procurement to confirm license compliance; the CIO to sign off on the user threshold before expansion |
| Change records for each wave | Wave plan, approval, go and no-go results against the measured thresholds, rollback test and post-wave review | Change advisory board, internal audit and assessors reviewing how each expansion was approved |
Questions buyers ask about scaling a private LLM chat
How much effort does a private LLM chat rollout take, and what drives it?
Effort is driven by three things: the concurrency target, the complexity of your identity setup, and the number of GPUs you need to serve that concurrency. A pilot with a few hundred users on one model server is a small job. Moving to thousands of staff adds PostgreSQL, Redis, shared file storage, SSO group waves, load testing and monitoring, and each of those adds scope. No effort figure is given here because it depends on your environment. Ask any partner for a written scope that lists the concurrency target, the identity sources, the GPU count and the models, and tie each deliverable to one of them.
Can Ollama serve thousands of staff from one server?
Ollama can run models on your own hardware, but its default concurrency settings are small, so it is usually not the first choice for thousands of simultaneous users. By default, Ollama allows 1 parallel request per model (OLLAMA_NUM_PARALLEL), keeps up to 3 times the number of GPUs in memory (OLLAMA_MAX_LOADED_MODELS), and queues up to 512 requests (OLLAMA_MAX_QUEUE), according to the Ollama FAQ. Those values can be raised, but the result must be load tested on your hardware. vLLM is built around batching many concurrent requests and exposes Prometheus metrics at /metrics, which makes it easier to size for larger concurrency. Confirm the target concurrency and measured throughput before choosing either runtime.
Why does Open WebUI need PostgreSQL and Redis for multiple replicas?
Open WebUI needs them so that several replicas can behave as one service. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, because SQLite does not handle concurrent writes from multiple processes well. For multiple replicas, Redis is needed as a shared state store for sessions, websocket connections and application state, and shared file storage is needed so uploads and knowledge stay reachable from every replica, according to the Scaling Open WebUI guide. Vector storage is a separate choice: Open WebUI supports 13 vector databases, so you can keep it inside your own PostgreSQL or use a dedicated store. Confirm each of these components with the vendor's current documentation before you size them.
What does the Open WebUI branding license mean above 50 users?
Above 50 users, the Open WebUI License prohibits altering or removing Open WebUI branding, unless you hold an enterprise license or written contributor permission. The limit applies to deployments with more than 50 users in any rolling 30-day period, according to the Open WebUI License documentation. Code through v0.6.5 remains BSD-3-Clause, but code from v0.6.6 onward is under the Open WebUI License. A rollout for thousands of staff therefore needs a licensing decision before launch, not after. Ask your legal team to read the license text, and ask any partner how they will handle branding in the interface.
What should an Open WebUI enterprise license quote include?
An enterprise license quote starts from the expected seat count. Open WebUI does not publish pricing, and its enterprise license, which allows white-labeling and custom branding with dedicated support options, is quoted after you contact its enterprise sales team with the expected number of seats, according to the Open WebUI Enterprise documentation. Prepare a number that reflects named staff, not only pilot users, and state the growth you expect over the first waves. Ask the vendor to confirm in writing which features, support terms and renewal conditions the quote covers, and whether branding rights extend to all deployments you plan to run.
Can our own team run a staff chat rollout without an implementation partner?
Your team can run it internally if it has people who already operate Kubernetes or Docker, PostgreSQL, Redis, GPU servers and an identity provider with SCIM and OIDC experience. The hard parts are capacity planning, network isolation of inference nodes (vLLM notes that multi-node traffic is insecure by default), and the sequence of SSO waves. Before deciding, confirm your GPU availability, the concurrency target, the identity sources, your logging and retention requirements, and who will patch model servers on a frequent release cadence. DeployOpen implements, hardens and supports self-hosted platforms in your own infrastructure under written, mostly fixed scope, so a partner can cover some or all of these steps.
What should we measure before each SSO group rollout wave?
Measure the signals that show whether the current wave is safe to expand. Track request latency and queue depth, token throughput and KV cache use from vLLM's metrics endpoint or Ollama's queue settings, error rates after login, and the health of PostgreSQL and Redis under load. Check that SCIM group sync matches the groups you intend to grant, and that role-based access to models and knowledge is correct for the wave. Set the thresholds in writing before each wave, and hold the next wave if a threshold is missed. The exact thresholds depend on your models, hardware and user behavior, so agree them with your partner during planning.
What to ask an implementation partner before the first wave
Ask the partner to show how they measured concurrency before naming any limit. Ask whether they tested Ollama with OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE at your expected peak, or whether they used vLLM and what request load and token profile they used to set its limits. Ask how they secure the vLLM endpoints beyond --api-key, which the vLLM security docs say does not cover /metrics, /health or other operational routes. A credible answer names a reverse proxy that allowlists only the user-facing endpoints, network isolation for any multi-node traffic, and how that policy is tested. Ask how SCIM 2.0 groups from your identity provider map to Open WebUI roles and per-resource permissions, and who approves that mapping.
Ask how they test the multi-replica state layer before users depend on it. Open WebUI needs PostgreSQL instead of SQLite, Redis for sessions and websocket state, and shared file storage for uploads and knowledge. Ask for the failover test plan: which replica they stop, what they expect a user to see, and how they verify that uploads and knowledge stay reachable from every replica. Ask how they will test upgrades of both the model server and Open WebUI, including the release cadence they expect to follow and whether a staging environment mirrors production.
Ask for the wave gates in writing. Each wave should name the entry measurements (latency, error rate, queue depth, GPU memory and KV cache use from the vLLM metrics or equivalent Ollama monitoring), the support load, and the owner who signs off. Ask for the stopping criteria, meaning the thresholds that pause a rollout and the rollback steps. Request a written scope, a list of deliverables and the acceptance criteria for each wave before any work starts, so the quote reflects a defined outcome rather than an open-ended effort.
What to measure before each wave
Each rollout wave starts only after a fixed set of measurements shows the platform is holding its load, the identity layer is behaving and the acceptable use rules are being followed. The sequence produces a go or no-go record for every wave that the sponsor can review.
Define the metric baseline from the pilot
Before the first wave, the platform team records baseline values for concurrency, queue depth, latency, error rates and KV cache use during the pilot, using the Prometheus-format metrics that vLLM exposes at /metrics and the request logs from the Open WebUI layer. The team agrees thresholds for each metric with the business owner and the security lead in writing. The step closes when the thresholds are signed off and dashboards show the baseline for each model endpoint.
Track concurrency and queue depth per model
The platform team watches how many requests run at once and how many wait for each model, against the limits that apply to the chosen runtime. In Ollama, the parallel request, loaded model and queue settings bound this behavior, while vLLM relies on its own scheduler and KV cache capacity. Queue depth that keeps growing between waves signals that the next wave needs more capacity or a different serving engine. The step closes when peak concurrency and queue depth for the pilot population are documented against the planned wave size.
Review latency and KV cache pressure
The team reviews time to first token, full response latency and the latency histograms from vLLM, alongside KV cache utilization during peak periods. High cache pressure at normal concurrency means the model serving capacity, context length limits or batch settings need work before more users join. Latency is judged at the peak hour, not on average. The step closes when the team confirms that latency and cache use stay inside the thresholds at the projected peak for the next wave.
Check error rates and endpoint exposure
The platform team checks request error counts, timeouts and upstream failures from the metrics endpoints and the reverse proxy logs. Any traffic reaching administrative or monitoring endpoints from user networks is treated as a blocking finding, because the vLLM security guidance says that the API key does not protect every route. The security lead confirms that the allowlist still matches the intended user endpoints. The step closes with an error budget per wave and a written confirmation that the exposure review is clean.
Verify Redis and PostgreSQL health across replicas
When Open WebUI runs on multiple replicas, the team checks that PostgreSQL connections, query latency and failover behavior are within limits, and that Redis holds session and websocket state without evictions or unexpected restarts. The team also confirms that shared file storage serves uploads and knowledge from every replica. A failed replica during a test should not drop users or lose chat history. The step closes when a controlled replica restart and a Redis restart are tested and the results are recorded.
Measure support volume and user feedback
The service desk tags every assistant ticket by category, such as login, group access, slow responses, model quality or file upload, and the team compares volume per user against the pilot. A rising share of access tickets points to gaps in SSO group mapping before the next wave. Feedback from a sample of users is collected at the same time. The step closes when the support trend for the current wave is stable enough to add the next group of users.
Review acceptable use incidents and logs
The compliance and security leads review flagged prompts, blocked uploads, reports of sensitive data pasted into the assistant and any prompt injection attempts found in the audit logs. Each incident is classified and linked to an owner, and the acceptable use policy is updated when the pattern calls for it. Log retention and access to logs are confirmed against the organization's own rules, including any record-keeping duties that apply to the deployment. The step closes with a signed incident review that either clears the wave or sets conditions for it.
Record the go or no-go decision
The sponsor, platform lead and security lead meet to compare the measured values with the agreed thresholds and decide whether the next SSO group proceeds, is paused or is rolled back. The decision record lists each metric, its value, the threshold and the owner of any corrective action. The step closes when the record is filed and the next wave's group membership, capacity changes and monitoring targets are scheduled.
How DeployOpen scopes and supports a staff chat rollout
DeployOpen starts a staff chat rollout with a written scope agreed before any work begins. For a rollout of this size, that scope should name the user population and each wave of access, the models and serving engines in use, the Open WebUI or LibreChat version to deploy, the PostgreSQL, Redis, shared file storage and external vector database to be provisioned, the SSO groups mapped to roles, the monitoring to be built, and the acceptance criteria for each wave. Deliverables and timelines are fixed in that document, so the client knows what is included before the first change is made in its environment.
Delivery happens inside the client's own infrastructure, whether that is its cloud accounts, data centers or an air-gapped network. DeployOpen plans the sizing and phasing, implements the stack, integrates the OIDC or LDAP identity source and SCIM provisioning, then hardens the deployment. Hardening covers placing vLLM or Ollama endpoints behind a reverse proxy that exposes only user-facing routes, keeping the model servers off public networks, and reviewing administrative settings. Backup and restore of the PostgreSQL database and shared storage are tested before the first wave, and the runbooks, configuration records and upgrade procedure are written down so the client's own team can operate the system after handover.
DeployOpen prepares systems, configurations and evidence for compliance assessments, such as logs, access reviews and change records, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. After handover, clients can keep the platform current through an optional retainer covering upgrades, patching and continuous security testing. Because Open WebUI and vLLM release frequently, the client should confirm in the scope how often upgrades are reviewed and who approves them before each wave.
