A team may choose self-hosted n8n because it wants more control over the workflow environment. That choice can be useful, but it does not make a cloud-model request local. Customer text may leave the workflow host for the model, enter a storage service and then move into a connected business system.
This article proposes a hosting decision brief that maps those movements and responsibilities. It does not select a deployment for a particular organisation or change any system. The goal is an accurate account of where processing occurs and what the team must operate.
Define which component you want to control
Separate the workflow engine, database, queue, binary storage, model endpoint and connected applications. Self-hosting one component does not determine the others' locations, access or retention. A server address tells you where that server runs, not where its outbound requests are processed.
Write the reason for considering self-hosting in concrete terms: operational control, approved network paths, integration requirements or another owner-defined need. Avoid a broad claim that it provides complete privacy. The actual arrangement needs evidence for every relevant transfer and stored copy.
Also define the workflow boundary. A document-intake process may include an upload form outside n8n, preprocessing in a separate service and staff exports after completion. Include those stages in the map rather than starting the diagram only when n8n receives its first event.
Inspect the queue and storage architecture
n8n's queue-mode documentation describes a main instance, Redis, workers and a database, with workers executing jobs and recording outcomes. It also says queue mode does not support binary-data persistence in filesystem storage and discusses external S3 storage for that need. Those components create separate operating and data-handling questions. Source: n8n queue mode
Verify the actual selected configuration and feature availability. Do not infer that a self-hosted worker uses local file storage for every attachment or that all editions expose identical options. Record database, Redis and binary-storage locations, access paths, backups and responsible owners.
Credentials and configuration also need ownership. The documentation explains that relevant workers require the shared encryption key to access stored credentials. Keep the actual secret values out of planning documents and logs; the brief records who manages the configuration and how access is controlled, not the secrets themselves.
Hosting and data-transfer decision brief
Use this complete proposed brief for a fictional document-summary workflow. Locations shown as to be verified are explicit evidence gaps, not assumed answers.
| Stage | Data and destination to establish | Operational owner | Evidence or hold question |
|---|---|---|---|
| Upload intake | Original document, form metadata and intake store | Application owner | Where does the upload arrive before n8n, and who can access it? |
| n8n main and workers | Workflow inputs, execution state and permitted credentials | Workflow operator | Verified host locations, network paths, role access and selected version |
| Database and Redis | Stored execution records, queued work and state | Infrastructure owner | Actual retention, access, backup and recovery arrangements |
| Binary storage | Documents or attachments required by the workflow | Storage owner | Confirm selected storage mode and location; do not assume filesystem persistence in queue mode |
| Cloud AI request | Approved text, images or files sent to the selected endpoint | AI integration and information owners | Exact provider, endpoint, processing arrangement and necessary input fields |
| Model output | Extracted fields or summary and provider-associated state | Integration owner | Where is output stored, who reviews it and what provider controls apply? |
| Connected business system | Approved resulting record, proposal or message | Business-system owner | Destination permissions, action approval and verified outcome |
| Logs, backups and exports | Error traces, saved executions, source copies and staff downloads | Respective system owners | Necessary content, access, retention and deletion behaviour |
Decision record: compare the current hosted arrangement and proposed self-hosted arrangement stage by stage. State which locations change, which remain external and which responsibilities move to the team. Record unresolved locations, feature constraints and required approvals. Do not label the proposed workflow wholly local if its model or storage path remains external.
Operating responsibilities: updates, configuration review, monitoring, backup restoration, worker recovery, capacity and credential handling need named owners. Evaluate whether those responsibilities can be met under the organisation's actual constraints, rather than treating server installation as the end of the decision.
Acceptance fixtures: send only invented test documents through an authorised future pilot; inspect the actual destinations and stored copies; test a failed model request, worker restart, missing attachment and recovery from the approved backup process. Record observed transfer and recovery evidence. This article does not claim those tests have been run.
The brief is ready when every stage has an established location or explicit gap, a responsible owner and the required handling decision. Choosing self-hosting is a separate owner decision based on this evidence, not a conclusion inferred from a diagram.
Review cloud-model handling separately
OpenAI's data-controls guide distinguishes abuse-monitoring logs and application state, including endpoint-specific conditions and feature exceptions. If the workflow uses OpenAI, review its actual endpoint and account controls. Self-hosting n8n does not determine those provider records or make all requests non-retained. Source: OpenAI data controls
For another provider, obtain that provider's current evidence rather than applying OpenAI settings by analogy. Record local copies separately too. A provider deletion capability does not remove a saved n8n execution, backup or exported summary automatically.
Minimise inputs according to the approved task where practical. A summary may not need every attachment or personal field. That reduces unnecessary transfer, but does not settle the organisation's legal or confidentiality requirements; the responsible owners make those decisions.
Work through normal, missing and duplicate processing paths
In a hypothetical normal case, the self-hosted worker receives an invented document, sends the approved text to a configured cloud model and stores a reviewed output in the selected business system. The map accurately describes the external request despite the local workflow host.
In a missing-location case, the team knows where n8n runs but cannot identify its binary-storage or backup destination. The brief leaves those gaps open and holds the locality claim. It does not assume local storage because no one remembers configuring an external service.
In a duplicate-copy case, the original exists in upload storage, execution data and a staff export. These are separate copies even if they share content. The handling plan identifies their owners and deletion or access behaviour rather than assuming one action controls them all.
Distinguish requested integration actions from actual transfers
OpenAI's function-calling guide describes model requests followed by application execution and returned output. That distinction helps map the connected-system stage: a model proposing a tool does not prove the action occurred, while the application request itself may transfer data externally. Source: OpenAI function calling
Record actual adapter destinations and operation outcomes in the proposed verification. If an operation times out, investigate what reached the destination before retrying. A self-hosted orchestration layer does not eliminate uncertain external effects.
FAQ about self-hosted n8n and cloud AI
Does self-hosting mean documents never leave our infrastructure?
Not if the workflow sends content to a cloud model or other external service. Map and verify each transfer. Hosting location alone does not establish complete processing locality.
Can we ignore backups and logs when comparing hosting options?
No. They may contain inputs, outputs or identifying metadata, and they have their own access and handling responsibilities. Include them in the decision brief.
What should decide between hosted and self-hosted orchestration?
The verified component map, required controls, integration needs and ability to operate the chosen arrangement. The article provides that comparison record rather than assuming one option is appropriate for every team.
If your business needs help defining this process, explore Workflow automation, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.