My friend Tobi texted me on a Thursday evening while I was staring at a Code node that was refusing to parse a webhook payload correctly, and his message said: “bro should I just use Zapier or is n8n actually worth the stress.” I told him I would call him back. Then I finished debugging, which took another forty minutes because the payload had a nested array that Make.com’s documentation had shown as a flat object and I had built the entire extraction logic on that assumption. When I finally called Tobi back, I gave him the honest version instead of the one that sounds balanced.
Here is the honest version.
Zapier is a finished product. I mean that in both senses. The interface is clean, the integrations are maintained, the error messages are readable, and the support actually responds. It is also priced like a finished product that knows it has you, which is to say that the moment your automations get any real volume or complexity, you are looking at pricing that requires you to have a conversation with a sales team, which is the automation industry’s way of saying the number on the website is not actually the number. I moved a client off Zapier last year because their monthly task count had grown to the point where the renewal quote came back at three times what they had been paying, for workflows that had not changed. The tool had not got better. They had just got more dependent on it.
Make.com is genuinely better than Zapier at the workflow level. The visual canvas is the best in the category, the data mapping is more flexible, and the pricing stays reasonable longer. I have built complex multi-branch logic in Make that would have been painful in Zapier and it mostly held together. Where Make falls apart is when the workflow gets deep enough that you need to do something the platform did not anticipate. The HTTP module is fine until you need to handle OAuth token refresh mid-execution with conditional retry logic, at which point you are either writing a workaround that involves an intermediary webhook or you are accepting that this particular automation lives at the edge of what Make can actually do. I have had that conversation with clients more than once. Make’s answer is usually a feature request with a vague timeline.
n8n does not have that ceiling. That is not marketing copy, that is what the Code node is. When the HTTP Request node gets you ninety percent of the way and the last ten percent requires you to reshape a response object before passing it downstream, you write twelve lines of JavaScript in the Code node and you move on. When I was building an invoice approval flow that used OpenAI function calling to extract line items and route approval based on vendor category and amount thresholds, the logic required conditionals that would have needed five or six separate modules in Make chained together. In n8n it was an IF node, a Code node, and a Switch node. The workflow was readable. I could come back to it three weeks later and understand what it was doing.
The part nobody warns you about with n8n is the self-hosting experience the first time. I set it up on an AWS EC2 instance using Docker Compose and the documentation, which has got better but is still optimistic about how straightforward this is, did not adequately explain what happens with webhook URLs when you are behind a Nginx reverse proxy that you have not configured to pass the correct host headers. My webhooks were registering with a localhost URL, which meant every external trigger was hitting an endpoint that did not exist from outside the container. The fix was a single environment variable, N8N_HOST, that the documentation mentioned in a footnote in the deployment section. I found it after ninety minutes of reading GitHub issues from 2021. The production workflow had been failing silently for two hours before I noticed because the execution log was not surfacing the webhook registration error at the level I was checking.
That experience is real and it is the price of self-hosting. What you get in return is that the tool does not throttle you, does not charge you per execution, does not make you talk to a sales team when your volume grows, and does not deprecate the integration you depend on because the third-party API changed and the maintenance queue is long. I have had two Make.com modules break on me because of API version changes on the provider side. Both times the fix was waiting for Make to update the module. In n8n I would have updated the HTTP Request node myself in twenty minutes.
The cloud-hosted version of n8n closes most of the self-hosting gap for people who do not want to manage infrastructure. It is not free, but the pricing is execution-based in a way that scales more honestly than Zapier’s task limits, and you retain the full capability of the platform including the Code node, which Zapier restricts at the plan level in a way that I find difficult to justify on any grounds other than upselling.
Zapier is the right answer if you need something running by Friday that a non-technical team member can maintain without your help. That is a legitimate requirement and Zapier meets it. But if you are building anything you expect to still be running and extending a year from now, you are going to hit a wall, and the wall is going to cost money to go around.
n8n is harder to start. It is significantly cheaper to grow. Those two facts are the whole comparison, and everything else is marketing.
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.
