n8n: Automation Patterns
n8n: Open Automation Engineers and Teams Can Trust
n8n is a workflow automation tool that connects APIs, databases, and services. Think Zapier, but open source and way more flexible.
Engineers skip the integration busywork and leaders get visibility into what’s running. Marketing can build their own automations without filing a ticket.
I’ll walk through the core ideas, show you what actually works in production, and build a real example from scratch.
What n8n Is (and Is Not)
n8n uses a visual node editor. Each node does something: fetch from an API, transform data, send a webhook. You wire them together.
Need custom logic? Drop in JavaScript. Want to run it on your laptop? Fine. Kubernetes? Also fine. Everything’s transparent—you can see executions, inspect payloads, trace what failed.
It’s not great for heavy ETL jobs or anything that needs serious compute. And yes, it’s designed for RPA-style tasks, but the good kind where you actually control the workflow code, not fragile screen recordings that break when someone updates a button.
Why It Matters for Engineers, Leaders, Founders, Marketers
If you’re an engineer, stop writing throwaway scripts to sync data between Salesforce and your database. Build it once in n8n, version it, and move on. You get retries, auth management, and error handling for free.
Tech leaders — your backlog has 20 “sync X to Y” tickets. Give your team a platform where they can build these themselves safely. You own the code. No vendor lock-in. And you can actually see what automations are running.
Marketers get something out of this too. Need to route hot leads to Slack? Enrich contacts from Clearbit? Trigger email sequences when someone downloads a whitepaper? Build it yourself instead of waiting two sprints for engineering.
You’ll still need guardrails (more on that later), but scoped credentials and templates make this safer than you’d think.
Core Concepts
Triggers start workflows. Could be a schedule, a webhook, a new file in S3, whatever.
Nodes are the building blocks — one node, one job. Fetch from an API. Transform JSON. Send to Slack. Branch on a condition.
Credentials stay separate from workflows. You reference them by name, and when someone leaves you revoke their creds without touching 50 workflows.
Each trigger fires an execution that processes items through your graph. If your trigger returns 100 new leads, n8n runs the workflow for each one (or in batches, depending on how you configure it).
Mapping connects data between nodes with expressions. Usually point-and-click, but you can write JavaScript when the mapping gets weird.
Error handling is built in. Retry with backoff, route failures to a dead-letter queue, send alerts when things break.
What Works in Production
I’ve seen workflows break in creative ways. Here’s what actually prevents fires.
Make every workflow idempotent. Use external IDs and upserts — if your workflow runs twice, nothing breaks. Add retries with exponential backoff so you don’t hammer a service that’s already struggling. And paginate. Don’t pull 10,000 records in one request.
Data contracts matter more than people think. Define what shape data should be at each step and validate early. I’ve debugged too many workflows where garbage data made it halfway through before exploding.
Scope credentials per workflow or team. Rotate them. You don’t want one leaked Slack token to expose everything.
Export workflows as JSON and review changes in Git. Tag releases. This saved me when someone accidentally broke the production lead-routing workflow at 4 PM on Friday.
The ops side matters just as much:
- Separate environments (dev, staging, prod) with parameterized URLs and credentials
- Metrics: throughput, success rate, latency, errors — when something breaks at 2 AM, you want to know which workflow and which step
- Alerting with context: “Salesforce sync failed: 401 Unauthorized” gets you moving, “Workflow failed” doesn’t
- Test with real-ish fixtures and dry-run before deploying
Keep a governance catalog once you hit 20+ workflows. Who owns this? What’s the SLA? When can we turn it off?
And backups. Export configurations. Test restores. I learned this one the hard way.
Architecture
Start simple: run n8n in Docker on a single server. Containerize it so you can reproduce the setup when (not if) you need to move it. Use persistent volumes for workflow state, and put long-term data in a real database — not n8n’s execution logs.
When you outgrow one instance, scale horizontally. Shard workflows across workers or push heavy work to queues and serverless functions.
For custom logic, either write a Function node or call an HTTP endpoint you control. Keep the interface stable so workflows don’t break when your implementation changes.
Example: RSS Keyword Alerts to Slack
Let’s build something useful. We’ll monitor an RSS feed (say, Hacker News) for a keyword and post matches to Slack.
This is free—you need Docker, a Slack workspace, and 20 minutes.
What you need:
- n8n running locally (Docker)
- A Slack Incoming Webhook
- Any RSS feed (I’ll use https://hnrss.org/frontpage)
1) Start n8n locally
Install Docker if you haven’t. Then run:
docker run -it --rm -p 5678:5678 -v ~/.n8n:/home/node/.n8n n8nio/n8n
Open http://localhost:5678 and create an account. You’re in.
2) Set up Slack
In Slack, create a new app. Enable Incoming Webhooks. Pick a channel (I use #feed-alerts). Copy the webhook URL.
3) Create a workflow
Back in n8n, click “New” to start a workflow.
4) Add a Schedule trigger
Search for “Schedule Trigger.” Set it to run every 15 minutes. You can tune this later.
5) Add RSS reader
Add the “RSS Read” node. Paste your feed URL (https://hnrss.org/frontpage works great).
Execute the node to test. You’ll see items with titles, links, and publish dates.
6) Filter by keyword
Add an IF node. Set the condition to: title contains "AI" (or whatever keyword you care about).
True branch continues. False branch ends. This filters out noise.
- (Optional) Dedupe so you don’t repost old items
- Add a Function node on the true branch with this code to track last published date:
const state = getWorkflowStaticData('global');
const last = state.lastPubDate || 0;
const fresh = items.filter(i => {
const t = new Date(i.json.isoDate || i.json.pubDate || 0).getTime();
return t > last;
});
if (fresh.length) {
const max = Math.max(...fresh.map(i => new Date(i.json.isoDate || i.json.pubDate || 0).getTime()));
state.lastPubDate = max;
}
return fresh;
- Shape the message
- Add a Set node to produce a compact payload.
- Keep fields: title, link. Optionally compose a message string.
- Post to Slack
- Add an HTTP Request node connected to the Set node.
- Method: POST
- URL: your Slack webhook URL
- Headers: Content-Type: application/json
- JSON body:
{
"text": "New item: {{$json.title}}\n{{$json.link}}"
}
10) Test and deploy
Click “Execute Node” at each step. Fix any mapping issues. When Slack shows a message, you’re good.
Name the workflow something obvious like “HN AI Alerts.” Flip it to Active.
Quick tweaks:
- Swap Slack for Discord or Teams by changing the webhook URL and payload
- Adjust the schedule and keywords
- Add an error path that posts failures to a private channel (trust me, you’ll want this)
Rolling This Out Without Breaking Everything
Start with one workflow that solves a real problem. Alerts, lead routing, data enrichment—pick something people are currently doing manually.
Build a template library. Document naming conventions. Make it easy for the next person to do the right thing.
Create a Slack channel for automation changes. Not for approval (that kills velocity), but for visibility. When something breaks, you’ll know who to ask.
Track ROI simply: hours saved per week, errors avoided, time-to-ship for integrations. This matters when you need budget for scaling.
Add guardrails as you grow:
- Role-based access (not everyone needs production deploy)
- Scoped credentials (marketing shouldn’t have database admin)
- Production approval for high-risk workflows
Each safe automation buys you time for harder problems. That compounds fast.
Just Build Something
n8n lets you connect systems without writing boilerplate or giving up control. Treat workflows like code — version them, test them, and monitor them the same way you would any service.
Pick one thing your team does manually every week. Automate it. Measure what changes, then build the next one.
You can ship your first automation in under an hour. Go do it.
Get posts like this in your inbox
Bi-weekly emails on automation, AI, and building systems that run without you. No fluff.
No spam. Unsubscribe anytime.
Related Articles
The AI Coding Model Wars: How Open Source Is Closing the Gap on Proprietary Coding Models
February 15, 2026
Four major coding models launched in six days. The benchmark gap? 2.6 points. The price gap? 45x. A head-to-head comparison of Opus 4.6, Codex 5.3, GLM-5, and Kimi K2.5.
Intentional AI Integration: How to Adopt AI Coding Tools Without Wrecking Your Codebase
April 1, 2026
AI tools made your team faster. Then patterns started drifting. Here's how to keep architectural coherence without killing the productivity gains.
Lessons Learned in 2026
March 5, 2026
A generalist's field notes from 2026. AI changed the game, execution still wins, and the engineers who connect dots nobody else sees are the ones getting ahead.
Wrestling with a technical challenge?
I help companies automate complex workflows, integrate AI into their stacks, and build scalable cloud architectures.