I Spent Two Days Setting Up n8n — Here's Why It's My New Favorite Automation Tool

I've been running my site for about two months now, and I've been deep in the AI tooling rabbit hole. I already wrote about Dify (Complete Guide to Deploying and Using Dify Locally With Docker) for building AI chat apps, and that's great. But last week a friend asked me: "Is there something where I can just drag and drop and connect a bunch of APIs together?" And honestly, my first thought was n8n.

I'd heard about n8n for a while but never actually sat down to figure it out. So last weekend I spent two full days deploying it, building workflows, hitting walls, and eventually getting things working. This post is everything I learned — the good, the bad, and the "why isn't this documented anywhere" moments.

What Even Is n8n?

Quick version: n8n is an open-source workflow automation platform. You build automations by dragging nodes around and connecting them.

Think Zapier or Make, but with some key differences:

• Self-hostable: Your data stays on your server. No third-party cloud involved.
• Fair-code licensed: Core is open source and free to use. Enterprise features are paid.
• Native AI capabilities: Built-in AI Agent nodes that can call LLMs, use tools, and reason.
• 400+ integrations: GitHub, Slack, databases, HTTP requests, you name it.
• Custom code support: Need complex logic? Drop in a JavaScript or Python node.

The thing that really got my attention was the AI Agent feature. n8n isn't just "connect APIs together" — it's "build an AI agent that can use APIs as tools." That's a different level entirely.

Deploying It: Docker Makes Life Easy

If you just want to try it out, one command:

docker run -it --rm \

  - -name n8n \

  - p 5678:5678 \

  - v n8n_data:/home/node/.n8n \

  docker.n8n.io/n8nio/n8n

Hit http://localhost:5678, create an account, and you're in. But for anything serious, you'll want docker-compose with PostgreSQL.

The Production Setup

Here's my docker-compose.yml:

version: '3.8'

services:

  n8n:

    image: docker.n8n.io/n8nio/n8n

    restart: always

    ports:

      - "5678:5678"

    environment:

      - N8N_HOST=your-domain.com

      - N8N_PORT=5678

      - N8N_PROTOCOL=https

      - NODE_ENV=production

      - WEBHOOK_URL=https://your-domain.com/

      - DB_TYPE=postgresdb

      - DB_POSTGRESDB_HOST=postgres

      - DB_POSTGRESDB_PORT=5432

      - DB_POSTGRESDB_DATABASE=n8n

      - DB_POSTGRESDB_USER=n8n

      - DB_POSTGRESDB_PASSWORD=your_secure_password

      - N8N_ENCRYPTION_KEY=your_random_encryption_key

    volumes:

      - n8n_data:/home/node/.n8n

    depends_on:

      postgres:

        condition: service_healthy

  postgres:

    image: postgres:15

    restart: always

    environment:

      POSTGRES_USER: n8n

      POSTGRES_PASSWORD: your_secure_password

      POSTGRES_DB: n8n

    volumes:

      - postgres_data:/var/lib/postgresql/data

    healthcheck:

      test: ["CMD-SHELL", "pg_isready -U n8n"]

      interval: 10s

      timeout: 5s

      retries: 5

volumes:

  n8n_data:

  postgres_data:

docker-compose up -d and done. Well, mostly.

Pitfalls I Hit (So You Don't Have To)

Pitfall #1: N8N_ENCRYPTION_KEY is not optional

n8n uses this key to encrypt your saved credentials (API keys, OAuth tokens, etc.). If you don't set it, every time you restart the container, all your saved credentials become unreadable. Your workflows will break silently. Generate one with:

openssl rand -hex 32

Pitfall #2: WEBHOOK_URL matters more than you think

If you use Webhook triggers (GitHub webhooks, Slack events, etc.), this URL must be externally accessible. Without it, n8n generates webhook URLs like http://localhost:5678/... which obviously won't work from the outside.

Pitfall #3: HTTPS is on you

n8n doesn't do HTTPS itself. You need a reverse proxy. I use Nginx:

server {

    listen 443 ssl;

    server_name your-domain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;

    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

    location / {

        proxy_pass http://localhost:5678;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support (n8n needs this!)

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

    }

}

The WebSocket config is critical. Without it, the n8n frontend just hangs on loading. Took me a while to figure that one out.

Pitfall #4: PostgreSQL healthcheck typo

I spent 30 minutes debugging why n8n wouldn't start. Turns out I typed pg_ready instead of pg_isready in the healthcheck. The container was "healthy" but PostgreSQL wasn't actually ready. Double-check your healthcheck commands.

My First Real Workflow: RSS + AI Summaries

Deployment is nice, but what actually made me go "okay, this is cool" was building a real workflow. My first one: every morning at 8 AM, grab RSS feeds from tech blogs, use GPT-4o-mini to generate summaries, and email them to me.

The node chain looks like this:

1. Schedule Trigger — fires at 8 AM daily
2. RSS Feed Read — pulls articles from RSS feeds
3. Split In Items — processes each article individually
4. HTTP Request — calls OpenAI API for summarization
5. Gmail — sends the digest

Setting Up the RSS Feed

Add an RSS Feed Read node and point it at an RSS URL. For example, Hacker News:

https://hnrss.org/frontpage?count=10

Want multiple sources? Add multiple RSS nodes and merge them with a Merge node.

Calling OpenAI (The Flexible Way)

n8n has a built-in OpenAI node, but I found the HTTP Request node gives you more control:

• Method: POST
• URL: https://api.openai.com/v1/chat/completions
• Authentication: Predefined Credential → OpenAI API
• Body:

{

  "model": "gpt-4o-mini",

  "messages": [

    {

      "role": "system",

      "content": "Summarize this article in 3 sentences. Be concise and factual."

    },

    {

      "role": "user",

      "content": "Title: {{ $json.title }}\nContent: {{ $json.content }}"

    }

  ],

  "max_tokens": 300

}

That {{ $json.title }} syntax is n8n's expression language. It pulls data from the previous node's output.

Pitfall #5: The expression editor can be wonky

Sometimes when you drag a field from the input panel into the expression, it generates the wrong path. My advice: run the previous node first, look at the actual JSON output, and write the expression manually. More reliable.

Pitfall #6: Timeout with local models

If you're running a local model through Ollama or vLLM, responses can be slow. I was testing with Llama 3 70B locally (Complete Guide to Local AI Deployment: Running Llama, Qwen, and GLM on Your Machine) and a single request took almost 5 minutes — way past the default timeout. Either increase the timeout in node settings or use a faster model for automation workflows.

Debugging: Pin Data Is a Lifesaver

n8n has this feature called Pin Data — right-click any node and pin its output. Next time you run the workflow, that node just uses the pinned data instead of actually executing. Incredibly useful for debugging downstream nodes without burning API credits.

There's also Execute Node — you can run a single node instead of the whole workflow. Pin the output of earlier nodes, then iterate on just the node you're working on.

Honestly, this debugging experience is better than most workflow tools I've tried.

The Killer Feature: AI Agent Workflows

This is where n8n really shines. Since version 1.x, n8n has a built-in AI Agent node that turns your workflow into an actual agent — one that can reason, use tools (What the Heck is MCP? A Full-Stack Dev's Practical Take), and make decisions.

Building a Database-Querying Agent

I built an agent that can query my PostgreSQL database and answer questions about business data. The setup:

1. Chat Trigger — user sends a message
2. AI Agent — the brain
3. OpenAI Chat Model — the LLM powering the agent
4. Postgres Tool — a tool the agent can use

Configure the AI Agent:

• Agent Type: Tools Agent
• System Message:

You are a data analysis assistant. You can query a PostgreSQL database

to answer user questions. When querying, first check what tables exist,

then write appropriate SQL queries. Respond in clear, concise language

with key numbers highlighted.

Then connect the Postgres Tool node as a tool the agent can use. The agent will automatically decide when it needs to query the database, write SQL, and format the results.

This genuinely impressed me. I asked "How many new users did we get last month?" and it wrote SELECT COUNT(*) FROM users WHERE created_at >= ..., ran it, and gave me a clean summary. No manual SQL needed.

Pitfall #7: Agent token consumption is high

Because the agent might loop through multiple LLM calls (think → decide tool → see result → think again), token usage is 3-5x higher than a single API call. A complex query burned about 3000-5000 tokens. With GPT-4o, that's a few cents per query. I switched to GPT-4o-mini for the agent and it's much more economical.

Pitfall #8: Agents can write dangerous SQL

Theoretically, an agent could write DELETE or DROP statements. Low probability, but real risk. I gave my database user read-only permissions. You should too.

Multi-Tool Agents

The really powerful part is connecting multiple tools:

• HTTP Request Tool — call any API
• Calculator Tool — math operations
• Code Tool — execute arbitrary code
• Vector Store Tool — search a knowledge base

I built a "universal assistant" workflow with a search API, weather API, and a local knowledge base. Ask it "What's the weather in Beijing? Also check my meeting schedule for tomorrow." It'll call the weather API and query the knowledge base in sequence, then give you a combined answer.

The key to making multi-tool agents work well is writing a good System Message. Tell the agent:

• Who it is and what it does
• What tools it has and when to use each one
• Response format expectations
• When NOT to use tools (to avoid unnecessary API calls)

My first attempts were messy — the agent kept calling tools it didn't need. Adding "Only use the search tool when the user explicitly asks for external information" fixed most of the issues.

n8n vs Dify: Which One Should You Pick?

I've written about Dify before, and now n8n. So which one?

Pick n8n when:

• You need to connect many external services (APIs, databases, SaaS tools)
• Your core need is automation; AI is just one piece of the puzzle
• You need complex branching, loops, and error handling
• You're a developer who likes granular control
• You need scheduled tasks, webhooks, and non-conversational triggers

Pick Dify when:

• You're building an AI chat application (customer service, assistant)
• You need RAG (knowledge base Q&A)
• You want pure visual building with minimal code
• Your end users are non-technical and need a chat interface
• You care most about prompt engineering and model tuning

Use both together:

Honestly, the ideal setup is using both. Use n8n for data collection, preprocessing, and automation pipelines. Use Dify for the AI chat application layer. They complement each other perfectly.

Advanced Tips

Environment Variables Worth Setting

# Execution timeout (seconds)

EXECUTIONS_TIMEOUT=600

# Prune old execution data

EXECUTIONS_DATA_PRUNE=true

EXECUTIONS_DATA_MAX_AGE=30

# Enable community nodes

N8N_COMMUNITY_PACKAGES_ENABLED=true

# Editor base URL (for correct links)

N8N_EDITOR_BASE_URL=https://your-domain.com

Community Nodes

n8n has a community nodes ecosystem — third-party integrations installed as packages. Some I found useful:

• n8n-nodes-pdf — parse PDF files
• n8n-nodes-telegram — enhanced Telegram Bot integration
• n8n-nodes-wechat — WeChat integrations

Install from the UI under Settings → Community Nodes, or via CLI:

docker exec -it n8n n8n community-node install n8n-nodes-pdf

Performance Optimization

• Use PostgreSQL, not SQLite — SQLite gets slow under concurrent loads
• Set up data pruning — execution records pile up fast
• Use Sub-Workflows — split complex workflows into smaller, reusable pieces
• Limit concurrency — set max parallel executions to avoid overwhelming your server

Things I Don't Love

Let me be honest about the rough edges:

• Learning curve is steeper than expected — concepts like Credentials, Expressions, and Pin Data take time to understand
• Some node docs are sparse — you end up trial-and-erroring a lot
• Debugging large workflows is painful — even with Pin Data, 30+ node workflows get confusing
• Mobile experience is bad — the web UI is desktop-first, which makes sense but still annoying

Wrapping Up

After two weeks with n8n, I'm sold. It's not trying to be everything — it's a workflow automation tool that happens to have great AI integration. If you have repetitive tasks you want to automate, or you want to add automation capabilities to your existing apps, n8n is worth your time.

It's not as AI-focused as Dify, but its versatility is the selling point. Anything with an API can be connected. And the AI Agent feature is genuinely powerful — being able to build an agent that can query databases, call APIs, and make decisions within a visual workflow is something I haven't seen done this well elsewhere.

Next up, I'm going to try building a GitHub PR auto-review workflow with n8n. If that works out, I'll write about it. Questions? Drop them in the comments.

Resources

• n8n Official Site: https://n8n.io
• n8n GitHub: https://github.com/n8n-io/n8n
• n8n Docs: https://docs.n8n.io
• n8n Community Forum: https://community.n8n.io
• Docker Deployment Guide: https://docs.n8n.io/hosting/installation/docker/