Joshua Opolko

Self-Hosting n8n for LangChain AI Workflows: A Deployment Evaluation

By Joshua Opolko · Published July 4, 2026

Short version: n8n's AI features are LangChain. The AI Agent node, chain nodes, memory, and vector store integrations are built on LangChain.js and ship with every self-hosted instance, so self-hosting n8n gives a company a visual LangChain runtime plus 500-odd business integrations, free under the sustainable-use license for internal use. It evaluates well when AI is one step inside broader automations, and poorly when the AI pipeline is the product; that's Flowise, Langflow, or Dify territory. Production means Postgres, queue mode with Redis workers, a pinned encryption key, and keeping model traffic on your own infrastructure via Ollama or a LiteLLM proxy.

Key takeaways

What "n8n plus LangChain" actually means

Companies evaluating this pairing often assume they'll be gluing two systems together. They won't: LangChain is already inside n8n. The advanced AI nodes that shipped with n8n 1.x (AI Agent, the LLM chain nodes, conversation memory, output parsers, vector store and embeddings integrations) are implemented on LangChain.js and delivered through n8n's bundled LangChain node package. When you drag an AI Agent node onto the canvas and wire a model, memory, and tools into it, you are composing a LangChain agent visually.

Two consequences follow. First, the evaluation question is not "can n8n talk to LangChain" but "is a visual LangChain runtime with a giant integration catalogue the right shape for our AI workloads." Second, the ceiling is higher than the canvas suggests: the LangChain Code node lets you write LangChain.js directly inside a workflow, importing the same primitives the visual nodes use, so complex custom chains don't force you out of the platform on day one.

The four things to evaluate before committing

1. Licensing

n8n is not OSI open source; it ships under a sustainable-use license. For the standard company case (self-hosting n8n to automate your own business, including AI workflows for internal teams) it is free with unlimited workflows and executions. What it forbids is reselling n8n itself as a hosted service. What it gates behind the paid enterprise tier: SSO/SAML, LDAP, multiple environments with Git-based deployment, log streaming, and external secrets integration. If your security team requires SSO on every internal tool, price that in before the pilot, not after.

2. Deployment architecture

The evaluation instance and the production instance are different animals:

StageShapeNotes
EvaluationSingle Docker container, SQLiteUp in ten minutes; fine for a two-week pilot
Small productionSingle container + PostgresThe minimum for anything a team depends on
Scaled productionQueue mode: main + Redis + N workers + PostgresWebhook processors and workers scale horizontally; survives spiky load

Non-negotiables at production: pin N8N_ENCRYPTION_KEY as a managed secret (it encrypts every stored credential; lose it and every credential is unrecoverable), terminate HTTPS at a reverse proxy, and back up Postgres together with that key. The full container setup, reverse proxy config, and upgrade discipline are covered step by step in the main n8n self-hosting guide.

3. Data privacy, the actual reason companies self-host

Self-hosting n8n keeps workflow data, credentials, and execution logs on your infrastructure. But an AI workflow leaks by default in a different place: the model call. An AI Agent node pointed at a cloud API ships your prompts, and whatever workflow data you templated into them, to that provider. The self-hosted answer has two tiers:

This split (orchestrator private, model traffic governed) is the architecture most evaluations converge on, and it is the same pattern I run in production for an LLM-as-ETL pipeline.

4. Where the canvas ends

Visual workflows are the selling point and the trap. Straightforward agent patterns (a tool-using agent over a vector store, a classification chain, a summarize-and-route flow) build in an afternoon and stay legible. Deeply custom logic (multi-agent orchestration, elaborate retrieval strategies, custom reranking) turns into node spaghetti. The honest evaluation criterion: if more than roughly a third of your planned AI logic needs the LangChain Code node, the visual layer is costing you more than it gives, and a code-first stack or a purpose-built tool fits better.

Sizing: what the hardware evaluation misses

Teams consistently overspec n8n and underspec everything around it. n8n itself is a Node.js orchestrator: 2-4 vCPUs and 4-8 GB RAM runs a serious company instance, and queue-mode workers scale out rather than up. AI workflows barely change that, because the heavy compute happens wherever the model runs. What actually needs sizing:

n8n vs the purpose-built LangChain tools

ToolBuilt forChoose it when
n8nBusiness automation with AI steps insideThe workflow touches email, CRMs, sheets, webhooks, databases, and an LLM; one platform should own all of it
FlowiseVisual LangChain app builderThe AI pipeline is the product (chatbot, RAG app) and you want LangChain-native control
LangflowVisual LangChain (Python) prototypingPython-first team iterating on chain and agent designs before productionizing
DifyIntegrated LLM-app platformYou want RAG, app hosting, and observability in one self-hosted box; see the Dify guide
LangChain in codeFull controlEngineering team, complex agents, CI/CD; the visual layer would only be in the way

The pattern in real deployments: companies run n8n and one of the others, with n8n owning the business-facing automations and calling the specialized AI service over HTTP when a pipeline outgrows the canvas. That is a feature of the architecture, not a failure of the evaluation. For n8n against general-purpose workflow rivals, see n8n vs Windmill.

A two-week evaluation plan that actually answers the question

  1. Days 1-2: single-container n8n with Postgres, behind your reverse proxy. Wire one model provider through LiteLLM even in the pilot, so the governance story gets tested, not assumed.
  2. Days 3-7: build the two workflows you actually plan to run, not demos. One business automation with an AI step (classify, extract, summarize), one agent with a tool and memory. Have the intended maintainers build them, not the strongest engineer.
  3. Days 8-10: break things. Kill the container mid-execution, restore Postgres from backup, rotate a credential, upgrade the n8n version. The operational story is the evaluation.
  4. Days 11-14: decide against the four gates above: license fit, architecture fit, privacy posture, canvas ceiling. If more than one gate is uncomfortable, run the comparison table before committing.

Frequently asked questions

Does self-hosted n8n actually use LangChain?

Yes. The AI Agent node, chain nodes, memory, output parsers, and vector store integrations are built on LangChain.js and ship with every self-hosted n8n instance via the bundled LangChain node package. The LangChain Code node additionally exposes the underlying primitives for custom chains, so the visual nodes are a starting point rather than a ceiling.

Is self-hosted n8n free for company use?

Yes for internal business automation, under n8n's sustainable-use license, with unlimited workflows and executions. You cannot resell n8n itself as a service, and enterprise features (SSO/SAML, LDAP, environments, log streaming, external secrets) require the paid tier. If SSO is mandatory for internal tools at your company, include that cost in the evaluation.

What does a production self-hosted n8n deployment look like?

Postgres instead of SQLite, queue mode with Redis and worker containers for scale, a pinned N8N_ENCRYPTION_KEY stored as a managed secret, HTTPS at a reverse proxy, execution-data pruning configured, and backups covering both the database and the encryption key. n8n itself runs comfortably on 2-4 vCPUs and 4-8 GB RAM; model hosting and vector stores are sized separately.

Can n8n AI workflows run fully on-premise with no cloud model calls?

Yes. Point the model nodes at Ollama running on your own hardware, or route through a self-hosted LiteLLM proxy when you need multiple providers behind one governed, OpenAI-compatible endpoint. The orchestrator, credentials, execution data, and model traffic then all stay on infrastructure you control.

When is n8n the wrong choice for LangChain workloads?

When the AI pipeline is the product rather than a step in a business process, when most planned logic would live in the LangChain Code node anyway, or when an engineering team wants CI/CD-managed code rather than visual workflows. Flowise, Langflow, Dify, or plain LangChain in code fit those cases better, and hybrid deployments (n8n calling a specialized AI service) are common and sane.

Written by Joshua Opolko. I self-host n8n alongside Ollama, LiteLLM, and Dify, and run a production LLM pipeline (Claude Haiku classification and web-search verification) that powers a public directory site. License terms and enterprise feature gating are as published by n8n and verified July 2026; confirm current terms with n8n before purchase decisions.