n8n with resident AI services: same VPS or split hosts?

Classify the actual AI context

Resident services only

This decision concerns services that remain available or hold data between n8n requests: a model-serving runtime, an embedding process, a reranker, Qdrant or another selected vector store, source documents, model files, runtime caches and device drivers. A resident process may be idle much of the time and still reserve memory, hold files open, consume disk, or need an operator when its host or dependencies change.

Record one line per selected service. “AI” is too broad to place: inference may use CPU or an accelerator; embedding may share a runtime or use another process; a reranker can create a separate peak; a vector service may retain indexes and payload on disk while caching selected structures. For each line, identify the exact release or image tag, executable/build and device path, persistent mount, caller, resource owner and recovery method. The same model file size does not establish host RAM or VRAM need. Keep weights, runtime allocation, activations and KV cache separate; keep Qdrant structures, source corpus, cache and recovery copies separate as well. The model and memory worksheet belongs to Article 4; Qdrant structure and recovery quantities belong to Article 6.

Driver and device access follow the process that uses the accelerator. A container label alone does not prove that a host device is visible, that the selected runtime build supports it, or that two services can share it safely. Ollama’s Docker documentation describes a model volume and container packaging example; it is not evidence that an arbitrary host or GPU is compatible. vLLM documents separate CPU and GPU installation paths, and llama.cpp documents backend-specific builds. Pin the chosen service and build before accepting device assumptions. See Article 5 for runtime-specific capability and lifecycle questions.

Keep n8n-specific contexts elsewhere

This page treats n8n as a caller and a neighboring resident workload. It does not size workflow execution, explain JSON or binary payload handling, design Code task runners or the Assistant sandbox, discuss SSRF controls, or make claims about n8n releases. Those subjects belong to the existing n8n AI resource planning guide and its linked n8n security material. That guide is a scope boundary here, not evidence for new n8n behavior.

The supplied L07 n8n/Ollama common-issues material is useful narrowly: it distinguishes caller network arrangements. It does not determine which placement is best for your workload. If you use an n8n model node, its exact behavior, credential setup, processing semantics and selected version must be checked in the n8n-owned documentation. This article uses topology examples only to prevent the common addressing error of treating one container’s localhost as another container’s localhost.

Map processes, data and callers

Draw the system before comparing locations. Include every selected resident service and every copy of data that must survive. The table is an intake worksheet; blank fields mean unknown, not zero. “Peak” should refer to a named observation window and workload, not an assumed universal multiplier.

For every row, record source of the value, unit, time window, average versus peak, and whether the figure is measured, documented or still open. A selected release is not a measured requirement. Runtime settings are version-specific: for example, captured Ollama context guidance and its FAQ default conflict, so record the selected version and configured context rather than borrowing a generic number. vLLM’s documented allocation and KV-cache settings apply to particular runtime configuration, not a host-wide capacity formula. Use the separate memory article for the complete field set.

Trace the service route one caller at a time

For each route, write caller location → name resolution → destination address and port → process bind → container/host publication → firewall or private network → return route. A process listening on an interface does not prove that a host port is published; publication does not by itself authorize internet access. A host listener, container namespace, network membership and provider routing are separate facts. Record the allowed caller and denied caller explicitly. Use Article 8 for endpoint reachability and authorized verification.

Then map data movement. Mark whether source documents, prompts, generated outputs, embeddings, vectors, snapshots or binaries cross a host boundary; record origin, destination, direction, estimated or observed bytes and period. Include staging and recovery transfers. These flows affect exposure, troubleshooting, transfer charges and restore time. A private route does not eliminate data governance or credentials, and no performance or privacy result follows from topology alone.

Assign a failure and recovery owner before placement

For each process, identify who notices a failure, who may pause new work, who owns the last accepted data copy, and who decides between restoring and rebuilding. State the acceptable data loss and recovery time as goals. Keep the model artifact, runtime configuration, Qdrant collection snapshots, source data and host configuration as distinct recovery items. Qdrant’s captured documentation distinguishes collection snapshots, which cover a collection on a node at a time, from full-storage snapshots, which are suitable only for single-node deployments and not distributed mode; neither establishes complete host recovery. Confirm the selected Qdrant version and required copies. A snapshot, replica or persistent mount is not automatically an independent backup.

Recovery can require simultaneous source and destination space, temporary files, compatible versions and a verified route. Do not assume a rebuild or repull is immediate, free, or possible from an unverified registry. Set a disk floor and a stop owner before adding data. Article 9 handles model stop, deletion and repull lifecycle distinctions; Article 6 owns Qdrant data and recovery calculations.

Compare same box and split placement

Choose among complete alternatives, not by adding every possible service to one theoretical bill. Mark each row selected, rejected or unresolved and explain the evidence behind it. A same-box design can reduce the number of hosts while concentrating resource and recovery responsibility. A split design can create a separate allocation boundary while adding address, transfer and operating dependencies. These are trade-offs to assess, not guarantees about outcomes.

Same box

Co-location may be reasonable when the selected model, embedding/reranking and vector services fit the measured host envelope during representative bounded work, and the shared host’s driver, disk, maintenance and failure domain are acceptable. It can simplify service routing and avoid a second host, but it does not remove internal network controls or prove that the chosen device can serve all processes concurrently.

Check overlapping peaks, not just each service’s idle value. Inference may reserve device memory or allocate KV cache as context and concurrency change; embedding batches can coincide with a model request; vector search can use cached structures while writing persistent data. System RAM, VRAM, process allocation, page cache, artifact bytes and free disk are different fields. Record observations by process and host over the same window. Do not sum mutually exclusive alternatives, and do not infer the actual fit from a parameter count, a quantization label or an advertised host tier.

The main operational cost is concentration: host maintenance or disk pressure can affect both the orchestrator and resident service; a device driver or filesystem change may touch several processes; and a single recovery owner may need to reconcile service and data state. Determine whether n8n can remain useful when AI is unavailable, whether AI can be safely paused during host maintenance, and which state must be recovered first. Those answers come from the chosen design and operator, not from the phrase “same VPS.”

Split hosts

A separate AI/data host may fit when observed resource peaks, device isolation, change schedules or recovery boundaries justify a second machine and a controlled private path. It can separate host-level maintenance and allocation, but a second host does not automatically create high availability: there may be one AI endpoint, one data copy, shared credentials, a shared network dependency or no tested cutover. It also does not guarantee lower latency. The route, distance, DNS, TLS/authentication, return path and failure behavior have to be selected and observed.

Account for another host’s recurring floor, storage, device or software requirements, monitoring, patching, backup, address/network work and operator time. Add cross-host requests and data transfers to the cost intake. Determine what leaves the orchestration host: prompts, source text, vectors, outputs, logs or snapshots. Keep data minimization, encryption and access control with the named owners. Split placement can improve one selected isolation boundary while increasing the number of places that must be secured and restored.

Choose a split design only after identifying private routing and DNS ownership, who provisions and rotates service credentials, who monitors both ends, and how a caller behaves when the AI endpoint is unavailable. If the candidate depends on an unreviewed public listener or unknown provider terms, pause. Article 8 owns detailed network binding and reachability; this page does not prescribe a public bind or firewall change.

Optional components

Make a selection register so mutually exclusive choices stay mutually exclusive:

Only selected components flow into the next cost and recovery worksheets. A remote API and local model are not both counted unless both are actually used. Likewise, do not total same-box and split-host candidates as if they were one architecture. “Unknown” remains an open field until a source or observation resolves it.

Run a bounded placement decision

This is a proposed observation plan, not a report of a test. Use an environment you are authorized to inspect, a maintenance window, a named operator and a way to hold new work. Do not activate a new service until its exact version, state path, network route, resource threshold and rollback point are known. If the system already has unexplained errors or uncertain state, resolve that before adding a variable.

1. Set the scope and stop owner. Record host identity, OS/architecture, exact n8n and resident-service tags, runtime build, model revision and Qdrant version where selected. Name the operator who can pause the bounded workload and the person authorized to restore state. Mark each topology candidate, including rejected alternatives.
2. Define a representative window. Choose one known, bounded workload, input cap, concurrency cap and duration based on the actual intended use. Record ordinary and peak periods separately. Do not invent a “typical” request or use unlimited retries. Set operator-chosen stop thresholds for memory, VRAM, free disk, error rate, queue/backlog and response acceptance before observing.
3. Capture the baseline. Before adding a service, record timestamp, CPU, host and relevant process/container memory, VRAM if present, disk use/free-space floor, network bytes if available, service errors and restarts. Record how each value was obtained and what it covers. Use the existing host’s approved monitoring and read-only inventory; do not print environment variables, credentials or full secret-bearing configuration. Capture n8n-side baseline indicators through its existing owner and tooling rather than attributing its internal behavior to this article.
4. Verify the route and state boundary. Document each caller’s vantage point, resolved name, destination scope, process bind, port publication, firewall owner and return path. Confirm that only the intended caller is allowed under the approved network plan. Inventory mount names and paths without changing them; note model, cache, corpus, index, snapshot and temporary locations. Do not probe an unauthorized address or expose a service to make a test convenient.
5. Add one selected service at a time. Follow the operator’s separately reviewed change procedure for the exact environment. Start with one resident service and a bounded, harmless workload; wait through the predefined observation window; record CPU, RAM, VRAM, disk growth, network movement, service errors, retries and any host pressure. The vector service, model runtime, embedder and reranker are separate additions. Do not combine all optional components during first acceptance.
6. Compare and decide. Compare the same fields and time window against baseline. Note peak and duration, concurrent work, failures, restarts and missing observations. A short observation cannot prove future capacity; mark workload growth, longer context, restore peak and production concurrency as unresolved until separately bounded. Accept only if the named owner agrees that thresholds, data coverage, route and recovery responsibilities were met.

Rollback and recovery receipt

Before any separately authorized change, record a known-good configuration reference, verified recovery point, state consistency owner and the procedure that would reverse only the newly selected service or route. Roll back only if the responsible operator confirms it is safe for in-flight work and data. Restore the prior route/configuration, then have the owner check the baseline service and expected state. These are planning gates; this article has not executed or verified a rollback or restore. If the recovery point is uncertain, keep work held and follow the selected service’s recovery plan.

Complete a receipt even when the result is “not accepted”:

An accepted receipt applies only to the versions, workload, observation window and controls recorded. It does not establish an availability target, general capacity, guaranteed latency, future growth, or an automatic failover path.

Cost and ownership handoff

Send a selected architecture ledger to Article 2, the only page in this cluster that totals Local AI costs. Include each chosen host once, its billing period and verified rate source, provisioned storage, model/runtime/cache files, Qdrant/source data, temporary and recovery space, snapshots and independent copies, initial and repeated pulls, client/API traffic and split-host transfer. Keep one-time and recurring quantities distinct. Unknown price, transfer treatment, included allowance and tax remain unknown; no missing amount is zero by implication.

Pass host architecture, CPU/GPU requirement evidence, OS and device/driver questions to Article 3. Send exact model files and separate memory observations to Article 4, runtime and build questions to Article 5, and Qdrant structure, snapshot and restore quantities to Article 6. For endpoint bind and caller verification, use Article 8; for stop, retention, deletion and repull states, use Article 9. Return to the Local AI selection guide if the workload or selected component set is still uncertain.

Keep owner fields explicit: host operator; runtime maintainer; data custodian; network/DNS owner; backup and recovery operator; and person who accepts the bounded workload. One individual may hold several roles, but list each responsibility and access path. Decide who receives the completed cost and network handoffs and who can stop or resume service. Cross-host architecture adds coordination among owners even when one person fills them all.

Evidence and updates

Source captures checked 2026-11-06. The topology descriptions below are bounded to the captured documentation; verify platform, release, build and network behavior for the selected environment before acting. This page makes no n8n release or workflow-execution claim.

• Ollama FAQ — bind, model paths, scheduling and configuration fields; defaults are release-sensitive.
• Ollama Docker documentation — container and model-volume example, not proof of host hardware compatibility.
• vLLM optimization documentation — concurrency, cache and profiling considerations; confirm the selected version and build.
• vLLM metrics documentation — possible runtime observations; metric behavior and exposure need version and network review.
• vLLM OpenAI-compatible server — endpoint and authentication scope; API compatibility is not complete feature parity or a security guarantee.
• llama.cpp README at captured commit, build guide and server README — immutable source snapshot, not a stable-release guarantee.
• Qdrant storage, memory tiers and snapshots — persistent structures, per-structure cache choices and snapshot scope; check the selected version and recovery requirements.
• Qdrant security and monitoring — captured self-hosted configuration and observation topics; confirm current controls before deployment.
• Docker bridge network documentation and Docker packet filtering and firewalls — network and host firewall interaction. Consult the captured n8n Ollama connectivity guide only for caller-topology context; confirm n8n-specific guidance on its owner page.

Recheck the selected n8n version on its own documentation page and selected model/runtime/vector-service versions before using this worksheet. L06 and L07 are local overlap references for ownership and caller context, not current release or deployment evidence. The map and runbook are planning aids; no host, model, route, benchmark, recovery or deployment was operated for this article. See Methodology for evidence boundaries.