n8n vs Zapier vs LangChain is usually framed as three competing tools. Two of them own retries, scheduling and state; the third owns none of it, and that difference decides your architecture.
Clients ask us which of the three to standardise on, as if they're bidding for the same slot on the org chart. They aren't. Zapier and n8n are hosted execution platforms: they own the trigger, the schedule, the retry, the credential vault, and the record of what ran at 04:12 last Tuesday. LangChain is a library you import. It owns nothing until you give it a process to live in, a queue to retry from, and a database to put its state in. Comparing them straight across is like comparing a warehouse to a forklift.
The useful question isn't which is better, it's which layer owns durability. Every automation that matters — invoice ingestion, lead enrichment, ticket triage with an LLM in the loop — eventually fails halfway through. Something has to know that step 4 of 9 blew up, hold the payload, and resume without double-charging a customer. That component is your spine, and picking it first makes every other decision cheap. Pick it last and you end up with a LangGraph agent running inside a Zapier Code step with a ten-minute ceiling and no idea what it did.
Zapier's real asset is roughly eight thousand maintained integrations and the OAuth refresh logic behind them. When HubSpot rotates a scope or Xero changes a field, someone at Zapier fixes it and you never find out. That is genuinely worth money, and for ops teams wiring form-to-CRM-to-Slack it's the correct answer — no infrastructure, no on-call, business users can read the Zap. Billing is per task, meaning per action step, which is fine at a few thousand a month and brutal at a few hundred thousand.
It stops being the right answer the moment your logic gets shape. Fan-out over a list, loop until a condition holds, run three branches and merge the results — these are either awkward or absent. Code steps are sandboxed with short runtimes and no persistent filesystem, so anything that takes minutes has to be pushed elsewhere anyway. And the version control story is a screenshot. If two people edit a Zap, the second one wins and nobody gets a diff.
Self-hosted n8n gets interesting when you run it in queue mode: main process for the editor and webhooks, Redis as the job broker, a pool of worker containers doing the actual execution, Postgres holding workflows, credentials and the execution log. Now a worker can die mid-run and the job comes back. You can scale workers independently of the UI, pin concurrency per queue, and replay a failed execution with its original payload instead of asking the client to resend the file. That replay capability is the single feature that separates a toy from a production system, and it's why we default to n8n as the outer layer for B2B work.
Two things bite. First, the execution log is written to Postgres on every run, binary payloads included, and it will eat your disk inside a month if you don't set data pruning and push binaries to S3-compatible storage instead of the database. Second, workflows are stored as JSON with node coordinates baked in, so a git diff is unreadable noise — moving a node two pixels looks like a change. We keep the automation logic thin inside n8n and put anything worth reviewing into real code, so the diff lands somewhere a human can actually read it.
Where LangChain and LangGraph earn their place is the messy middle of an LLM task: tool loops, retrieval chains, structured output parsing, an agent that decides how many steps it needs. Drawing that as boxes and arrows in a visual editor is miserable — a while-loop with a token budget doesn't render as a flowchart, and debugging it through a canvas is worse than reading a stack trace. LangGraph's checkpointers give you durable agent state in Postgres or SQLite, which is the closest the library gets to owning reliability, and it's real. But it still needs a process manager, a deployment target, and something upstream that decides when to call it.
So don't run it upstream. We ship it as a small FastAPI service in its own container with one endpoint, a request schema, an idempotency key, and a hard timeout. n8n calls it over HTTP like any other API. If the model provider rate-limits or the agent loops, the service returns a typed error and n8n's retry policy decides what happens next — the failure is visible in the execution log rather than buried in a node's stdout. The version of that service is a git SHA, it has unit tests with recorded fixtures instead of live model calls, and rolling it back doesn't touch a single workflow.
If your volume is low, your logic is linear, and the value is entirely in the connectors, use Zapier and spend the saved engineering time elsewhere. If you have branching, loops, meaningful volume, data that can't leave your VPC, or a per-task bill that's climbing faster than revenue, self-host n8n in queue mode and treat it as infrastructure — backups, monitoring, a staging instance, the lot. If the hard part is an LLM making decisions across several tool calls, write it in LangGraph or the provider SDK directly and expose it as a service. Most of our production systems use exactly two of the three, and the pair is almost always n8n plus code.
The tell for a bad architecture is simple: ask where the exception path lives. If the answer is that someone checks a Slack channel each morning, you don't have automation, you have a cron job with witnesses. Put the retry, the dead-letter queue and the replay button in one layer, keep the reasoning in another, and the tooling argument mostly dissolves.
A software studio that ships and maintains its own products — KeepChats, Gwora and Cairn — and builds the same way for clients. Founded and led by codewithumar.
Talk to the studio →Send the problem. You get one fixed number and a plan back within a business day.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar