Before I found n8n, I was already doing what n8n does. I just didn't know that's what it was called.

I had a project called Ghost Communicator — a Puppeteer-based system that opened browser windows to different AI chat interfaces and relayed messages between them. Claude talks to GPT, GPT talks to Gemini, I watch. It was held together with Node.js scripts and enthusiasm. I had another project that stitched SearXNG and Firecrawl together into a self-hosted search engine. Both of these were, in retrospect, middleware. I was building orchestration layers by hand, one fetch request at a time, because I didn't know there was a whole category of tool designed to do exactly this.

Then I fell into n8n, and the shape of the problem changed.

What Actually Changed

The standard pitch for n8n is that it's an open-source alternative to Zapier and Make, self-hostable, no operation limits, $12/month on a VPS instead of $200+ on a cloud platform. All of that is true and it matters. But it's the least interesting thing about it.

What n8n actually did for me was make orchestration visible. When you're writing scripts to connect systems, the logic lives in your head and in a tangle of files. When you build the same thing as a visual workflow, you can see the architecture. You can see where the data transforms, where the branches happen, where the failures will occur. That visibility changed how I thought about what was possible. I went from "I can make these two things talk to each other" to "I can make anything talk to anything, and the wiring is the product."

I now run 50+ workflows on a single VPS. Content aggregation, AI model orchestration, calendar automation, notification routing, data transformation. Things that would be either impossible or wildly expensive on Zapier or Make, running quietly on a $12 server that I control completely.

The Line Between Workflows and Apps

Here's the thing nobody told me and I had to figure out the hard way: the line between a workflow and an application is increasingly fake.

A workflow that has a webhook trigger on the front end, a database on the back end, and an LLM making decisions in the middle is — functionally — an application. It takes input, processes it, returns output. It has state. It has logic. The fact that it lives inside a workflow engine instead of a codebase doesn't change what it is. It just changes how fast you can build it and how easy it is to modify.

This is the thing that n8n taught me that no amount of reading about automation would have: we can just make our own middleware now. The LLM is the universal translator. It handles the messy part — parsing unstructured input, making judgment calls, transforming data between formats that were never designed to be compatible. The workflow engine handles the routing. You handle the intent. That's the whole stack.

You don't need to be a software engineer to build software anymore. You need to understand systems well enough to describe what should happen, and then you need the patience to actually wire it together. Which brings me to the part nobody wants to talk about.

Credentials and I/O: The Tax on Everything

Every automation project has the same structure. You spend an hour on the logic — the fun part, the part where you design the workflow and it all makes beautiful sense in your head. Then you spend three days getting the OAuth token to work.

I'm not exaggerating. Credentials and I/O are the single biggest pain in the ass in all of automation, and it's not even close. Not the orchestration. Not the AI. Not the data transformation. The part where you need to authenticate with a service that has a three-legged OAuth flow with a callback URL that has to be HTTPS and registered in a developer console that requires a different account than the one you're actually trying to automate, and then the token expires in an hour and the refresh flow is documented in a PDF from 2019 that references an endpoint they deprecated last March.

This is what makes everything take forever. It's not a wall — a wall implies you stop. It's more like a tax. Every project pays it. Every integration pays it. You build the whole beautiful workflow and then you sit there for a day and a half trying to figure out why Google Calendar returns a 403 for the scope you definitely authorized.

And it's not just OAuth. It's parsing a PDF that some vendor generated with a tool from 2006 that embeds the text as images. It's getting data out of an API that returns XML nested six layers deep with inconsistent field names. It's the webhook that works in testing and silently fails in production because the payload format changed and nobody told you. It's always the I/O. The logic is trivial. Getting data in the right shape, from the right source, with the right permissions — that's where the time goes.

Nobody writes about this part because it's not exciting. But if you're evaluating whether to build automation for your business, this is the honest answer to "how long will it take?" It will take as long as the most annoying credential and the most poorly documented API endpoint in your stack. The rest is easy.

Why Self-Host

The self-hosting question is actually simpler than the automation question. If you run your workflows on someone else's infrastructure, you're subject to their rate limits, their pricing changes, their decisions about which integrations to support, and their opinion about how much data you should be allowed to move. If you run them on your own box, you're subject to your own patience with server administration.

I chose the second one. A VPS running Docker with n8n, a Postgres database, and Nginx Proxy Manager in front of it. Total monthly cost is less than a single month of Make's "Pro" tier. I can run unlimited workflows, process unlimited operations, and when something breaks at 2 AM, I have full access to the logs and the database and the filesystem, instead of a support ticket and a 48-hour response time.

Self-hosting isn't for everyone. It requires comfort with the command line and a willingness to be your own ops team. But if you're building automation as a core part of your work — not just connecting two apps, but building systems that run significant parts of your business or your infrastructure — the control is worth the maintenance. Every time.