Migrating from Zapier to self-hosted n8n: what it costs and when it pays off

Moving from Zapier to self-hosted n8n pays off when a few busy workflows run thousands of times a month, or when your data shouldn't pass through another company's servers. Zapier bills by task, so every step of every run counts. Self-hosted n8n has no per-run fee: you pay for a small server and for someone to keep it updated and backed up. For a handful of quiet zaps, stay on Zapier. For busy flows, the switch usually costs less within a few months.

How the pricing differs

Zapier charges per task, and a task is each action step that runs. A five-step zap that runs 2,000 times a month uses about 10,000 tasks. n8n Cloud charges per workflow execution, so the same flow counts once per run however many steps it has. Self-hosted n8n (the free community edition) has no usage fee at all: the cost is the server, the database and your time.

• Stay on ZapierA few low-volume zaps, nobody technical on the team, and connectors n8n doesn't have.
• Move to n8n CloudYou want n8n's editor and pricing per run, but nobody to look after a server.
• Self-host n8nBusy flows, data you'd rather keep on your own servers, or a team that's comfortable owning a small piece of infrastructure.

What self-hosting n8n really involves

The install is the easy part. The work is keeping it healthy, and that is what most guides skip.

• A Postgres database instead of the default SQLite, so executions and credentials survive restarts and you can back them up.
• A fixed encryption key (N8N_ENCRYPTION_KEY) stored somewhere safe. Lose it and every saved credential has to be entered again.
• HTTPS and a stable public URL, so webhooks from Stripe, forms and CRMs reach you.
• Daily database backups that you have restored at least once.
• Updates every few weeks, tested on a copy first, because nodes and APIs change.
• Queue mode with Redis and separate workers once runs start to overlap or one slow flow holds up the others.
• An alert when a workflow fails, using an error workflow that posts to Slack or email.

How to migrate without losing a run

1. 01List every zapWhat triggers it, what it touches, how often it runs and who relies on it. Most teams find a few they can simply turn off.
2. 02Start with the busiest or riskiestThose save the most, and they're the ones where failures hurt.
3. 03Rebuild, don't copyZapier paths and filters often become one cleaner n8n flow with an IF or Switch node. Add retries and an error branch while you're there.
4. 04Run both side by sidePoint the n8n flow at the same trigger, write to a test sheet or table, and compare results for a week.
5. 05Switch and keep the zap pausedTurn off the zap but don't delete it until the n8n flow has run cleanly for a full cycle, such as a month-end.

When n8n isn't enough either

n8n is a good middle step, and you can drop into code nodes when you need to. A flow that waits days for an approval, moves money or must never run twice usually belongs in code with proper tests. I wrote about those signs in why no-code automations break at scale.