Why I Don’t Use n8n
Every few months, someone asks me:
“Have you tried n8n? It looks perfect for all your automations.”
n8n is a popular open-source automation platform: a visual canvas where you connect nodes, call APIs, transform data, and run workflows on a schedule or on triggers. It’s powerful, flexible, and genuinely useful for a lot of people. But I don’t use it.
Not because it’s bad software, and not because I think “real developers don’t use visual tools.” I avoid it for reasons that have more to do with how I like to build and run systems long-term than with n8n itself. This article is not a takedown. Think of it as: “Here’s why n8n doesn’t fit my brain and my stack—and how you can decide whether it fits yours.”
My Default: Logic Belongs in Code, Not in a Canvas
I’m happiest when the important parts of a system live as text in a Git repo: versioned, reviewable, diffable, testable. n8n, like other visual automation tools, flips that model. The logic lives in a GUI. The “source” of truth is a workflow definition that you usually manipulate through the browser. You can export and backup flows as JSON, but that’s not the primary mental model.
For small teams and non-developers, that’s a feature. For me, it’s friction.
If something is core to a product, security-sensitive, or critical to operations, I want it as code—a script in tools/, a small service under services/worker/, a CLI command wired into a task runner. I want to open a pull request, review changes line-by-line, and know that future-me (or someone else) can reason about it without reverse-engineering a visual graph. That doesn’t make n8n wrong. It just means that for my important workflows, the GUI isn’t an upgrade over text—it’s a downgrade.
Another Moving Part in the Stack
Every platform you add comes with hidden recurring costs: deployment, upgrades, backups, security hardening, monitoring and alerting, onboarding others to “how we use this thing.” n8n is no exception. Whether you self-host it or pay for a cloud instance, you’re adding a runtime, a database, a secrets store, a job scheduler, a piece of critical automation glue that now has to be kept healthy.
That’s not a criticism of n8n it’s just reality for any orchestration platform.
In my world, I already have cron and systemd timers, Dockerized workers for background jobs, scripts and CLIs for repetitive tasks, existing logging and monitoring. In other words, I’ve already paid the setup cost for a more traditional, code-centric automation stack. Adding n8n on top doesn’t simplify that; it would sit next to it and increase the overall surface area.
If I were starting from scratch with no automation story, n8n might be more attractive. But with the tools I already have, my equation looks more like: “Is this worth another always-on service I have to own and understand?” So far, the answer has been no.
Maintainability and the “Future Me” Problem
Visual workflows are fun in week one. Drag a node here, connect an API call there, add a condition, ship it. Fast forward eighteen months: Why does this workflow exist? Who added that extra branch, and what does it do? What changed last week that broke this path? How do I safely refactor this without breaking three other flows that depend on it? You can be disciplined with visual tools document everything, apply naming conventions, limit what you build in them. But the medium itself doesn’t encourage that by default.
By contrast, code plus Git gives you a few huge maintainability advantages for free: a clear history of what changed and why, diffs you can scan in seconds, ability to search across the entire codebase, the option to add tests around critical paths. For the kind of long-lived systems I care about, that’s hard to give up. Again, this isn’t “n8n is unmaintainable.” It’s: “If I have to maintain this automation for years, I’d rather it be a small codebase than a big canvas.”
Boundaries Between Projects and Businesses
I run multiple projects and product lines. One of my guiding rules is: each venture should be cleanly separable. If I ever need to sell it or hand it off, I shouldn’t have to untangle a ball of shared infrastructure first. Visual automation tools make it easy to create “central glue” one n8n instance that talks to everything, shared credentials to multiple products and services, cross-cutting workflows that mix data or behavior from unrelated systems. That’s incredibly convenient, right up until it isn’t.
My preference is to keep each product’s automation as close to that product as possible: a repo per project, a job runner per project (or per bounded context), limited and explicit integration points between them. Can n8n be used in a disciplined, isolated way? Absolutely. But given my goals, the risk is that it encourages me to centralize things that I actually want to keep separate.
Where n8n Does Shine
So far I’ve mostly explained why n8n doesn’t fit my stack. Let’s flip it.
If you want automation without writing much code, n8n is genuinely powerful. It has a node for many common apps and services. You can chain together multi-step workflows visually. You can inspect data at each step as it flows through. For small teams and solo founders with limited dev time, that can be a superpower.
If you’re gluing together SaaS tools, not building core product logic, n8n can be a great home. I draw a pretty hard line between product logic (things that are your product or core IP) and ops glue (connecting email, CRM, spreadsheets, and notifications). When a support ticket is closed, update this spreadsheet and ping this Slack channel. When a new row appears in this Google Sheet, send it to your CRM and trigger an email. When a payment fails in your billing system, create a task in your helpdesk. These are important, but they’re often not the foundation your business is built on. For that kind of work, the trade-off—less code, more GUI—can be very reasonable.
If non-developer teammates need to own automations, n8n isn’t just an automation engine—it becomes a collaboration surface between technical and non-technical people. If you work with ops people, marketers, or virtual assistants, you might want a tool where they can see workflows visually, duplicate and tweak them, add small branches or conditions, without waiting on a developer for every change.
My Simple Rule of Thumb
To keep myself honest, I use a simple mental rule:
- If it’s part of the product, or something I’d be nervous to lose → it lives in code, in a repo.
- If it’s purely operational glue between external tools, low-risk, and likely to change often → a visual tool might be a good fit.
Right now, my work is heavily skewed toward the first category. That’s why n8n hasn’t earned a permanent place in my stack. If your work is skewed the other way lots of SaaS-to-SaaS glue, not much core product engineering you might come to the opposite conclusion.
Choosing Tools That Match You, Not the Hype
The point of this article isn’t “don’t use n8n.” The point is: tools live or die on how well they match your values, constraints, and workflow preferences.
My values happen to be text over GUI for critical logic, Git over opaque state, fewer moving parts over more platforms, strong boundaries between products and businesses. Given that, not using n8n is almost inevitable.
For you, the calculus might be different. If you want speed over structure, if you value visual clarity for non-developers, if your automations are mostly glue between third-party tools, then n8n could be an excellent choice.
And if you’re somewhere in between, you don’t have to be religious about it. You can absolutely keep core product logic in code, use n8n for low-risk, ops-level workflows, and let each tool do the work it’s best suited for. That, in the end, is why I don’t use n8n personally, but I’m still glad it exists.