A local language model is quick to try out. A shared AI assistant also needs controlled access, clear data flows and someone responsible for operation. Ollama and Open WebUI can work together: one component runs the models, while the other provides the interface for everyday work.
For a business, planning starts with a specific task: drafting text from approved notes, organising internal notes or helping with technical questions. Decide which inputs are permitted, how outputs will be checked and what response times suit daily work before choosing hardware.
Two components with different responsibilities
Ollama provides the runtime and an API for language models. Open WebUI adds a manageable web interface. A locally installed interface does not establish where every connected model processes requests. Cloud models, web search and additional tools can use other data flows.
In this operating concept, employees reach the interface through approved access. Open WebUI connects internally to Ollama. The model API is restricted to the services that actually need it. Connections between separate containers or servers require explicit planning: localhost refers to each component’s own network environment.
From a single workstation to a shared service
The main difference is what happens after the first successful chat. This comparison describes a possible development stage for a small business; it is a planning aid rather than a documented customer project.
| Area | Individual test | Shared use |
|---|---|---|
| Access | One person tests on their own computer. | Individual accounts, defined roles and a controlled process for withdrawing access. |
| Data | Non-sensitive sample data. | Approved data types, retention and demonstrable permissions for source material. |
| Availability | The computer is switched on during the test. | Agreed operating hours and a documented recovery procedure. |
| Capacity | One request produces a useful answer. | Concurrent tasks, waiting times and longer inputs are measured. |
| Changes | Models and software are tried out. | Tested versions, a backup before changes and a dependable rollback path. |
Protect interface access and the model API separately
According to the vendor, Ollama’s local API does not require its own authentication. Network exposure therefore does not replace access control. For a business service, the model API should be reachable only through the necessary internal connections. A port accessible to all workstations or the internet is not a suitable starting point. Ollama: authentication (external link).
Configure sign-in, user approval and administrative permissions deliberately. An existing identity service may be a useful integration; the right connection depends on the environment. A proxy must pass an authenticated identity only through trusted information that it sets itself. Open WebUI: access and permissions (external link).
HTTPS protects the connection between the browser and the access point. When multiple systems are involved, encrypt and restrict the onward connection to the backend according to protection needs. Test certificates, redirects and connections required by the interface together. Open WebUI: HTTPS and reverse proxies (external link).
Verify “local” through the actual data flow
Ollama provides a mode without its cloud features for exclusively local model requests. This does not replace checking other connections in Open WebUI or added tools. Model downloads and software updates also need a planned retrieval path. Ollama: local use and cloud features (external link).
- Model: Which exact version processes the request, and where does it run?
- Documents: Where are uploads, extracted text, search indexes and backups stored?
- Additional services: Are other providers used for search, text recognition, speech or embeddings?
- Tools: Which connection may read data or trigger actions, and under whose permissions?
Cloud and hybrid services can be suitable additions. Specify providers, data types and approvals explicitly. Switching to an external service should not happen unnoticed simply because the local model is busy.
Company knowledge needs specific permissions
Sign-in initially establishes who is using the interface. It does not automatically grant access to every uploaded document. In this example, an approved guide could be available to all pilot users while personnel records remain entirely outside the pilot.
When adding further sources later, check permissions for each collection, document and user. Search results, quotations, shared chats and saved answers can also disclose information. Changes to groups or source permissions must take effect in the knowledge system. Read more on the specialist pages Company knowledge & RAG and AI security and permissions.
Backup and updates are part of the concept
Back up the data actually used: database, uploads and configuration, plus the keys needed for recovery. Document the model name and exact version, including adapted models and your own extensions. Store the backup separately from the running system with controlled access.
Before an update, arrange a restorable backup, review release notes and test outside the production service. After a database migration, an old container image alone will not necessarily restore the previous state. Open WebUI: updates, backup and rollback (external link).
A useful recovery test starts in a separate environment. Check sign-in, the model connection, a non-sensitive test task and the expected permissions there. Only then can you estimate how long an actual outage would last. A running VM or an existing backup directory alone does not establish this.
A running interface does not establish a working model
Monitoring should distinguish between an accessible interface, the selected model being available and a complete request working. Open WebUI’s documentation also separates these levels. Open WebUI: functional monitoring (external link).
For the agreed operation, also monitor storage usage, available capacity, error rates and waiting times. Test requests contain no confidential information. Logs should support troubleshooting without routinely duplicating every conversation. Decide who responds to incidents and who approves updates before broader use.
A manageable acceptance check before launch
- Check access: An approved user gets in; an unapproved user and an unauthorised network segment remain excluded.
- Check data flows: The model, interface and all additional services use only the agreed connections.
- Check permissions: Two test roles receive only their authorised content. Revoked access also takes effect after a previously successful search.
- Check load: Typical tasks run individually and concurrently; record acceptable waiting times and limits.
- Check recovery: Restore a backup separately; document responsibilities and the rollback path.
Required hardware depends on the model, context length, concurrent use and quality target. The architecture therefore cannot establish a universal number of users served simultaneously. The existing article Testing local AI: a pilot with meaningful load explores this capacity assessment in more detail.
Start with a clearly defined task
DAXS can assess existing infrastructure, plan data flows and access, and integrate the solution into the agreed operation. A well-defined use case with verifiable value is a good first step. It establishes whether a local service, cloud integration or a combination is economically and organisationally suitable.
Local LLMs & infrastructure · MCP & interfaces · Request AI consulting & automation
Sources: this example describes one possible architecture and assessment process, rather than universal installation instructions. Product features, model licences and actual system compatibility are checked for the versions used.
