A client forwarded me their Zapier invoice in February and asked if it looked right. It looked right in the sense that the number matched what Zapier charges for their Team plan with the task volume they were running. It did not look right in the sense that they were paying $598 per month to move data between six applications in workflows that collectively contained, at most, three conditional branches and one API call that was doing anything remotely interesting. The rest was field mapping. Renamed fields passed from one app to another, the kind of thing that looks like automation on a dashboard and feels like nothing when you actually read what the Zap is doing.
I told them what I am going to tell you. That number is not the cost of the automation. It is the cost of not wanting to think about infrastructure.
I understand the appeal. When Zapier works, it genuinely works, and setting up a new Zap takes twenty minutes including the time you spend looking for the trigger you want. For someone running a small business who needs one workflow connecting two SaaS tools and will never need to look inside it again, the managed convenience is probably worth something. But the pricing is built on the assumption that you will grow into their task tiers, and the task tier model is one of the more quietly punishing pricing structures in SaaS because complexity and volume scale together. The more useful your automations become, the more tasks they consume, the more you pay, and the relationship between what the platform is doing and what it costs you becomes increasingly difficult to justify.
The $11 number is a t3.micro EC2 instance on AWS. That is what I pay for the server that runs n8n for two clients and several of my own workflows. The actual cost sits between nine and thirteen dollars a month depending on data transfer, and it has not gone above fifteen in the time I have been running it. The self-hosting setup I use is Docker Compose with an nginx reverse proxy, a PostgreSQL database for execution persistence, and Certbot for SSL. That is the whole stack. None of it is exotic.
The first time I set this up, I made every mistake that someone who learned infrastructure from documentation rather than a computer science degree makes. I got the WEBHOOK_URL environment variable wrong, which meant that every webhook trigger I configured was pointing at localhost inside the container rather than the public domain, and the workflows would test fine within n8n’s built-in testing interface and then fail completely when anything external tried to trigger them. The error in production was not a helpful message about webhook configuration. It was silence. The execution simply never started. The n8n documentation tells you to set WEBHOOK_URL to your domain. It does not tell you clearly enough that if you set it incorrectly, nothing will error obviously — the webhooks will just never fire, and you will spend time looking at your workflow logic before you think to check the environment variable.
Once I understood that failure mode, I started documenting the setup properly for my own use, which is how I eventually built a repeatable process for spinning up new client instances. The Docker Compose file I use now is not meaningfully different from the one in the n8n documentation, but the environment variable configuration is explicit, the volume mounts are verified before anything goes into production, and the nginx config is tested against the actual domain before I migrate any workflows over.
The migration itself is where people underestimate the work. Moving from Zapier to n8n is not just an infrastructure decision. The logic that Zapier abstracts away has to be rebuilt explicitly. A Zapier Formatter step that was doing date parsing becomes a Code node with a moment.js expression or a Set node with n8n’s built-in date functions, depending on what exactly the transformation was doing. A Zapier Paths branch that was routing on a field value becomes an IF node or a Switch node depending on how many conditions you need. None of this is hard, but none of it is automatic, and anyone telling you that migration is straightforward has either never done it with a complex workflow or is not being honest about the time they spent.
Make.com is easier to migrate away from in some respects and harder in others. The canvas-based flow structure means the logic is at least visible before you rebuild it, but Make’s iterator and aggregator modules handle array manipulation in a way that has no single clean equivalent in n8n. I rebuilt a Make flow for a client last year that was using an aggregator to collect results from a multi-iteration API call, and the n8n version required a Code node with about forty lines of JavaScript to replicate the exact accumulation behaviour. That is not a criticism of n8n. It is just an accurate description of what the migration required.
The $11 number is real. So is the setup time. So is the fact that when something breaks at 3am on a self-hosted instance, you are the one who has to look at it.
The question is not whether Zapier is worth $600 a month in absolute terms. The question is whether the managed convenience is worth the difference between $11 and $600, every month, indefinitely. For most people asking me that question, once they have actually looked at what their workflows are doing and what it would take to move them, the answer is no. But that calculation only makes sense if you are willing to spend the setup time honestly rather than treating self-hosting as something that happens once and then runs itself.
It runs itself. After you have made all the mistakes it takes to understand how it actually works.
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.
