What n8n actually is
n8n is a node-based workflow automation tool built in Node.js, distributed under a fair-code license that lets you self-host the entire stack or use their managed cloud. At its core it is a directed graph engine wrapped in a web UI. Each node represents an action like calling an API, transforming data, branching on a condition, or invoking a language model. Wires between nodes carry JSON payloads forward.
The technical picture matters because the marketing tends to flatten it. n8n is not a Zapier clone with extra steps. It is closer to a lightweight version of Airflow or Temporal that ships with a few hundred prebuilt integrations and a node editor. You can drop into code nodes and write JavaScript or Python directly, which is the first hint that it is aimed at builders rather than non-technical operators.
For AI specifically, n8n maintains first-party LangChain nodes covering chat models, embeddings, document loaders, vector stores, agents, and tools. You can wire an LLM call into the same graph as a Postgres query, an HTTP request, and a conditional branch without leaving the editor. The current version of the AI nodes exposes structured output parsing, tool calling, and memory primitives, which is enough to build agentic loops without writing a custom framework.
The practical difference between n8n and pure code is the speed of iteration. You can stand up a working AI pipeline in minutes, then harden it once the shape is right.
Setup and authentication
The fastest path to a working instance is Docker. A minimal compose file mounts a volume for SQLite or Postgres, exposes port 5678, and starts the service. If you want production-grade persistence, swap the SQLite default for Postgres by setting the corresponding database environment variables and adding a service to compose. n8n ships with a setup wizard that walks you through creating the owner account on first run.
For local development without containers, you can install via npm with a single command and run the CLI. The npm path is fine for prototyping on a laptop but expect to move to Docker or a hosted box once you start sharing workflows with teammates or wiring real credentials.
Authentication in n8n happens at two layers. The first is the user account for the editor itself, which you set up through the wizard. The second is per-node credentials, which you store encrypted in the n8n database. Each integration like OpenAI, Slack, Notion, or Google Sheets has a credential type that holds the API key, OAuth tokens, or connection string. Credentials are scoped to your user and can be shared across workflows but never appear in workflow JSON exports, which makes it safe to commit workflow files to git.
OAuth2 flows run inside the editor. For services like Google or Microsoft, you register an OAuth app in their console, paste the client ID and secret into n8n, and complete the consent flow once. After that the tokens refresh automatically. For simple API key integrations, you paste the key into a credential record and reference it from the node.
One practical tip: create separate credentials for development and production by using different projects in the upstream service. OpenAI in particular lets you create multiple keys with separate billing and rate limits, which is the cleanest way to keep sandbox experiments from contaminating your production bill.
First working example
Here is a complete workflow you can build in under ten minutes. The goal is to accept a message from a webhook, send it to an LLM with a system prompt, and post the response to a Slack channel. The shape is generic enough to swap Slack for any output node.
Step one, create a new workflow and add a Webhook node. Set the HTTP method to POST and copy the generated test URL. The webhook fires whenever any service POSTs JSON to that endpoint.
Step two, add an Edit Fields node right after the webhook. Map the incoming body field into a clean field called userMessage. This step is small but it pays off because the rest of the graph now operates on a predictable shape regardless of what the upstream caller sent.
Step three, add the Basic LLM Chain node or AI Agent node from the LangChain section. Connect your OpenAI credential, set the model to something in the current generation like gpt-4o-mini for cost, and write a system prompt that frames the assistant as, for example, a customer support triage agent. Reference the userMessage field from step two in the user prompt using n8n’s expression syntax, which looks like {{ $json.userMessage }}.
Step four, add a Slack node at the end. Pick the post message action, choose your credential, select a channel, and map the LLM output into the message text field. Most chat model nodes expose the response under a field the editor auto-suggests when you click the expression pill.
Save the workflow and toggle it to Active. Hit the test webhook URL with curl, something like curl -X POST
If the workflow fails, open the Executions tab on the left rail. Each run shows the data at every node, which lets you pinpoint where the chain broke without adding logging code.
Key settings that matter
The settings most people ignore are the ones that hurt the most in production. Start with the workflow-level settings panel, accessible from the gear icon in the top right of the editor.
Save execution progress controls how much state n8n persists after a run. Leaving it on for every workflow is the default but it can balloon storage. For noisy workflows you can switch to Save manual executions only, which keeps storage lean while still letting you debug on demand.
Error workflow is the most underused feature in the platform. Every workflow can point to a fallback workflow that runs on failure. Wire a fallback that posts to a dead-letter channel in Slack, sends a PagerDuty alert, or writes to a log table. The cost of setting this up is ten minutes and it pays back the first time a vendor changes an API.
Retry on fail is the dial next to error handling. Set it to true and pick a max retry count and a wait between attempts. Transient failures from LLM providers are common at typical rate-limit tiers, so a retry of three with a five-second wait resolves most flakiness without code.
Timezone matters more than you would guess. Workflows run on a schedule using the instance timezone, which defaults to the server clock. If your server runs in UTC and your team is in Sydney, a daily 9am trigger fires at 7pm local