Nextcloud Assistant with local AI models: what the module does and when teams implement it
Teams that already run Nextcloud for files often ask for AI help with documents but do not want their content sent to a public AI service. The Nextcloud Assistant is the Nextcloud interface for launching AI tasks and seeing their results, and Context Chat lets users ask questions about the content of their own documents. Local models are one way to supply the inference behind those tasks, so the choice of where models run is separate from the choice to use the Assistant at all. This is a module on top of a Nextcloud server. The team must already run that server, or plan to, before the Assistant adds anything. The work is shared between three parts: the Nextcloud server itself, which holds the apps, users and permissions; the model host, which runs the language model and answers requests; and the task processing setup, which picks up queued AI jobs from Nextcloud and passes them to the model. Each part has its own owner, its own logs and its own failure modes, so the project plan should name who runs each one. Implementation usually makes sense when a few conditions hold together. Users need document questions or summaries often enough that the feature matters to them. Data classification rules say that prompts and document text must stay inside the organization's infrastructure. The team has, or can budget for, hardware that can run the chosen model at an acceptable speed. And someone is accountable for keeping the Nextcloud server, the app versions and the model runtime current. If one of these is missing, the module may still work, but the risk sits with the team rather than with a documented design. Before committing, confirm several points with the vendor and in your own environment. Check the Assistant and Context Chat app versions against the Nextcloud major version you run, because compatibility is tied to the server release. Confirm which models and runtime versions the current app documentation supports. Ask which AI features are available from your installed apps and which need additional components. Test a representative document set on the target hardware, since answer quality and response time depend heavily on both the model and the machine. Also decide early which users and groups may use AI tasks, and whether any cloud or hosted model endpoint is allowed at all. A local runtime that can reach external services through configuration is not the same as one that is isolated by design. Write these decisions down before the rollout, because they determine the network rules, the access controls and the evidence you will need later if an internal or external reviewer asks where document content went.
What the Nextcloud Assistant does with local AI models
The Assistant is the user-facing layer, Context Chat adds document questions, and a model runtime and task worker do the processing. Each card below covers one part of that chain and what to confirm before rollout.
Assistant app as the user interface
The Assistant app gives users a place inside Nextcloud to launch AI tasks and view the results. Administrators decide which users can reach it and which task types are enabled for them. Confirm in the current app store listing for your Nextcloud version which task types ship with the app and which need additional components.
Context Chat for document questions
Context Chat lets users ask the Assistant questions about the content of their documents. Plan which folders, file types and user groups are in scope, since that determines what content is processed and by which components. Confirm the supported file types, indexing requirements and any extra backend services in the Context Chat listing before you size the server.
Ollama as the local runtime
Ollama runs language models on your own hardware and exposes a REST API on port 11434 with OpenAI compatibility. By default it binds to 127.0.0.1, so Nextcloud can only reach it from the same host until you change the OLLAMA_HOST setting and place a reverse proxy in front of it. Its local API does not require authentication, so network restriction and proxy access control belong in the design.
Alternative model endpoints to confirm
The Assistant can also connect to a Local large language model ExApp or to an OpenAI or LocalAI style endpoint, depending on what the app store lists for your version. Confirm which option is still available, which provider types it supports and what setup each one requires. Pick one model path per environment and record the endpoint, model names and credential handling you chose.
Task worker for parallel processing
For Nextcloud 33, the recommendation for speeding up AI task processing is occ taskprocessing:worker, since it handles parallel execution better than the older background job worker. Run the worker under a process supervisor so it restarts after failures, and set the number of workers against the model host's capacity. Review the upgrade notes for your version before you change an existing background job setup.
What stays on the server and model host
Decide the data path before rollout. Nextcloud keeps files, users, permissions and task records, while the model host receives the prompts and document content that a task sends to it. Ollama states that when it runs locally it does not see your prompts or data, but you should verify the traffic flows in your own environment and set OLLAMA_NO_CLOUD=1 where policy requires it.
Which model runtime and hosting option fits your environment
This table compares four ways to supply the language model behind Nextcloud Assistant and Context Chat, based on where prompts are processed, who runs the model host, how Nextcloud authenticates, and when each option fits. Read it first for data location and operating responsibility, then check the hardware and upgrade workload in the last column. The main takeaway is that the choice of runtime also sets how much GPU capacity and maintenance your team takes on.
| Option | Prompts and who operates the host | Authentication | When it fits and what it sets |
|---|---|---|---|
| Ollama on a dedicated GPU host | Prompts are processed on a server you run. Ollama states that when it runs locally it does not see your prompts or data. Your team operates the host, the models and the updates. | The local Ollama API at port 11434 needs no authentication by default. Ollama binds to 127.0.0.1 unless OLLAMA_HOST changes it, so any network exposure needs a proxy with access control, such as Nginx. | Fits organizations that need prompts kept on infrastructure they control and have GPU capacity and staff to run it. Sets GPU sizing, model storage and concurrency settings such as OLLAMA_NUM_PARALLEL, plus ongoing Ollama and model updates. |
| Local large language model ExApp inside Nextcloud | The model is deployed through a Nextcloud app and runs within the Nextcloud deployment. Confirm in the app listing and documentation where the model runs and which host resources it uses. | Confirm how the app connects to its model and whether any credentials are stored in Nextcloud. Document the answer before rollout. | Fits teams that want fewer separate services to run and already operate Nextcloud. Sets the Nextcloud host's CPU, memory and GPU requirements, so confirm the app's hardware needs before sizing the server. |
| OpenAI-compatible or LocalAI endpoint | Prompts go to whichever server hosts the endpoint. Your own LocalAI or OpenAI-compatible server keeps processing in your infrastructure, while a third-party endpoint sends prompts outside it. Confirm the operator and its data terms. | Depends on the server. Ask the endpoint operator which authentication method it supports and configure Nextcloud to match. Do not leave an unauthenticated endpoint reachable from the network. | Fits teams that already run a model server with an OpenAI-style API, or want one endpoint shared by several tools. Sets the workload of that server, including its own upgrades, scaling and access control, on top of Nextcloud's settings. |
| Cloud inference | Prompts are sent to a hosted service outside your infrastructure, such as ollama.com/api or ollama.com/v1. The provider operates the model host. Review the provider's data handling and contract terms before use. | Requires an API key sent as a Bearer token in each request. Store the key as a secret and rotate it under your key management policy. | Fits workloads where data classification allows external processing and you want no GPU hardware to manage. Cloud features can be turned off with OLLAMA_NO_CLOUD=1, which helps enforce this choice on local hosts. Ask for usage and cost terms in writing, since hosted pricing changes independently of your Nextcloud upgrades. |
How Context Chat and task workers process documents
Every Assistant request follows the same path, and knowing it is the fastest way to find where a slow or failed answer started. A user either launches a task in the Nextcloud Assistant, such as summarizing or rewriting text, or asks a question in Context Chat, which answers from the content of the documents the user can already access. Nextcloud records the request as a task and places it in a queue. A task worker process then picks the task up, sends the prompt to the model endpoint configured in the administration settings, waits for the completion, and writes the result back so the Assistant interface can display it to the user. The user sees a pending state until that loop closes, so each stage is a possible bottleneck.
The worker command changed in Nextcloud 33. The recommendation for speeding up AI task processing moved from occ background-job:worker to occ taskprocessing:worker, which handles parallel execution better. Administrators upgrading to 33 should update any unit files, cron entries or process supervisors that start the old command, and confirm that exactly the intended number of worker processes is running after a restart. Parallelism matters for sizing because each worker can hold a request open against the model host while it waits. More workers mean more requests reach the model at once, and the model host decides how many of them run and how many wait. Plan worker count and model concurrency together, not one after the other.
The model host must be reachable from the Nextcloud application servers or task worker hosts on the port and address you configure, and nothing else needs to reach it. Ollama serves a REST API on port 11434 and binds to 127.0.0.1 by default, so a host that runs Ollama on a separate machine needs OLLAMA_HOST set deliberately and a network path restricted to the Nextcloud hosts. The local API does not require authentication, so access control has to come from the network layer or a reverse proxy in front of it. Confirm the exact bind address, firewall rules and proxy configuration in your own environment before testing, because a model host reachable from the wrong network segment is a data exposure risk.
Ollama concurrency settings decide how many users can wait on answers at once. OLLAMA_NUM_PARALLEL sets how many requests a model handles in parallel, and its default is 1 per model. OLLAMA_MAX_LOADED_MODELS sets how many models stay in memory, with a default of 3 times the number of GPUs, or 3 on CPU. OLLAMA_MAX_QUEUE sets how many requests can wait, with a default of 512 queued requests. Requests beyond the queue limit fail rather than wait. Raising parallelism increases memory use for each loaded model, so the right values depend on the model size, context length and hardware. Treat the defaults as a starting point only.
Sizing must be tested against your own workload. Measure response time with the number of concurrent Assistant users and Context Chat questions you expect at peak, using documents of realistic length from your own file shares, and record queue depth and failures as you raise load. Ask any partner or vendor to state the assumptions behind a capacity estimate, including model, hardware, context size and parallelism, and to show the test method. Also plan for the model host to restart during an upgrade, which will fail in-flight tasks and require users to resubmit them. Confirm with your own team how failed tasks are reported to users before go-live.
What drives Nextcloud Assistant implementation cost and effort
This table lists the factors that move the cost and effort of a Nextcloud Assistant rollout with local models, and how to keep each one manageable. Read each row as a question to settle during scoping, because the answers decide the hardware, configuration and test plan. No price or duration is given here; a quote follows from the written scope once these factors are agreed.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| GPU or CPU capacity and host hardware | New hardware adds procurement, racking and OS setup. Model size and parallel requests set accelerator needs. | Check existing hosts first. Size against the models you plan to run and test on a representative host before buying. |
| Number of models and storage location | Each model uses disk space. Default paths differ by operating system, and OLLAMA_MODELS moves them to another volume. | Agree a short model list early. Set OLLAMA_MODELS to a volume with spare capacity and include it in backups. |
| Concurrent users and queueing | OLLAMA_NUM_PARALLEL defaults to 1 per model. OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE limit loaded models and queued requests. | Agree expected peak use, then tune parallel and queue settings during load testing. |
| Document corpus for Context Chat | Volume, file types and change rate drive indexing time, storage use and worker load. | Limit indexed folders and file types to the agreed scope. Index a sample first to measure the actual load. |
| Network exposure of the model endpoint | Local Ollama listens on 127.0.0.1 port 11434 without authentication. Exposing it through OLLAMA_HOST or Nginx adds TLS, access control and logging work. | Keep the endpoint on a private interface. Place it behind a reverse proxy with authentication and TLS, and turn off cloud features with OLLAMA_NO_CLOUD=1 where unused. |
| Identity and access rules for AI tasks | Deciding which users may run Assistant and Context Chat adds configuration and review work. | Map AI access to existing directory groups through the LDAP, OIDC or SAML backends. Document the group list before rollout. |
| Nextcloud version and upgrade cadence | Each major release is supported for one year, and upgrades move one major version at a time. Nextcloud 33 changed the task worker command. | Choose a target release and rehearse upgrades. Use occ taskprocessing:worker on Nextcloud 33 and later, and confirm app compatibility before each upgrade. |
| Testing with representative documents | Answer quality, latency and indexing results vary with document type, language and length. Testing is often the largest effort. | Build a test set from the agreed document types. Set acceptance criteria and repeat the tests after model or version changes. |
How to roll out the Assistant on local models, step by step
This sequence takes an existing Nextcloud installation from version checks to a supervised pilot of the Assistant and Context Chat on models you host. Each step closes with a named artifact your team keeps, so the rollout can be audited, repeated and handed over.
Confirm Nextcloud and app release compatibility
The platform owner checks the Nextcloud major version in use and the Assistant and Context Chat releases that the Nextcloud app store lists for that version. Nextcloud 33 changed the recommended command for AI task processing to occ taskprocessing:worker, so the worker design depends on your version. Check database, PHP and web server versions against the system requirements for your release. If the server is behind, upgrade one major version at a time, back up before each upgrade, and disable third-party apps until they are confirmed compatible. Output: a compatibility record listing every version checked and the upgrade decision.
Size and provision the model host
The infrastructure team decides where the model runtime and the task workers run, and who owns each host. Model size, the choice between GPU and CPU inference, memory, and disk for stored models set the capacity limit, so test representative models on candidate hardware before committing. Ask your hardware vendor or run your own benchmarks to confirm throughput for your document sizes. Place workers on separate hosts if queue load could slow the Nextcloud server. Output: a sizing sheet with host specifications, the model storage volume, and the network paths between Nextcloud, the workers and the runtime, signed off by the infrastructure owner.
Install and bind the model runtime
The platform engineer installs Ollama on the model host. By default it listens on 127.0.0.1 port 11434, so set OLLAMA_HOST deliberately to the single interface that the workers need and keep it off public networks. The local API does not require authentication, so enforce access with firewall rules and network segmentation. If Nextcloud or the workers reach the runtime across hosts, place a reverse proxy such as Nginx in front and restrict it to those sources. Set OLLAMA_MODELS to the storage volume you sized and set OLLAMA_NO_CLOUD=1 to turn off cloud features. Output: a host configuration file, a firewall rule set, and a successful reachability test from each worker host.
Select models and set concurrency
The AI lead selects the models approved for each enabled task and records the license terms for each one. Pull those models onto the host and confirm that each responds to test prompts. Set concurrency deliberately: OLLAMA_NUM_PARALLEL sets parallel requests per model (default 1), OLLAMA_MAX_LOADED_MODELS limits how many models stay in memory (default 3 times the number of GPUs, or 3 on CPU), and OLLAMA_MAX_QUEUE sets the queued request limit (default 512). Match these values with the worker concurrency so the host keeps enough memory free under load. Output: a model register with names, versions and license review, plus the concurrency settings and the reasoning behind them.
Connect Nextcloud and configure the task worker
The Nextcloud administrator installs the Assistant and Context Chat releases confirmed in the first step and points their model settings at the runtime endpoint. Start the task processing worker using the command documented for your Nextcloud version, and run it as a managed service with automatic restart so it survives reboots. Confirm that the worker is registered and that a test task completes from the Assistant interface. Output: an export of the app and provider configuration, the worker service definition, and a log entry showing a completed test task from start to result.
Test permissions, answers and queue behavior
The security and QA lead prepares a sample document set with known contents and deliberate sharing rules, including folders that specific test users cannot read. Run Context Chat questions as each test user and confirm that answers draw only on files that user can access. Check answers against the known contents to catch errors in retrieval or generation. Then submit a burst of tasks to observe how the queue behaves, including waiting times and what happens near the OLLAMA_MAX_QUEUE limit. Output: a test report with pass or fail results per case, the sample set, and queue observations recorded under load.
Set group access and run a pilot
The Nextcloud administrator creates a pilot group, restricts the Assistant and Context Chat to that group using the app access settings for your version, and confirms that users outside the group cannot launch tasks. Brief pilot users on what content the Assistant processes, where the models run, and how to report wrong or missing answers. Collect feedback through an agreed channel for a defined pilot period set by the project sponsor. Output: the pilot group definition, a screenshot or export of the access configuration, the pilot user brief, and a written go or no-go decision before any wider rollout.
Document operations and monitoring
The operations team writes runbooks for routine tasks: worker restarts, model updates, Nextcloud upgrades, queue alarms, and backups of the Nextcloud database and the runtime configuration. Monitor the runtime host, worker status, queue length and response errors, and alert the owners named in the runbook. Ollama ships releases frequently, so pin a tested version and validate each new release in a staging environment before production. Output: an operations runbook, a monitoring dashboard and alert definitions, and an upgrade checklist that the team keeps current with each Nextcloud and runtime change.
How the Assistant connects to the rest of the Nextcloud platform
Nextcloud Assistant with local models touches several platform components at once. The cards below cover the connections that decide whether answers stay within each user's permissions and whether the deployment can be backed up, monitored and upgraded safely.
File access and permission inheritance
Context Chat should only answer from content the requesting user can already open in Nextcloud. Before relying on this, ask the Nextcloud team to confirm permission inheritance with their own test, and run a test with a restricted account on shared folders, group folders and external shares. Record which content types the test covers and which it does not.
Directory and single sign-on backends
Users usually sign in through LDAP or Active Directory, which the Nextcloud LDAP app supports, or through OpenID Connect or SAML backends. Decide which source is authoritative for group membership, since that membership drives what Context Chat can see. Confirm how deprovisioned users are handled in both Nextcloud and the model host logs.
Reverse proxy and TLS for the model endpoint
Ollama binds to 127.0.0.1 on port 11434 by default and its local API does not require authentication. If Nextcloud reaches the model across a host or network boundary, place it behind a reverse proxy such as Nginx with TLS and access restrictions, and set the bind address deliberately with OLLAMA_HOST. Confirm that only the Nextcloud server can reach the endpoint.
Monitoring the model host and task queue
Watch the model host for memory, GPU and disk pressure, and watch the Nextcloud task queue for jobs that wait too long. Ollama queues are governed by OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE, so alerts should cover queue depth and rejected requests. Confirm which metrics your monitoring stack can collect from both components.
Backup scope for models, indexes and configuration
A complete restore needs more than the Nextcloud database and data directory. Include the Ollama model directory, which is set by OLLAMA_MODELS, the Context Chat index, the app configuration and the reverse proxy and TLS settings. Test a restore into a separate environment, because a missing index forces a full re-indexing run after recovery.
Upgrade path and app compatibility
Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time, with a backup first. Third-party apps, including the Assistant and Context Chat, must be confirmed compatible with the target release before upgrading, and disabled until they are. Check the Nextcloud 33 upgrade notes for the taskprocessing:worker change before planning.
Keeping Assistant prompts on your own hardware
Running the Assistant against a local Ollama server keeps prompts and document content on infrastructure your team operates. The Ollama FAQ states that when it runs locally it does not see your prompts or data. Read that as a vendor statement about the software, and test it in your own environment. Two settings control cloud behavior. Setting OLLAMA_NO_CLOUD=1 in the environment, or the equivalent entry in the server configuration file, turns cloud features off. Confirm on a test host that the setting survives a service restart and that the Nextcloud server and task workers reach only the local endpoint you configured.
Ollama's pricing page describes running models on your own hardware as unlimited, so local inference carries no usage fee from Ollama. Your recurring costs are the hardware, power, operations staff time and any support contract you choose. Cloud plans also exist. The pricing page lists Pro at $20 per month ($200 per year), Max at $100 per month, Team at $500 per month and Enterprise at custom pricing. According to the same page, model access controls and cost budgets per user or API key sit in the Enterprise plan. If you need per-user limits on model use, ask Ollama whether the Enterprise plan covers your case, or plan to enforce limits at a gateway you control.
Local does not mean protected. The Ollama FAQ says the server binds to 127.0.0.1 on port 11434 by default, and the OLLAMA_HOST variable changes that address. The local API does not require authentication. If you bind it to a network interface so the Nextcloud server or task workers can reach it, anyone who can reach that port can run models. Keep the bind address as narrow as your architecture allows, restrict port 11434 with firewall rules to the Nextcloud application and worker hosts, and place any exposed endpoint behind a reverse proxy such as Nginx with proxy authentication, as the Ollama documentation describes.
Three more controls sit on the Nextcloud side and in your operating processes. First, log AI tasks on the Nextcloud server and on the proxy, recording who launched which task and when. Check that these logs do not store prompt text beyond what your data handling policy allows. Second, set a retention rule for content indexed by Context Chat, because document text feeds that index. Confirm in the Context Chat documentation where indexed content is stored and how it is removed when a source file is deleted or its sharing changes. Third, limit who can reach the model host to named administrators, the service account Nextcloud uses and the operations group, and review that list on a schedule you set.
Verify all of this with your own architecture review before you rely on it. Map where prompts, retrieved document passages, model files and logs travel and where they rest, including the model storage path, which the Ollama FAQ documents for each operating system and which the OLLAMA_MODELS variable can move. Then test the design. Capture traffic from the Ollama host during an Assistant task and confirm that no outbound connection goes to cloud endpoints. Do not treat the FAQ statement, the pricing page or a configuration flag as a compliance result. Independent auditors and your own assessors decide whether your evidence meets a given requirement, so bring them the test records and the logs your design produces.
How DeployOpen scopes and delivers a local AI module for Nextcloud
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Nextcloud Assistant with local AI models, that means scoping the Assistant and Context Chat against models you host, sizing the hardware and task workers they need, and delivering the setup in your environment.
How we scope
- The written scope names the Assistant, Context Chat, model runtime and the groups allowed to use them.
- Scoping records which model runtime each use case depends on, and which data stays inside your network.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
How we build
- Size the Nextcloud host and the Ollama host separately, then test each against the agreed use cases.
- Bind Ollama to 127.0.0.1 port 11434 or a private interface, since its local API has no authentication.
- Configure parallelism and queue limits for Ollama, and use taskprocessing:worker on Nextcloud 33 and later.
How we hand over
- Documented runbook covering model storage locations, OLLAMA_MODELS, OLLAMA_NO_CLOUD settings and worker startup.
- Verification records covering which Nextcloud users can reach the Assistant and how Context Chat is tested.
- Administrator walkthrough covering backups, one-major-at-a-time upgrades and third-party app compatibility checks.
How we support
- Retainer options for monthly maintenance, Nextcloud and Ollama version updates, and model changes.
- Continuous testing of Assistant and Context Chat behavior after each Nextcloud or Ollama release.
- Quotes follow from the written scope, and ongoing support is scoped separately from the initial build.
