The invoice that did it was $340. Not the highest I’d ever paid Zapier, which is the depressing part. It was just the one I happened to actually look at properly instead of clicking through to pay like I had been doing for eighteen months.
Three hundred and forty dollars. For a month. For automations that were, if I’m being honest with myself, not doing anything Zapier deserved credit for. An email comes in. Parse it. Check a value. Write a row to a sheet. Send a Slack message. Repeat, twelve hundred times that month, across eight different Zaps, each step counting as a task, each task counting toward a limit designed by people whose financial model depends on you not noticing how quickly you hit it.
I’d known about n8n for probably a year at that point. I’d looked at it, decided the self-hosting part sounded like work, and gone back to clicking through invoices. That was the mistake.
The setup took a Saturday afternoon. EC2 instance, Docker Compose, an Nginx reverse proxy I had to look up how to configure correctly because the n8n documentation’s section on reverse proxies assumes you already know what a reverse proxy configuration file looks like, which I did not. The docs say to set the WEBHOOK_URL environment variable to your domain. What they do not say, and what cost me ninety minutes, is that if your Nginx config is not passing the correct headers, your webhooks will accept the incoming request and then silently fail to trigger anything. No error. Just nothing. I sat watching the execution log refresh while a webhook that was definitely being hit was definitely not executing, until I added the proxy_set_header lines and suddenly everything worked and I felt the specific mix of relief and irritation that is the characteristic emotional state of self-hosted software.
Once it was running, the migration was faster than I expected in some places and slower in others. The fast parts were the simple Zaps: trigger, transform, output. Those rebuild in n8n in about ten minutes and the workflow is immediately cleaner because you can see the data flowing between nodes instead of guessing from Zapier’s step history what happened where. The Set node alone is worth something. Being able to name your fields explicitly, map them, and see the output before you run the whole thing is the kind of feature that sounds minor until you’ve spent twenty minutes debugging a Zapier step because you couldn’t tell which transformation was producing a null.
The slow parts were anything involving multi-step logic with conditional branches. Zapier’s filter steps and path routing look simple in the UI and are genuinely limited underneath. When I rebuilt those flows in n8n using IF nodes and proper branching, I kept finding logic errors in the original Zaps that had been silently producing wrong results for months. Zapier hadn’t flagged anything. There was no error log I could actually read. The tasks had just been executing incorrectly and counting toward my bill simultaneously.
One migration took three days. An invoice processing flow that used a Zapier Formatter step to parse dates in a specific regional format. Rebuilding it in n8n meant writing about eight lines of JavaScript inside a Code node to handle the same transformation. That sounds worse. It is actually better, because the code is readable, I can test it in isolation, and I know exactly what it does. The Zapier formatter was a dropdown and a guess that I trusted until I had a reason not to.
The moment that finished the conversion was the first time a production workflow failed in n8n and I could actually read the error. Not “Step 3 encountered an error, check your settings” with a link to a generic help article. An actual error: the HTTP Request node returning a 401, the full response body visible in the execution log, the specific header that was missing, the exact field I needed to change. I fixed it in four minutes. The equivalent Zapier debugging session, based on eighteen months of prior experience, would have been forty minutes and a support ticket that got answered three days later with a link to the same help article.
Zapier is not a bad product. It is a product designed for people who want to pay not to think about automation. The pricing is a direct reflection of that. You are paying for the abstraction, for the connectors that authenticate without OAuth configuration, for the interface that a non-technical person can use without help. If that is genuinely what you need, it is worth the money to someone. It is just not worth the money to anyone who has figured out what is actually happening underneath and has half a Saturday to set something up themselves.
My bill after the migration: thirty-one dollars a month. One EC2 t3.small instance, running continuously.
The ninety percent figure is real. What it cost was one Saturday, ninety minutes of Nginx confusion, and the willingness to read an error message instead of paying someone else to hide it.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.