Book a demo
Book a demo
Login

Operations Open WebUI + Docker workloads

Operate an AI chat workload

Review model/provider configuration, access, stored data, updates, and recovery assumptions. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A team runs Open WebUI for internal AI chat. It needs to verify model connectivity, user access, data handling and resource limits rather than treating the installed UI as a ready model.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Map model dependencies

Where
Open WebUI admin and model provider
Permissions
Authorized Open Webui application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Model endpoint, credentials, expected latency
Action
Record which provider or local model serves requests, who owns it and where prompts/logs are retained.
Expected result
A clear dependency and data map.
Verify
Check endpoint is reachable from app network.
If it fails
If no model endpoint exists, label the UI installed but unusable for chat.

Sources: Open WebUI administrator and model connections · Open WebUI role and group access controls · Open WebUI conversation data controls

Step 2 of 5

Review users and settings

Where
Open WebUI admin settings
Permissions
Authorized Open Webui application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Admin/limited roles, signup, retention controls
Action
Inspect registration policy, groups and model visibility. Use a limited account for first tests; keep credentials outside prompts.
Expected result
A controlled access baseline.
Verify
Sign in as limited user and inspect available models/tools.
If it fails
If user sees unintended tools or data, correct permissions before rollout.

Sources: Open WebUI administrator and model connections · Open WebUI role and group access controls · Open WebUI conversation data controls

Step 3 of 5

Measure one safe request

Where
Open WebUI chat and model endpoint metrics
Permissions
Authorized Open Webui application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Non-sensitive prompt, expected response
Action
Send a harmless question using the intended model. Record actual latency, error and resource use without assuming a specific performance level.
Expected result
An observed end-to-end response.
Verify
Confirm model ID, output and server resource trend.
If it fails
If request fails, separate UI, provider authentication and model capacity.

Sources: Open WebUI administrator and model connections · Open WebUI role and group access controls · Open WebUI conversation data controls

Step 4 of 5

Review retention and exposure

Where
Open WebUI data/settings and privacy owner
Permissions
Authorized Open Webui application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Chat retention, upload policy, external provider terms
Action
Decide what data users may submit, what the UI stores and whether provider receives it. Test deletion and account behavior if required.
Expected result
A usable data policy.
Verify
Ask a test user to find their conversation and permitted deletion path.
If it fails
If behavior differs from policy, restrict access until resolved.

Sources: Open WebUI administrator and model connections · Open WebUI role and group access controls · Open WebUI conversation data controls

Step 5 of 5

Check backup and updates

Where
xCloud Docker Backup and runbook
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
DB/volume paths, model endpoint owner, backup
Action
Verify a Completed backup of app state, then rehearse a safe restore of test chat/config. Assign update and model-outage responders.
Expected result
A recovery plan for UI state and model dependency.
Verify
Test login and model request after rehearsal.
If it fails
If model endpoint is external, document its separate recovery owner.

Sources: Back up and restore Docker apps · Docker backup operations and storage constraints · Open WebUI administrator and model connections

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized Open Webui administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases