The problem nobody talks about

Every project has them — the quiet, unglamorous scripts that sit in a cron tab or a scripts/ folder, doing essential work that nobody wants to maintain. Sync this API. Clean up that table. Send a notification when this webhook fires. They work fine until they don’t, and when they break at 2 AM, you’re grepping through a 200-line bash script you wrote six months ago.

I had about 15 of these. Different languages, different patterns, zero documentation. It was a liability dressed up as automation.

Enter n8n

n8n (pronounced “n-eight-n”) is a self-hosted, visual workflow automation platform. Think Zapier, but you own the data, the execution, and the bill. It connects to 400+ services out of the box, runs as a Docker container, and lets you build complex multi-step workflows without writing a single line of glue code.

The key insight: most automation is just “when X happens, do Y, then Z.” n8n makes that pattern visual, debuggable, and maintainable.

What I actually run

Telegram → AI → Summary

I monitor a few Telegram topics that accumulate fast — project updates, incident reports, discussion threads. Instead of reading 200 messages, a workflow pulls new messages every 15 minutes, sends them to an LLM for summarization, and drops a concise digest into a dedicated channel.

The result: I get the signal without the noise. A 30-second read replaces 20 minutes of scrolling.

Webhook → Database → Notification

When a deploy finishes, a form gets submitted, or an external service calls back, the workflow validates the payload, writes it to PostgreSQL, and routes a notification based on severity. Deploys get a quiet log entry. Failed builds get a Telegram ping. Critical errors get both Telegram and email.

No more checking dashboards manually. The system tells me when something needs attention.

Scheduled Cleanup

A daily cron that scans for orphaned records, stale sessions, and expired tokens. It logs what it found, cleans up automatically, and sends a summary report. No more manual database sweeps or “wait, how long has this been sitting here?”

Self-hosted setup

n8n runs as a Docker container on the same VM as my other services. The setup is straightforward:

  • PostgreSQL as the workflow database — not the default SQLite, because production data deserves a real database
  • Webhook URLs exposed via Cloudflare Tunnel — no opening ports, no nginx config gymnastics
  • Environment variables for all API keys and secrets — never hardcoded in workflows, never committed to git

The whole thing uses about 256MB of RAM and handles my current workload without breaking a sweat.

What surprised me

Error handling is genuinely good. Each node can have its own error workflow, so a failed API call in step 3 doesn’t kill steps 4 and 5. You can retry, skip, or route to a fallback — all configured visually.

The execution history is a debugger. Every run is logged with full input/output at each step. When something breaks, you replay the exact execution, inspect what went wrong, and fix it. No more adding console.log to a cron script and waiting for the next run.

Community templates are useful starting points. Not as finished products, but as architectural patterns. “Oh, that’s how you handle pagination in a loop” or “that’s how you branch based on a condition.” The real value comes from building custom workflows for your specific stack.

When it doesn’t fit

n8n is integration glue, not application code. If your logic involves complex state management, real-time processing, or branching that would make a decision tree cry — write it as a service. n8n excels at the orchestration layer: the “when this happens, do these three things in sequence” patterns that glue your real services together.

It’s not a replacement for understanding your systems. It’s a tool that makes the boring parts of keeping them running actually maintainable.