Conditional verdict: name the AI execution context first
“AI on n8n” can describe four placements: an external provider, JavaScript in Code, n8n Assistant, or a resident model and vector database. A mixed workflow can use more than one. Record selected components separately; do not provision every optional path as required.
Pause a same-host decision if the workflow’s payload and concurrency are unknown, model requirements have not been checked, the only model route is a public listener, or the selected sandbox privilege is not accepted. A successful API call says nothing about local inference capacity. A reachable model says nothing about whether the workflow has enough execution memory or a recoverable index.
This page covers n8n-side placement and contention. Model-family, quantization and VRAM questions belong to the existing Local AI VPS guide. Choose an exact n8n image tag and inspect its own release notes before changing workflows: the captured 3.0 release notes say “Released,” while its breaking-change page calls 3.0.0 early access and another channel reference names older stable/beta labels. That conflict is unresolved here; do not infer a universal current channel or use latest as a migration plan. [N29, N30, N48]
Four AI contexts have different dependencies
The table is a classification worksheet, not a product comparison. For each workflow, mark the active row, record its dependencies and leave unused options unselected. Provider charges, edition features and operational work remain separate inputs for the cost walkthrough.
| Context | What runs where | Record before placement |
|---|---|---|
| Hosted model/API node | Model inference is handled by the external provider; n8n still orchestrates data and receives results. | Credential owner, outbound destination, provider quota/rate limit, retry policy, payload/response size, data leaving the VPS, and execution memory. API/model spend is unresolved until the selected provider and terms are checked. |
| Code task | Code executes within n8n’s Code task model; external mode uses a separate runner sidecar. | Task manifest and dependencies, matching n8n/runner version, concurrency, timeout and resource policy, data copies, allowed network access and runner placement. |
| n8n Assistant | Assistant uses a model provider, a required code sandbox, and optional search. | Provider and API credentials; sandbox type, trust boundary and privileges; search selection; edition/readiness; renewal of generated mTLS material; cost owner for each selected service. |
| Resident inference/vector | Model runtime and optionally vector service run on a host/container you operate. | Runtime and exact image, model artifact and cache locations, index/documents, persistent mounts, accelerator access if any, private endpoint and distinct backup/rebuild owner. |
Hosted model/API nodes
An API call consumes network access, credential handling and n8n memory for inputs and returned data. It can fail from quota, rate limits or provider availability even when the VPS is idle. Retrying without a bound can increase both the queue and external spend. Record what data crosses the provider boundary and whether retries are safe for the workflow’s side effects. No local model disk or GPU follows merely from selecting an AI node.
Code-node AI tasks and external runners
Task runners isolate Code execution; an external runner is a matching-version sidecar, not a Redis queue worker and not an inference server. A Code task may still process large inputs and consume compute. Record package requirements, concurrency, timeout, output size, permitted destinations and whether every worker has its corresponding runner. For queue topology, see queue, workers and concurrency; secrets and runner credentials belong with Article 9. [N15]
Assistant sandbox is not a resident model
Captured self-hosted Assistant guidance requires a model provider and code sandbox; web search is optional. The docs label Assistant as having limited enterprise readiness, including partial support for listed enterprise capabilities, so treat that as a feature-readiness gate, not production proof. The official bundled sandbox includes a privileged Docker-in-Docker runner. Its documented at-least-4-GB RAM and 2-vCPU note applies to that Assistant sandbox stack only, never bare n8n. Accept the privilege explicitly or choose another supported arrangement after reviewing its requirements. Generated certificates and renewal are lifecycle work; do not assume a one-time setup renews itself. [N03, N49]
Count the model provider, sandbox and optional search only if selected. A managed sandbox replaces the self-hosted sandbox responsibility rather than adding a second simultaneous sandbox by default. Assistant is not local inference: a provider-backed Assistant still has external API dependencies.
Resident inference and vector services
The official self-hosted AI starter kit combines n8n, Ollama, Qdrant and PostgreSQL, but describes itself as a proof-of-concept project that is not fully optimized for production. Its presence proves a template composition, not security, recoverability, performance or a universal host requirement. Inventory actual model files, runtime cache, vector documents/index, database, any prompt/response artifacts and accelerator passthrough only when chosen. Decide whether each data set is backed up or deliberately rebuilt. Keep model sizing theory on the Local AI guide. [N39, N40]
Attribute workflow and service memory instead of guessing
n8n does not cap the amount of data a node can fetch and process. Memory demand can rise with JSON volume, binary data, node behavior, Code or older Function work, manual runs that copy data for the editor, and concurrent executions. An AI step can add a large prompt or response to that execution, but a provider call and a resident model have different service allocations. [N12]
Observe a named window that includes ordinary peaks, not just idle. Keep average and peak separate. The sum below is an inventory method, not a sizing formula: entries must come from the deployment or remain unknown.
| Observed component | Record | Boundary to preserve |
|---|---|---|
| n8n main and any webhook processors | Idle/peak allocation, execution class, manual versus production runs, concurrent workflows, payload and binary behavior. | Do not attribute all host memory to one process or assume editor runs equal production runs. |
| Workers and Code runners | Number and placement, version match, concurrent tasks, task memory/timeout policy, queue and error behavior. | Workers execute queue jobs; Code runners execute Code tasks. They are separate components. |
| Database, Redis, proxy and OS | Observed allocations and relevant storage/connection behavior for selected services. | These remain needed even when inference is external; do not omit their baseline. |
| Selected model, vector and Assistant services | Measured allocation for each selected service, startup/pull peaks, index growth and whether resources are capped by the actual runtime. | Optional alternatives are counted once; unknown stays unknown. File size is not a memory conversion. |
| Headroom and stop criteria | Operator-defined reserve, alert thresholds, latency/error limit and observation period. | No universal safe percentage or performance promise is implied. |
Write the calculation as: observed main + workers/webhooks + matching Code runners + DB + Redis + proxy + selected model/vector/Assistant services + explicit operator headroom. If an item is not observed, label it unknown and stop before calling the placement accepted. Increasing a host allocation can be one response to measured pressure; reducing payload, batching bounded work, reducing concurrency or moving a component may address the cause. n8n documents bounded sub-workflows as one memory-reduction approach, but its example is not a benchmark or a universal chunk size.
Separate failure classes: a provider rate limit is not host memory pressure; a Code timeout is not proof of slow hardware; model saturation is not n8n OOM; and a growing queue can reflect downstream backpressure. Observe the process, execution and dependency that failed before changing allocation.
Disk, binary retention and external stores
Inventory persistent and temporary bytes by owner. A successful image pull or model download can require extra temporary space alongside retained data, while an export or restore needs its own destination. The table makes growth and recovery visible; it is not a disk-size recommendation.
| Artifact | Measure and growth question | Retention / recovery owner |
|---|---|---|
| OS and container images | Current image layers, update/pull overlap and rollback image availability. | Platform operator; deployment pins and update procedure. |
| Model files and runtime cache | Exact selected artifacts, download temporary space, cache location and replace-versus-retain decision. | Model operator; document license/source and reproducible acquisition route. |
| Vector documents and index | Source document volume, index growth, database files and any rebuild staging space. | Application/data owner; tested backup or documented rebuild acceptance. |
| n8n, database and execution data | .n8n including key material where applicable, database state, execution retention and custom paths. | See database and backup boundaries and recovery planning. |
| Binary data, exports and temporary copies | Selected binary mode, retention window, dump/export staging, independent copy and restore workspace. | n8n operator and external-store owner if selected; avoid counting one payload as both local disk and object storage. |
Version matters. Captured pre-3.0 material describes default in-memory binary behavior; 3.0 breaking-change material says it is removed and filesystem becomes the fallback for old configuration. Check the target release and mounted disk. Ordinary queue guidance does not support filesystem binary persistence, while a narrow large-response relay-offload exception describes shared storage and says shared filesystem is not recommended. These are different paths. See the queue article. External object storage has edition and lifecycle implications; do not assume it is enabled or free. [N10, N13, N14, N29]
Keep model and orchestrator networking private
Each container has its own loopback interface. localhost inside n8n points back to n8n’s container, not automatically to a separate Ollama container. Captured newer Ollama Chat guidance recommends a same-user-defined Docker network and service-name URL such as http://ollama:11434; it does not require publishing a host port. Older guidance describes host-gateway or port-published arrangements. Preserve that conflict if the selected topology needs the older route, and verify it for the actual OS and Docker setup. [N41, N42]
- For co-located containers, prefer a private user-defined network where applicable. Record the service name, port and which containers can join it.
- For a host process reached by a container, validate the host-gateway mechanism and bind address on the selected platform; keep any host listener private or controlled.
- For a separate host, container service DNS does not cross machines. Specify routed private connectivity, firewall rules, endpoint authentication/encryption and an owner on each side.
- Do not publish model or vector admin ports to the public interface as a connectivity shortcut. A model endpoint being reachable is not caller authorization.
n8n’s SSRF protection can block private, loopback and link-local targets by default, with controlled allowlisting; captured 3.0 notes expand defaults. This application control supplements network isolation; it does not replace firewall policy or make a broad allowlist safe. Test intended destinations with the selected release and preserve the actual network boundary. Public webhook ingress belongs in Article 6; credential lifecycle belongs in Article 9. [N20, N29]
Same host versus separate AI host
Use the matrix conditionally. Same host is a candidate only after peak orchestration and selected AI allocations are observed, concurrency is bounded, private routes work and privilege is accepted. A split can reduce contention or separate lifecycle, but adds routing, authentication, monitoring, transfer and a recovery owner. It does not create high availability.
| Dimension | Same-host candidate | Separate-host candidate | Evidence / stop signal |
|---|---|---|---|
| n8n baseline and concurrency | Measured peak leaves operator-defined headroom with selected context active. | AI demand repeatedly contends with orchestration or execution class needs isolation. | Record process-level observations and workflow errors; unknown peak means no placement verdict. |
| Privilege and network | Private service network; any privileged sandbox explicitly reviewed. | Separate trust boundary or sandbox owner is required. | Unexpected public listener or unaccepted root-equivalent privilege stops acceptance. |
| State and recovery | Model/vector artifacts have named backup or rebuild plan on shared host. | Independent restart, update or retention owner outweighs added service complexity. | Missing index/model/config recovery owner blocks the change. |
| Storage, hardware and policy | Observed disk growth and device access fit the chosen host and its verified terms. | Different storage/device requirements or provider terms call for separate placement. | Check actual architecture, passthrough support and acceptable-use terms where selected; “AI-ready” is not evidence. |
| Failure behavior and cost | Workflow can pause/retry safely while local service is unavailable. | Independent lifecycle or failure isolation warrants network and cash complexity. | Document idempotency, offline behavior, transfers and operator time; split is not automatic failover. |
Choose one disposition: co-locate with measured limits; reduce payload or concurrency; switch to an API or other selected context; split model/vector/sandbox; or defer. Preserve rejected options so costing does not count them as active. If a workflow’s retries can duplicate external side effects, establish deduplication or manual reconciliation before changing placement.
Runbook: baseline, add one context, observe, choose
This bounded, read-only worksheet prints service names, image references, mounts and published-port mappings without displaying environment values, pulling images or changing containers. Run as the deployment operator with Bash and Docker Compose on the reviewed project. Do not run against an unfamiliar production host; record output in an access-controlled change record.
- Preconditions. Identify the owner, host, selected n8n release/tag, workflow and execution class, observation window, approved maintenance/change window, rollback target, existing monitoring and a verified recovery route for
.n8n, database, selected model/vector data and configuration. Put API keys outside notes and shell history. Do not start a model pull on a valuable host as discovery. - Fresh versus occupied. Establish whether this is an empty disposable staging project or an occupied instance. The script below only inspects. If project identity is ambiguous, containers are not the expected deployment, or any proposed change would reuse an unknown volume, stop. Do not convert “no matching containers” into permission to initialize production.
- Preflight. Record available/used disk using the host’s established monitoring, image/model sizes from trusted selected manifests, exact persistent mounts, CPU/RAM allocation evidence, OS/architecture and any verified GPU/pass-through compatibility. Confirm accepted-use terms, licenses, sandbox privilege and backups. Unknown headroom, storage destination or recovery coverage blocks activation.
#!/usr/bin/env bash
# Read-only inventory for the reviewed Compose project. No env dumps.
set -euo pipefail
umask 077
: "${PROJECT_DIR:?Set the absolute path to the reviewed Compose project}"
[[ "$PROJECT_DIR" == /* && -d "$PROJECT_DIR" ]] || { echo 'Invalid project directory' >&2; exit 2; }
cd -- "$PROJECT_DIR"
docker compose version
echo '--- Compose configuration: redact secrets in local output ---'
# Config may render substituted values. Keep it on screen only in a private
# session; NEVER redirect it into shared logs or paste it with secrets intact.
docker compose config --services
echo '--- Existing project containers ---'
docker compose ps --all --format '{{.Service}} {{.State}} {{.Publishers}}'
echo '--- Container image references and mounts (no environment) ---'
ids="$(docker compose ps --all -q)"
if [[ -n "$ids" ]]; then
docker inspect --format '{{.Name}} image={{.Config.Image}} mounts={{range .Mounts}}{{.Type}}:{{.Source}}->{{.Destination}} {{end}}' $ids
else
echo 'No containers for this Compose project; confirm whether project is fresh.'
fi
echo '--- Declared service names and published-port mappings ---'
docker compose config --format json | jq -r '
.services | to_entries[] |
[.key, ((.value.ports // []) | map(
if type == "object" then
((.host_ip // "unspecified") + ":" + ((.published // "unspecified")|tostring) + "->" + ((.target // "unspecified")|tostring))
else (tostring) end) | join(","))] | @tsv'
echo 'Discovery only. Do not activate services until manual gates pass.'Output handling: docker compose config can resolve substitutions and may reveal sensitive values depending on the project. The command above asks Compose only for service names, but even rendered output may be sensitive. Run in a private terminal; do not capture the complete rendered configuration into a shared transcript. The later checks use service names and metadata only. Never print process environments, .env, keys or decrypted credentials.
- Baseline first. Before activating anything optional, capture timestamped idle and representative n8n observations: host and container CPU/memory, disk growth, execution counts/concurrency, queue depth if used, DB/Redis state, errors and qualitative workflow latency. Record source and peak/average distinction. Run one harmless orchestration workflow within its known bounds; verify output and downstream state.
- Add one context. Change one selected component only, using reviewed exact image tags and private networking. For API or Code, begin with one bounded synthetic input. For Assistant, separately confirm provider/sandbox/search selections and the privileged boundary. For resident inference/vector, confirm model/index storage and stop before any unbounded download. Do not combine all optional services in one first acceptance.
- Observe and increment cautiously. Compare the same process and workflow observations. If representative workload is approved, increase concurrency by one operator-defined step at a time, with a known input cap, retry limit and time box. Record RAM, CPU, disk, network, execution/queue errors and dependency health. This is workload acceptance, not a benchmark.
- Stop branch. Stop the experiment and hold new AI-triggered work if memory exhaustion, disk pressure, unexpected restart, public model listener, unbounded retry/backlog, exceeded operator error/latency threshold, or missing/corrupt output appears. Preserve logs with secrets redacted and the last known-good configuration. Do not delete volumes or repeatedly restart to clear evidence.
- Rollback gate. The operator verifies recovery point, state consistency and whether in-flight work can be reconciled. If safe, remove or disable only the newly selected component using its reviewed change procedure, restore the recorded network/configuration state, then verify n8n baseline and harmless workflow. Keep ingress/workload held if the baseline is not healthy; recover data from the verified backup or isolated replacement before reopening. Article 10 owns full recovery and cutover acceptance.
Acceptance receipt: date/window and host; exact n8n and selected service tags; chosen and rejected contexts; workload and concurrency bounds; baseline/peak observations and thresholds; network route and listener review; disk/mount/recovery owner; test inputs and outputs; errors/retries; stop criteria observed or not; rollback point and operator; final disposition. A pass means this bounded observation met the stated conditions only. It does not establish production safety, capacity, availability or a performance guarantee.
Current-release AI gates and operational failure triage
For the captured n8n 3.0 breaking changes, legacy OpenAI Assistant/OpenAI Model and AI Transform nodes are removed, AI Agent v1 is removed, and the documented Code task timeout default changes from 300 to 60 seconds. Treat these as version-specific migration inputs, not a claim that an upgrade is appropriate. Before migration, select the exact tag, inspect matching release notes and migration report, locate affected workflows, test their behavior and approve rollback/recovery. The 3.0 release/channel labels conflict in the captured references, so the target channel remains a pre-publication and deployment check. [N29, N30, N50]
| Symptom | Inspect first | Safe branch |
|---|---|---|
| AI execution OOM | Payload/binary size, concurrent/manual runs, n8n process and Code runner observations, recent node/data changes. | Bound input, batch work or reduce concurrency; change allocation only from measured evidence. Preserve failed execution evidence. |
| Disk rises after model activity | Model pull, cache, image layers, temp space and persistent mount destination. | Pause further pulls; verify retention and free-space recovery plan before cleanup. Do not prune blindly. |
| Vector data missing after recreate | Actual mount, database/index persistence and selected backup/rebuild route. | Stop writes if recovery state is uncertain; restore or rebuild in an isolated target and verify expected records. |
| Container connection refused to model | Container-local localhost assumption, service DNS/network membership, listener and port. | Use the reviewed private service route; do not solve by public port publication. |
| Port 11434 reachable publicly | Container published ports, host bind, firewall and external exposure path. | Restrict exposure immediately through the approved network change, then verify from an external vantage point. Treat as an incident if untrusted access may have occurred. |
| API throttling or backlog | Provider quota, retry policy, event rate and queue accumulation. | Bound retries/backpressure or pause upstream triggers; do not add workers without identifying the constrained dependency. |
| Code task hits 60-second timeout | Selected n8n default/configuration, task duration, runner version and data volume. | Confirm release-specific policy and task suitability; split work or set a reviewed supported policy rather than interpreting timeout as a host benchmark. |
| AI node missing after upgrade | Exact source/target tags, migration report and removed-node changes. | Keep cutover blocked; restore or migrate workflow using version-matched guidance and approved recovery. |
| Assistant provider/sandbox failure | Provider reachability/key owner, required sandbox enablement, matching service/API configuration and readiness scope. | Keep Assistant use disabled while fixing dependency; do not expose sandbox endpoints to test reachability. |
| Sandbox certificate renewal or trust failure | Certificate dates, service names/SANs, mounted cert state and renewal owner. | Follow reviewed renewal procedure; avoid disabling mutual TLS as a shortcut. See Article 9. |
Community reports can suggest symptoms to inspect; they do not establish frequency, model quality or provider reliability. Ask what process, route, state and version can be verified.
Cost and Local AI hand-off
Return a selected/rejected inventory to the cost article: host placement for n8n, workers and any model/vector service; external API, search or sandbox only when selected; model, vector, cache and binary disk; export and recovery copies; inbound/outbound and host-to-host transfer; optional device or privilege requirements; operator time for updates, monitoring and recovery. Keep unresolved provider charges as unresolved rather than zero. Use the VPS cost tool only with evidenced inputs.
At provider pages, verify only the requirements your chosen topology needs: observed CPU/RAM/disk allocation, supported device passthrough and acceptable-use terms where relevant, private routing/firewall controls, persistent storage and recovery options, and the boundary of support for n8n versus third-party components. Do not infer an “AI-ready” claim from a generic VPS description.
Use Local AI VPS for model family, quantization, VRAM and serving theory. For data copies, compare backup versus snapshot responsibilities; when leaving a service, check stop, deletion and billing terms for retained disks or external subscriptions. Return to the n8n VPS hub if AI is not the workload that determines placement.
Sources and updates
Source captures checked 2026-11-06. Version-sensitive channel, Assistant and Ollama behavior must be rechecked against the selected release before publication or migration.
- n8n: Fix memory issues — execution data, Code/manual-run memory risks and bounded-work guidance. [N12]
- n8n: Set up task runners and Harden task runners — external runner model and security boundary. [N15, N21]
- n8n: Set up n8n Assistant — provider, required sandbox, optional search and readiness notes. [N49]
- n8n-io: Self-hosted AI Starter Kit — included services and proof-of-concept scope. [N39, N40]
- n8n: Ollama Chat Model common issues and Ollama node common issues — captured newer and older reachability guidance. [N41, N42]
- n8n: SSRF protection — application-level destination controls. [N20]
- n8n: Docker Compose installation — bundled Assistant sandbox requirements and the narrowly scoped resource note. [N03]
- n8n: Queue mode; Handle binary data; External storage — queue and version-scoped storage boundaries. [N10, N13, N14]
- n8n 3.0 breaking changes, release notes, migration tool, and Docker installation guidance — selected-version review required; channel labels conflict in captured sources. [N29, N30, N48, N50]
Updated 2026-11-06 from local primary-source captures. No resource benchmark or deployment result is claimed. Read the methodology for how evidence and unknowns are handled.