How n8n with Ollama keeps prompts on your network
n8n reaches a local model by calling Ollama's REST API on port 11434, so keeping prompts on your network comes down to three design choices: where Ollama listens, what sits in front of it, and where retrieval data is stored. A team that wants AI workflows in n8n without sending prompts or documents to a hosted model provider should make these decisions before the first workflow is built. n8n is source-available under the Sustainable Use License and is not an OSI open source license, which permits use for your own internal business purposes. Ollama is an MIT-licensed runtime. The exact Ollama and vector store nodes available in your n8n version must be confirmed in your own instance, because no node documentation was supplied for this page.
Where Ollama listens. Ollama binds to 127.0.0.1 on port 11434 by default, which means only processes on the same host can reach it. If n8n runs on a separate server or in a separate container, you will need to change the bind address with the OLLAMA_HOST variable, and that change widens exposure. The local Ollama API does not require authentication, so the network path is the main control. Keep n8n and Ollama on the same host or on a private segment, and restrict port 11434 at the host and network firewall. Set OLLAMA_NO_CLOUD=1 so cloud features are disabled and requests cannot be routed to ollama.com. Test the path from the n8n host and from a host outside the segment to confirm that the outside host is refused.
What sits in front of Ollama. If requests must cross a network boundary, put a reverse proxy such as Nginx in front of Ollama and terminate TLS there. The proxy is where you enforce authentication and an allow list of source addresses, because Ollama itself will not check who is calling. Log requests at the proxy so you can see which workflows and hosts reach the model. Confirm with your security team how these logs are retained, since they show metadata about who called the model even when prompt content stays local.
Where retrieval data is stored. A retrieval workflow stores document chunks and embeddings in a vector store such as Qdrant, and those are your data too. By default, self-deployed Qdrant listens on all network interfaces and has no authentication configured, so it must be locked down before n8n connects to it. Enable API keys and TLS, and use JWT-based access control with per-collection permissions where your Qdrant version supports it. Qdrant also needs block-level storage with a POSIX-compatible file system, so it cannot run on NFS or S3-style object storage. Confirm that the Qdrant node in your n8n version supports the authentication method you choose. In queue mode, workers that run these steps need the n8n encryption key and a network path to both Ollama and Qdrant, so test each worker host before go-live.
What you need before connecting n8n to Ollama
Local LLM workflows depend on an n8n instance, an Ollama runtime with a model that fits your hardware, a network route between them, and a vector store if your workflows retrieve documents. Confirm each component before you plan the build, because licensing, memory and network exposure shape most of the design. Version checks belong on the same list.
n8n edition and license terms
Choose between the free self-hosted Community edition and a paid self-hosted plan. The Sustainable Use License permits use or modification for your own internal business purposes or for non-commercial or personal use, so confirm that customer-facing services fit those terms before you build them. Files with .ee in their name or directory need a valid n8n Enterprise License, and SSO, LDAP, Git environments and log streaming are limited to the Business and Enterprise plans.
Ollama install on your platform
Ollama runs on Linux, macOS, Windows and Docker, and the project is MIT licensed. Pick the platform your team can patch, monitor and back up. If you run the Docker image, plan a persistent volume for models so downloads survive container replacement. Confirm which Ollama release you will run, since the project ships frequent releases, and pin that version in your change process.
Model size and memory budget
Choose the model after you size the hardware, because the model must fit in the memory your host can provide. Confirm the memory requirement for each candidate model with its publisher or with a test pull on comparable hardware before you commit. Ollama handles one parallel request per model by default through OLLAMA_NUM_PARALLEL and queues up to 512 requests, so workflows that fan out many simultaneous calls need tuning. Plan model storage space as well, and move it with OLLAMA_MODELS if the default volume is small.
Network path from n8n to Ollama
Ollama binds to 127.0.0.1 on port 11434 by default, and its local API does not require authentication. If n8n runs on another host or in a separate container, change the bind address with OLLAMA_HOST or place a proxy in front of it, and enforce authentication and TLS at that proxy. Check the route from every n8n process that calls a model, including worker and webhook processors in queue mode. Confirm firewall rules in both directions before testing.
Vector store for retrieval
Retrieval workflows need a vector store, and the usual choices are Qdrant or PGVector on PostgreSQL. Qdrant is Apache-2.0 licensed and free to self-host, but its security documentation states that self-deployed instances listen on all interfaces with no authentication by default, so configure API keys and TLS before connecting n8n. It also needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3. For PGVector, confirm the extension is available in your PostgreSQL build and version.
Confirm versions before planning
Release cadence is quick on every component, so confirm versions before you plan. The latest Qdrant release supplied is v1.19.2, published October 5, 2026, and n8n 2.43 was released on October 6, 2026. Check your installed n8n, Ollama and Qdrant versions against each project's release notes and upgrade guidance, and record the version combinations you tested together.
How the n8n AI nodes reach Ollama and the vector store
An n8n workflow reaches a local model through ordinary HTTP. The Ollama node sends a request to the Ollama REST API, which listens on port 11434 by default. Ollama loads the model onto the host's CPU or GPU, generates the response, and returns it to the workflow as the output of the model step. No external model provider sits in this path, so the traffic that matters runs between the n8n host and the Ollama host. Decide early which machine runs each service, because that choice sets every network rule that follows. Confirm against the n8n version you run which credential fields and base URL format the Ollama node expects, since the connection method can change between node releases.
Retrieval adds a second connection. The workflow generates embeddings with a model, writes the vectors to the store, and later sends a query vector to retrieve matching records for the prompt. With Qdrant, the vector store node calls Qdrant's own API, so the connection and its authentication settings belong to Qdrant. With PGVector, the vectors sit in a PostgreSQL table using the pgvector extension, so the node uses a standard database connection with its own role. Confirm for your node version which protocol and credential type each vector store node uses. Also confirm the vector size the collection or table expects, and fix the embedding model before loading data, because vectors from a different model generally cannot be mixed in one index.
Ollama's documentation states that when it runs locally it does not see your prompts or data. That statement describes what the runtime does with data, not how your network is protected. The local API has no authentication by default, and it binds to 127.0.0.1 unless the OLLAMA_HOST variable changes the address. Once n8n runs on a different host and must reach the API, the bind address must change, and anyone who can reach that port can send requests to the model. The network boundary therefore carries most of the control. Restrict port 11434 to the n8n hosts with firewall rules, and place an authenticating reverse proxy in front of it if traffic has to cross network segments. Where policy requires local-only operation, set OLLAMA_NO_CLOUD=1 so cloud features stay off.
The vector store needs the same scrutiny. By default, a self-deployed Qdrant instance listens on all network interfaces and has no authentication configured. Qdrant supports admin and read-only API keys and TLS for its REST and gRPC interfaces, and since v1.9.0 it supports JWT-based access with per-collection read or write permissions. Assign a read-only key to any workflow that only queries, and keep the admin key out of workflow credentials. Verify the result by attempting a connection from a host outside the approved list and confirming it is refused. Record which n8n credential uses which key, so a rotation does not break a production workflow without notice.
Configure n8n and Ollama in this order
Run these steps in sequence so the model server, the storage path, the n8n connection and the vector store each pass a check before the next step depends on them. The examples use illustrative hostnames, paths and model names, so replace them with your own values. Keep the host, port, model name and embedding dimension consistent across steps, or later checks will fail for reasons that are hard to trace.
Install Ollama and check port 11434
Install Ollama on the host that will run the models, using the package or container method your platform team already supports for Linux, macOS, Windows or Docker. Start the service, then send a simple request from the same host to the local API on port 11434. The check passes when the API returns a response from the server on that host. Local API calls need no authentication, so this test needs no key. Record the host and port, because every later step refers to them.
Set OLLAMA_HOST and add a proxy
Ollama binds to 127.0.0.1 on port 11434 by default, so n8n on another machine cannot reach it until you change the bind address. Set OLLAMA_HOST only when other hosts must connect, and place a reverse proxy such as Nginx in front to handle access control and TLS. The proxy address is the one your n8n credential will use in the sixth step. Check by sending the same request from the n8n host through the proxy URL, and confirm the raw port accepts connections only from the proxy.
Move the model store with OLLAMA_MODELS
Set OLLAMA_MODELS when model files must sit on a larger or separately backed-up disk. The default locations are ~/.ollama/models on macOS, /usr/share/ollama/.ollama/models on Linux and the .ollama\models folder on Windows. Confirm the service account can write to the new directory before restarting, since a permission error here will stop the model pull. Check by pulling a model after the restart and confirming the files appear in the new directory.
Disable cloud features with OLLAMA_NO_CLOUD
Set OLLAMA_NO_CLOUD=1 or the equivalent entry in the server configuration file so the server runs without cloud features. Ollama states that when it runs locally it does not see your prompts or data, and this setting keeps the deployment on local inference. Direct cloud inference requires an API key sent as a Bearer token, so confirm that no such key is configured on the host. Check by restarting the service and confirming that a local model still answers.
Pull the model and confirm a local response
Pull the model you chose for this workflow, using the exact name and tag, and size it against the memory and compute of the host using the model's own documentation. Send a prompt through the local API and confirm a coherent response. Concurrency defaults matter here: OLLAMA_NUM_PARALLEL defaults to one parallel request per model, and OLLAMA_MAX_QUEUE defaults to 512 queued requests. Check by reading the response from the host and confirming that the model name matches what you pulled.
Create the n8n Ollama credential
In n8n, create an Ollama credential whose base URL is the proxy address from the second step, using the scheme, host and port that the n8n process can resolve. Run the credential test from the n8n instance itself. If n8n runs in a container, localhost points at that container, so use the proxy address. In queue mode, every worker that runs these nodes needs the same network route. Check by confirming that the credential test succeeds.
Build a test chat workflow in n8n
Create a workflow with a manual trigger, an Ollama chat model node that uses the credential from the sixth step and the model name from the fifth step, and a final step that displays or stores the output. Keep the first run to a single prompt so you can read single-request behavior before you add concurrency. Check by running the workflow and confirming that the execution shows model output with the expected model name.
Connect Qdrant or PGVector and test retrieval
Add the Qdrant or PGVector credential last, after the store is secured. By default, self-deployed Qdrant listens on all network interfaces with no authentication, so configure an API key and TLS first. Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3, and SSD or NVMe drives are recommended. The collection's vector size must match the output dimension of your chosen embedding model. Check by writing a test point, running a similarity query and confirming that the test point returns.
Which setting maps to which value across n8n, Ollama and the vector store
This table pairs each n8n credential or node field with the Ollama or vector store value it must match. Read each row as a pair: the value you enter in n8n and the value on the other side that has to agree with it. The most common failure is an embedding vector size that differs from the Qdrant collection configuration, which shows up as failed writes instead of a clear error.
| Setting | Where it is set | What it must match |
|---|---|---|
| Base URL and port | Ollama credential base URL in n8n | The host and port 11434 where Ollama listens. Default bind is 127.0.0.1, so change OLLAMA_HOST for remote n8n. |
| Model name | Chat and embedding model fields in the Ollama nodes | The exact name shown by ollama list on the Ollama host, including the tag. |
| API key for local Ollama | Ollama credential API key field | Leave empty. The local Ollama API does not require authentication. |
| Cloud API key | Separate credential for direct cloud inference only | Sent as a Bearer token to the cloud endpoint. Use it only for cloud models, never for the local server. |
| Embedding model and vector size | Embedding model field in the embeddings or vector store node | The vector size that model produces must equal the vector size configured for the Qdrant collection. |
| Qdrant collection name | Collection name in the Qdrant vector store node | An existing collection created with the same vector size and distance metric. Confirm the configuration in Qdrant before the first run. |
| Distance metric | Set when the collection is created in Qdrant, not in n8n | The metric your embedding model's documentation recommends. Confirm it in the collection info before loading data. |
| n8n encryption key | Main instance settings, copied to every worker and webhook processor | Identical on the main instance and all worker and webhook processor nodes in queue mode, so credentials decrypt on each node. |
Securing the Ollama and Qdrant endpoints
Ollama and Qdrant both leave important controls off or open in self-deployed form, and n8n holds the credentials that connect to them. The cards cover network binding, authentication, transport encryption, audit logging and the n8n encryption key that protects stored credentials. Each setting described here must be verified in your own deployment, because the configuration you run is the one that counts.
Keep Ollama on loopback
Ollama binds to 127.0.0.1 on port 11434 by default, so a fresh install is reachable only from the host itself. The OLLAMA_HOST variable changes the bind address, and that change is a common way the endpoint becomes reachable across the network without anyone intending it. Check the effective value on every host that runs Ollama, including containers and service units, and confirm that n8n reaches the address you intended. If workers on other machines need the model, place them on a private interface and keep the bind off public addresses.
Front Ollama with an authenticating proxy
The local Ollama API does not require authentication, so any client that can open a connection to the port can run inference and list models. If other services or users need access, expose the API only through a reverse proxy that enforces authentication, such as Nginx, as the Ollama FAQ describes. Terminate TLS at that proxy, restrict which source addresses can reach it, and log requests. Test from outside the proxy to confirm that direct access to port 11434 fails. Cloud inference uses a separate API key sent as a Bearer token, so keep that key out of exported workflows.
Treat self-deployed Qdrant as open by default
The Qdrant security documentation states that self-deployed instances listen on all network interfaces and have no authentication configured by default. A container started with a published port can therefore accept reads, writes and collection deletions from anyone who reaches that port. Before connecting n8n, confirm the bind address and published ports, and confirm that an API key is set. Check every environment, including staging copies of the workflow stack, because vector stores holding internal documents are often created quickly for testing.
Scope Qdrant access with API keys
Qdrant supports admin and read-only API keys. Give n8n a key that matches its role: ingestion workflows need write access to their collections, while retrieval workflows for an assistant usually need only read access. Since v1.9.0, JWT-based granular access control adds per-collection read or write permissions, so one shared key does not have to reach every collection. Decide the collection map before building workflows, store each key in an n8n credential, and verify with a test call that each key fails on collections outside its scope.
Encrypt Qdrant traffic and log API calls
Qdrant supports TLS for REST and gRPC since v1.2.0, which protects embeddings and retrieved text in transit between n8n and the vector store. Since v1.17.0, Qdrant can write JSON audit logs of authenticated API operations. Enable TLS on the instance, point the n8n Qdrant credential at the HTTPS or gRPC endpoint, and confirm that the n8n host trusts the certificate chain. Ship audit logs to the same store as your other logs, and test that a failed call and an ingestion run each produce an entry.
Protect n8n credentials and the shared key
n8n encrypts credentials stored in its database with an encryption key held by the main instance. In queue mode, every worker and webhook processor must use the same key, or they cannot read the credentials for the Ollama and Qdrant connections. Back up the key separately from the database, because restoring a database without its matching key leaves the stored credentials unreadable. Restrict who can view or export credentials in the n8n interface, and verify on each deployment that the key on every worker matches the main instance.
How queue mode and workers change where Ollama must be reachable
In queue mode, reachability has to be planned for every worker. The main instance receives triggers and webhooks, but the executions themselves run on workers that pick up jobs through Redis and read and write workflow data in PostgreSQL. Any worker that runs an Ollama Chat Model node or a Qdrant Vector Store node makes its own HTTP calls, so each of those workers must reach the Ollama and Qdrant endpoints directly. A firewall rule that opens port 11434 only from the main instance lets triggers arrive and then fails inside the worker, often after the webhook has already returned. Treat every worker as a possible caller, and test the path from a worker host, not from the main instance.
The encryption key must be identical on the main instance, every worker and every webhook processor. Workers need it to decrypt the credentials stored in PostgreSQL, including the Ollama and Qdrant credentials used by AI nodes. A worker started with a different or missing key fails the execution at the point where it reads the credential, which can look like a model problem. Put the key in your secrets manager, inject it into each process at startup, and confirm that a rotated key reaches all roles before the old key is retired. Verify the setup by running a workflow that uses a credential on a worker, not only one that runs on the main instance.
Multi-main high availability is restricted to Enterprise self-hosted deployments, so a Community edition or cloud plan cannot run several main instances for failover. If your availability target assumes that losing one main instance will not interrupt triggers, decide that before the build and confirm with n8n whether your license covers multi-main. Adding workers increases execution capacity, but it does not remove the main instance as a point of failure for triggers and webhooks. Plan recovery for the main instance, Redis and PostgreSQL as separate components, and record which of them your current license and architecture can actually protect.
Ollama runs as a single host unless you design your own serving layer in front of it, so capacity has to be set on that host. Three environment variables control how much work one instance accepts. OLLAMA_NUM_PARALLEL defaults to 1 parallel request per model, OLLAMA_MAX_LOADED_MODELS defaults to 3 times the number of GPUs or 3 on CPU, and OLLAMA_MAX_QUEUE defaults to 512 queued requests. With several workers sending chat requests at once, a parallel value of 1 means most requests wait, which lengthens executions. Set these values against your model sizes, memory and the number of concurrent worker executions you plan to allow, and confirm the defaults for your Ollama version in its FAQ.
By default Ollama binds to 127.0.0.1 on port 11434, and its local API does not require authentication. Workers on other hosts need either a changed bind address through OLLAMA_HOST or a reverse proxy in front of the service, and either option needs network restrictions so that only worker addresses can connect. Qdrant needs the same review: self-deployed instances listen on all network interfaces and have no authentication configured by default. Enable an API key and TLS before any worker connects, and ask your security team to review both endpoints as part of the build, including which addresses are allowed to reach each one.
How to test retrieval and model responses before go-live
This sequence checks that the n8n workflows, Ollama models and Qdrant collection behave as designed from the hosts and network segments they will use in production. Each step ends with a recorded pass or fail, judged against your own acceptance criteria.
Prepare synthetic and approved test data
The platform or data owner assembles a fixed set of synthetic or approved documents and prompts, with expected outcomes or grading notes for each prompt. Keep the set under version control so every test run uses identical inputs. Confirm in writing that no production records are included unless the data owner has approved them for testing. The pass check is a signed-off test set and a written list of the acceptance criteria that will decide each result.
Confirm model responses from a worker host
Run the fixed prompts from a queue worker host, not only from the main n8n instance, because workers are the processes that call Ollama in production. Confirm the worker reaches the approved Ollama address and that each response returns within the timeout your workflows expect. Grade each answer against the criteria from the first step. The check is complete when every prompt is either passed or logged with a reason, and the results from the worker match the results from the main instance.
Verify embedding, storage and similarity retrieval
Send one synthetic document through the ingestion workflow and confirm that the embedding model produces a vector, that the point is written to the target collection, and that its payload fields are stored as designed. Then run a similarity query using a phrase from that document. The pass check is that the test document is returned among the top results with its metadata intact. Also confirm that the vector size in the collection matches the output size of the embedding model, because a mismatch fails at write time.
Check that the read-only Qdrant key cannot write
Use the read-only API key that the workflows will hold in production and attempt a write, an update and a delete against the test collection. Qdrant supports admin and read-only API keys, and granular per-collection read or write permissions depend on your version and configuration, so confirm which model your deployment uses. The pass check is that every write attempt is refused while the same key can still run similarity queries. Record the responses so the result can go into the access review.
Confirm Ollama refuses requests from outside the network
Ollama binds to 127.0.0.1 on port 11434 by default, so confirm the address set through OLLAMA_HOST matches your design and that the host firewall allows only the approved worker and main instance addresses. From a host outside that network segment, attempt a request to the Ollama API and expect a refusal or timeout. Also confirm that cloud features are disabled on the server, for example with OLLAMA_NO_CLOUD=1, if your policy requires it. The pass check is that the outside request fails and the approved hosts still succeed.
Verify execution and audit logs record each call
Trigger the test workflows and then review the n8n execution history for each run, checking that every node output and error is recorded and that the workflow identity matches the test. Next, review the Qdrant audit log for the authenticated operations from the earlier steps. JSON audit logging of authenticated API operations is available from Qdrant v1.17.0, so confirm your deployed version supports it. The pass check is that each test call appears in both logs with matching timestamps and the expected key or workflow identity. Missing entries are a failed check and should be traced before go-live.
Run a load test within Ollama queue limits
Ramp the test workload gradually from the worker hosts, and record the values of OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE in effect during the run. The documented defaults are one parallel request per model and 512 queued requests, so size the test so that it respects those limits unless you have deliberately changed them. Watch queue depth, response latency and error rates, and confirm that requests beyond the queue limit are rejected in a way the workflows handle. The pass check is that latency and error rates meet the criteria you set in advance, and that the queue never exceeds its configured limit.
Common failures when n8n calls Ollama and Qdrant
This table lists the failures teams most often hit when n8n calls Ollama and Qdrant on self-hosted infrastructure. Read each row from left to right: the likely cause points to the setting or topology to inspect, the check confirms it, and the fix names the change to make. Most failures trace to network reach, default settings, or storage and key handling, so confirm reachability before tuning models.
| Failure | Likely cause | Check | Fix |
|---|---|---|---|
| n8n cannot reach Ollama | n8n runs in a container or on a worker, so localhost points to its own network. | Request the Ollama API on port 11434 from the n8n container or worker host. | Use the host address or service name in the Ollama credential URL. |
| Ollama refuses remote connections | OLLAMA_HOST was left unset, so Ollama binds only to 127.0.0.1. | Check the bind address in the Ollama service environment and the listening sockets. | Set OLLAMA_HOST to a private interface and restrict port 11434 with firewall rules. |
| Requests queue or time out | OLLAMA_NUM_PARALLEL defaults to 1 per model, and OLLAMA_MAX_LOADED_MODELS defaults to 3 per GPU or 3 on CPU. | Run parallel executions and watch for queued requests, timeouts and models reloading between runs. | Raise both values to match concurrent workflows, then confirm memory headroom with a load test. |
| Workflow works on main but fails on a worker | The worker cannot reach the Ollama or Qdrant address. | Run a test request from the worker host using the same credential the main instance uses. | Open the network path from every worker to Ollama and Qdrant, then retest on a worker. |
| Credentials fail after a move | The encryption key was not shared with the new instance or with worker and webhook processor nodes. | Compare the encryption key on the main instance with each worker and the new host. | Share the same key with all nodes; if the original key is lost, recreate the affected credentials. |
| Qdrant writes fail | The Qdrant storage path sits on NFS or object storage, which Qdrant does not support. | Check the file system type of the Qdrant storage directory and its mount options. | Move storage to local block devices, preferably SSD or NVMe, with a POSIX-compatible file system. |
| Similarity results are empty or wrong | The embedding dimension or distance metric differs from the Qdrant collection settings. | Compare the vector size from the embedding model with the collection configuration. | Recreate the collection with the matching size and metric, then re-embed the documents. |
| Qdrant accepts calls with no key | Self-deployed Qdrant listens on all interfaces with no authentication by default. | Call the collections endpoint without a key from another host on the network. | Enable API key or JWT access control, add TLS, and limit which hosts can reach Qdrant. |
| Cloud calls appear in Ollama traffic | OLLAMA_NO_CLOUD was not set, so cloud features remain enabled on the server. | Review the Ollama server environment and logs for requests to cloud models. | Set OLLAMA_NO_CLOUD=1 or the equivalent in the Ollama server configuration file. |
Questions buyers ask before connecting n8n to Ollama
How much does it cost to connect n8n to Ollama?
The cost depends on the scope agreed in writing, and a quote follows from that scope. The main drivers are the hardware that hosts the models, the number of workflows to build and test, the retrieval scope if you add a vector store, and the network and security design. Hardware is usually infrastructure you already own or allocate, so the main project cost is the labor to design, build, test and hand over the system. Ongoing costs include running the infrastructure, time for your team to apply upgrades to n8n, Ollama and any vector store, and an optional support retainer. Ollama's local runtime carries no license fee for local use, and the open-source Qdrant engine is free to self-host, so most spend is labor and infrastructure. When you request a quote, ask for hardware assumptions, workflow count, retrieval sources, environments, and whether the work is fixed-scope or retained.
How long does an n8n and Ollama project take?
The duration depends on how quickly your environment is ready, how long approvals take and how much testing you need. Environment readiness means the hardware is provisioned, GPU drivers work, models are downloaded, and a private network path exists between n8n and the Ollama API. Approvals for network rules, data access and test data often take longer than the technical build, so start them early. Testing scope drives the rest. A small set of workflows tested with synthetic inputs takes less time than a set that covers retrieval, error handling, credential handling and access control. DeployOpen does not publish durations. Confirm the schedule, its dependencies and its assumptions in the written scope before work starts.
Can our internal team connect n8n to Ollama without a partner?
Yes, an internal team can do this if it has engineers who can operate Linux, containers, networking and n8n. Before starting, review the n8n Sustainable Use License, which permits use for your own internal business purposes but limits distribution and other uses, and confirm with counsel that your use fits. Files with .ee in their name need a valid n8n Enterprise License. Your testing steps should include confirming Ollama binds only to the interface you intend, blocking external access to port 11434 because the local API has no authentication, checking that n8n workflows return correct output on approved test data, verifying credential handling, testing retrieval permissions if you use a vector store, and rehearsing an upgrade and restore before production use.
What does our organization need to provide for the project?
Four inputs decide whether the project moves on schedule: hardware access, network rules, a named owner and approved test data. Hardware access means the team can install and configure the servers or accelerators that host Ollama and any vector store, including drivers and storage. Network rules define which hosts can reach the Ollama API, the n8n instance and the Qdrant endpoint, and they should be written before the build starts. A named owner makes decisions on scope changes, approves production access and signs off testing. Approved test data lets the team check workflow output against realistic cases without exposing data that policy forbids. Ask the implementation partner to list these inputs in the written scope so you can assign them before the build begins.
Do we need a commercial license to use n8n with Ollama?
Internal business use of n8n is permitted under the Sustainable Use License, which allows use or modification for your own internal business purposes. The license restricts distribution to free, non-commercial purposes, so offering an n8n-based service to outside customers needs a separate review of the terms. Any files with .ee in their name require a valid n8n Enterprise License, and features such as SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Ollama is licensed under MIT and Qdrant's open-source engine is licensed under Apache-2.0, so those components carry different terms. Confirm how your intended use fits these licenses with your legal or compliance team before you deploy.
Do we need Ollama's paid cloud plans to run local models?
No. Ollama's pricing page states that running models on your own hardware is always unlimited, so local models do not require a paid plan. The paid plans cover cloud models: Pro at $20 per month ($200 per year), Max at $100 per month, Team at $500 per month and Enterprise at custom pricing. Enterprise adds model access controls, cost budgets per user or API key, a dedicated support channel and custom security options. Cloud inference requires an API key sent as a Bearer token to ollama.com. If your policy forbids any external calls, set OLLAMA_NO_CLOUD=1 or the equivalent server configuration setting, and confirm in testing that no workflow reaches a cloud endpoint.
Which network settings keep Ollama and Qdrant private?
Ollama binds to 127.0.0.1 on port 11434 by default, and the OLLAMA_HOST variable changes that bind address. Its local API has no authentication, so any client that can reach the port can send prompts. Keep it on a private interface, restrict it with host firewall rules to the n8n host, or place it behind a reverse proxy such as Nginx that enforces authentication. Qdrant is different: by default, self-deployed instances listen on all network interfaces and have no authentication configured. Enable admin and read-only API keys, TLS for REST and gRPC, and per-collection JWT permissions where your access model needs them, and turn on audit logging so authenticated operations are recorded. Test each setting from a host outside the allowed network.
Can Qdrant run on our existing NFS or S3 storage?
No. Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on network file systems such as NFS or on object storage such as S3. Qdrant's installation documentation recommends SSD or NVMe drives. Plan the storage layout before you install, because moving a populated instance later adds work. For production clusters, the distributed deployment documentation recommends at least three nodes so quorum survives a node failure, and it explains that the replication factor duplicates stored data, so a factor of 2 doubles storage use. Check the storage, node count and replication factor against your retrieval volume and your recovery target. Confirm the backup approach with the snapshot documentation before go-live.
How DeployOpen scopes and delivers n8n with Ollama
DeployOpen plans and builds n8n with Ollama inside infrastructure you control, so model calls and retrieval stay on your network. Each engagement starts from a written, fixed scope that names the workflows, models, vector store and access model in use. Ongoing support, upgrades and testing are available as a retainer.
How we scope
- The written scope lists each workflow, its trigger, and the n8n data sources and business systems it touches.
- It names the Ollama models, hardware, and API access paths that workflows will call on your network.
- Vector store choice, storage needs, and access controls for Qdrant, where chosen, are agreed before any build starts.
How we build
- Ollama is bound to an internal address via OLLAMA_HOST, with cloud features disabled where policy requires.
- Model storage paths, OLLAMA_NUM_PARALLEL and queue limits are sized against the concurrency your workflows need.
- Qdrant is deployed with API keys and TLS enabled, because default self-deployed instances have no authentication.
How we hand over
- Workflow exports, n8n credential handling notes and a record of the Ollama and Qdrant settings are documented.
- Handover includes test runs of each workflow, plus access checks against the Ollama and Qdrant endpoints.
- Your legal team receives the Sustainable Use License text and a summary of your intended use for review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade plans cover n8n and Ollama release cadence, which is frequent, so model and node changes are tested first.
- Qdrant version changes, backup and snapshot routines, and access reviews are agreed in the support scope.
