AI & ML / Agents & orchestration / 20_n8n_and_low_code_automation.md

n8n and low-code automation

Updated 6 interview angles 4 min read source
On this page7
  1. What it actually is
  2. Where the boundary belongs
  3. Scaling: queue mode
  4. Against the alternatives
  5. The AI nodes
  6. Related
  7. Interview angle

n8n and low-code automation

Named in a growing share of AI-engineer ads, and the question is never “can you drag nodes”. It is where the boundary sits between a visual workflow and your Python services — because a team that puts business logic in n8n discovers it has an unversioned, untestable production system.

Verified 2026-08

Verified 2026-08. Self-hosted n8n under the Sustainable Use License — source-available, not OSI open source, the same shape as the Redis and Terraform stories in Valkey.

What it actually is

A node-based workflow runner: a trigger starts an execution, data flows through nodes as an array of items, and each node runs once per item unless told otherwise.

Node kind Examples
Trigger webhook, schedule, app event, chat
Action HTTP Request, Postgres, Slack, 400+ integrations
Logic IF, Switch, Merge, Loop Over Items
Code JavaScript, or Python via Pyodide
AI Agent, vector store, model, memory nodes

The item-array model is the thing that surprises people. A node returning five items causes every downstream node to run five times, which is convenient until an HTTP node quietly makes five hundred calls.

Where the boundary belongs

The defensible architecture, and the answer to the interview question:

text 
n8n            your service
────           ────────────
trigger   ──▶  POST /api/jobs      (one call, typed contract)
               ├─ validation
               ├─ business rules
               └─ persistence
          ◀──  webhook callback

n8n owns the glue: triggers, connectors, retries, human notification. Your code owns anything with a rule in it. That keeps the logic in a repository with tests, review and rollback, and keeps n8n doing the part it is genuinely good at — the forty integrations you did not want to write.

The failure mode is the opposite arrangement: pricing logic in a Code node, conditionals in an IF node, and a JSON export nobody can diff.

Gotcha: n8n workflows are JSON blobs in a database, not files in git. Version control means exporting deliberately. A workflow edited in production at 4pm has no diff, no reviewer and no rollback unless you built that yourself.

Scaling: queue mode

The default runs everything in one process. Production uses queue mode — Redis in the middle, workers pulled out:

yaml 
# docker-compose.yml, the shape that matters
services:
  # UI, webhooks, scheduling
  n8n-main:
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      # never SQLite in production
      DB_TYPE: postgresdb
  n8n-worker:
    command: worker
    deploy: { replicas: 4 }     # scale this, not main
  redis:
  postgres:

Three operational facts worth stating:

  • Postgres, not SQLite. The default SQLite store does not survive concurrency or a container restart on ephemeral disk.
  • Prune execution data. Every execution stores its full payload; EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE exist because the table otherwise grows until the disk fills. This is the most common self-hosted n8n outage.
  • Multi-main needs an Enterprise licence. One main process is a single point of failure for webhooks and schedules on the community edition.

Against the alternatives

Tool Owns
n8n integrations and glue, visually
Celery background tasks in your codebase
Temporal durable, long-running, code-defined workflows
Airflow scheduled data pipelines, code-first
Zapier / Make the same job, SaaS-only

The distinction interviewers listen for: n8n is an integration tool that can orchestrate; Temporal is an orchestration engine with no integrations. If the workflow’s value is “connect Slack to Postgres to an LLM”, n8n wins on time. If its value is “this must survive a week and a deploy with exactly-once semantics”, that is What is Temporal?.

The AI nodes

n8n ships LangChain-backed Agent, vector-store, model and memory nodes, which makes it a fast way to demo an agent. The limits arrive quickly: prompt and tool definitions live in the canvas rather than in versioned files, evaluation is manual, and observability stops at the execution log.

The honest position: prototype an agent in n8n, own it in code once it matters — the same argument as The agent framework landscape makes about frameworks, and for the same reason. What is not portable is the evaluation suite and the tool contracts.

Interview angle 6

  • “What is n8n and where would you use it?” - a node-based workflow runner for integration glue: triggers, connectors, retries and notification. Use it for the forty integrations you did not want to write, and keep anything with a business rule in a repository with tests.
  • “What’s the risk of putting logic in n8n?” - workflows are JSON in a database, not files in git. No diff, no review, no rollback, and no unit tests. A pricing rule edited in the canvas at 4pm is a production change nobody can reconstruct.
  • “How do you scale a self-hosted n8n?” - queue mode: Redis between a main process and worker replicas, with Postgres as the store rather than the default SQLite. Scale workers, not main; multi-main needs an Enterprise licence.
  • “What breaks a self-hosted n8n first?” - execution data. Every run stores its payload, so the table grows until the disk fills. Set the pruning variables on day one.
  • “n8n or Temporal?” - n8n is an integration tool that can orchestrate; Temporal is an orchestration engine with no integrations. Choose by which half is the hard part — connectors, or durability across a week and a deploy.
  • “Would you build an AI agent in n8n?” - to prototype, yes; the LangChain-backed nodes are quick. To own it, no: prompts and tool definitions live in the canvas rather than versioned files, and evaluation is manual.
Previous
The Claude Agent SDK