DEV Community

John
John

Posted on

n8n vs Zapier: Which Zaps Break When You Move to Self-Hosted n8n with Docker, and How Much Work Is Rebuilding Them?

#selfhosted #docker #automation #nocode

Treat a move from Zapier to self-hosted n8n as a rebuild, not a migration, because n8n has no native importer for Zaps. Simple webhook and API Zaps usually transfer cleanly. The ones that cause trouble depend on apps with no native n8n node, Zapier-hosted features such as Tables or Interfaces, or OAuth connections you must now register yourself. Audit your Zaps by those three risks before you commit, because that list, not your Zap count, determines the workload.

TL;DR

  • Solo operator with a handful of linear Zaps, such as a freelancer sending form leads to a CRM: Migrate first, because mainstream apps and short workflows are the cheapest kind to rebuild.
  • Developer running webhook-heavy Zaps, such as a SaaS founder routing Stripe events to Slack: Migrate, because webhook triggers and the HTTP Request node map closely to what you already do.
  • Marketing team relying on niche SaaS connectors, such as a three-person agency syncing lead-generation tools: Audit before deciding, because each app without a native node means reading API docs and building the calls by hand.
  • Non-technical business owner with nobody to maintain a server: Stay on Zapier, because updates, backups and failed runs become your responsibility after the move.
  • Team built around Zapier Tables and Interfaces, such as an operations group running approvals through them: Stay for now or plan a larger project, because you must replace the data store and front end as well as the workflows.
  • Company handling sensitive customer data, such as a small clinic or legal practice: Pilot one low-risk workflow on n8n, because self-hosting keeps execution data on infrastructure you control, but you also take on securing it.

The central tradeoff is simple: you give up Zapier's managed connectors and hands-off operation in exchange for control over your workflows, data and infrastructure, and you pay for that control in rebuild and maintenance time.

Table of contents

Which Zaps break first when you leave Zapier?

Nothing breaks on the day you install n8n. Zaps stop working when you switch them off, or when your Zapier plan ends, and n8n will not run them for you. The real question is which ones will resist a rebuild. Sort your account by the dependencies below, not by Zap count. A 2-step Zap tied to Zapier Tables can cost you more than a 10-step Zap built on Slack and Gmail.

  • Zaps using apps with no native node: Zapier's directory lists thousands of apps, while n8n ships hundreds of built-in integrations. Any app on the wrong side of that gap needs a community node or hand-built API calls.
  • Zaps built on Zapier's own tools: Tables, Interfaces, Storage by Zapier and Email by Zapier exist only inside Zapier. Moving the workflow does not move them, so you need a replacement for each.
  • Zaps using OAuth-only connections: Zapier owns the OAuth apps behind many of its connectors. Self-hosted, you may need to register your own client ID and secret, and some vendors put that behind an approval process.
  • Zaps relying on polling triggers: Their "new item" logic depends on how the trigger tracks what it has already seen. If you recreate one carelessly, it can miss records or process old ones again.
  • Zaps fed by Zapier webhook URLs: Every external system posting to a hooks.zapier.com address must be repointed at your n8n instance. Forms, payment tools and internal scripts are easy to overlook.
  • Zaps with long Delay steps: Runs already waiting inside Zapier will not transfer. Let them finish or recreate that pending state before you cut over.

Can you import Zaps into n8n, or do you have to rebuild every one?

Plan to rebuild every one. n8n can import workflows, but it expects n8n's own JSON format, in which each node has a type, parameters and connections. A Zap does not arrive in that shape. Even when your Zapier plan lets you export Zap data, that file is best treated as documentation, not as something n8n can run.

A few shortcuts can still reduce the typing:

  • Zap inventory: Record each Zap's trigger, steps, field mappings and owner in a spreadsheet before you begin. Zapier's export, where your plan offers it, can help with this. Screenshots fill the gaps, and this inventory becomes your rebuild specification.
  • n8n workflow templates: The template library at n8n.io includes common app-to-app patterns. Start from one when it matches, then check every field mapping, because a template reflects its author's data and not yours.
  • Reusable workflow files: Once you have built one good pattern, duplicate it in the editor or export it. The command n8n export:workflow --id=<ID> --output=workflow.json writes it to a file, and n8n import:workflow --input=workflow.json loads it into another instance.
  • Sub-workflows: If 20 Zaps repeat the same cleanup or notification steps, build those steps once and call them with the Execute Sub-workflow node. The result is fewer workflows to maintain than Zaps you started with.
  • AI-drafted JSON: A language model can turn your written Zap specification into n8n workflow JSON. Treat the output as a rough draft, because node parameters can be wrong or invented, and test it with harmless data.

Consolidation is the one real gain from the rebuild. Merge near-duplicate Zaps as you go instead of copying them one for one.

Which Zapier apps have no native n8n node?

No fixed list will stay accurate, because both catalogues change constantly. Zapier's directory also reaches further into niche SaaS, so the apps most likely to lack a node are vertical tools: specialist CRMs, regional invoicing systems and small lead-generation products. Check your own apps instead of relying on someone else's list. Take the app names from your Zap inventory and look each one up in the integrations directory on n8n.io.

Then check whether the node supports your specific trigger and action. An app can appear in the directory and still lack the one operation your Zap needs. Sort each result into one of these five buckets:

What you find What it means Typical next step
Native node with your trigger and action Closest to a direct swap Reconnect the account and remap the fields
Native node, but your action is missing Partial coverage Use the node where you can and make an API call for the missing action
Action node only, no trigger Nothing starts the workflow automatically Use a vendor webhook or the Schedule Trigger to poll the API
Community node only Third-party code, usually an npm package named n8n-nodes-* Check its maintenance history and source before installing
No node, but a public API You build the integration yourself Use the HTTP Request node
No node and no public API The hardest case Replace the app, or keep that Zap on Zapier

Community nodes deserve caution. They run inside your n8n instance and can access what it can access, so review them as you would any other dependency. Maintenance can also stop without warning, and an abandoned node may leave you with the same rebuild later.

How far can the HTTP Request node close the integration gap?

It closes most of the gap for any app with a documented REST API. The HTTP Request node can send any standard method, including GET, POST, PATCH and DELETE, with custom headers, query parameters and JSON bodies. What it cannot do is hide the API from you. A Zapier connector already knows the vendor's fields and quirks, while you have to learn them from the documentation.

These features and limits decide how far it gets you:

  • cURL import: If the vendor's docs show a curl example, paste it into the node's Import cURL option. This fills in the method, URL, headers and body, and it is often the fastest way to get a first working call.
  • Authentication: The node can reuse predefined n8n credentials for supported services or use generic types such as header auth, basic auth and OAuth2. Static API keys are easy. Signed requests with custom hashing usually need a Code node to compute the signature first.
  • Pagination: Zapier connectors often handle multiple pages for you. Here, you configure pagination in the node, using a next-page URL or an incrementing parameter, and test it against an account with enough records to span several pages.
  • Rate limits: A loop can quickly trigger HTTP 429 responses. Use the node's batching options or a Wait node to pace requests according to the vendor's published limits.
  • Hidden field translation: Connectors often turn internal IDs into readable dropdowns. Over raw HTTP, you may need an extra lookup call to convert a name into an ID.
  • Hard stops: Without a public API, the node has nothing to call. SOAP services are possible with hand-written XML, but expect more work, and browser-only tools remain out of reach.

Polling versus webhooks: what changes when triggers run on your own server

On Zapier, polling intervals depend on your plan, typically from 1 to 15 minutes, and Zapier always has a public endpoint ready for webhooks. With n8n, you set the polling schedule and provide the endpoint yourself. Most of the practical differences follow from that:

Concern Zapier Self-hosted n8n
Polling frequency Set by your plan Set by you, within the vendor's API limits
Webhook address hooks.zapier.com Your own domain, with WEBHOOK_URL set to its public address
HTTPS Provided Your reverse proxy or hosting platform
Downtime Zapier's responsibility Yours: events sent during an outage may be lost unless the sender retries
Test and live URLs Managed for you Separate: /webhook-test/ for testing, /webhook/ for active workflows

The last row catches many first-time users. A sender left on the test URL stops working once you close the editor's listening session, so activate the workflow and use the production URL.

Inbound webhooks also decide where you can host. n8n listens on port 5678 by default, and outside services must reach it over public HTTPS. A VPS gets there with a domain and a reverse proxy, while a home server or NAS also needs port forwarding or a tunnel. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user. Apps on it get a public HTTPS subdomain through NSL.SH mesh routing, without a static IP or port forwarding.

If your n8n instance will only poll, it needs outbound access alone. A machine behind a home router handles that, although it must be running when each poll is due.

Why OAuth and credentials can take longer than the workflow itself

On Zapier, connecting an account usually means clicking Connect and approving access, because Zapier has already registered its own OAuth app with the vendor. On self-hosted n8n, you are often the one who has to register that app. A workflow you can rebuild in minutes may wait on a developer console, an admin approval or a vendor review.

Your saved Zapier connections will not come with you, so budget for these tasks:

  • OAuth client registration: Create an app in each vendor's developer console, then copy its client ID and secret into n8n. You need developer access there, and in larger organizations that may mean asking an administrator.
  • Redirect URLs: n8n shows the callback URL in its credential dialog, typically ending in /rest/oauth2-credential/callback. It must match the vendor's setting exactly, so decide on your final domain before registering apps, or you will have to update each one later.
  • Google's testing mode: An external Google OAuth app left in Testing status issues refresh tokens that expire after 7 days. A workflow can pass every test and then fail a week later, so plan for this before go-live.
  • Vendor review: Some platforms require app review for sensitive scopes. Check this early, because you cannot speed up a review from your side.
  • Encryption key: n8n encrypts stored credentials with N8N_ENCRYPTION_KEY. Back it up separately from the database, because losing it makes the stored credentials unusable.
  • Account ownership: Connect shared workflows through a service account where the vendor allows it. Otherwise, an employee's departure can break every workflow tied to their login.

Start with the credential list from your inventory. Register those apps before you rebuild, so slow approvals surface while Zapier is still running.

Mapping Zapier Filters, Paths, Formatter and Code steps to n8n nodes

Most Zapier logic has a clear n8n equivalent, so the concepts transfer more easily than the connections. The main difference is the data model. Zapier steps generally pass along one record per run, while n8n passes a list of items, and most nodes run once for each item.

Zapier step n8n equivalent What changes
Filter Filter or If node Filter drops items, while If sends them down a true or false branch
Paths Switch or If node Branches can rejoin through a Merge node
Formatter (text, numbers) Edit Fields node or inline expressions {{ $json.email.toLowerCase() }} replaces a whole step
Formatter (dates) Date & Time node or expressions Check time zones, as the instance and workflow settings affect results
Code by Zapier Code node Replace inputData and output with n8n's $input and returned items
Looping by Zapier Built-in item handling or Loop Over Items You often need no loop node, unless you are batching or pacing calls
Delay Wait node Waiting runs resume after a restart when their state is stored in the database

Three behaviours catch people during a rebuild. First, a node that returns 50 items makes the next node run 50 times, which can send 50 emails if you expected one. Use the Aggregate node when you want a single result. Second, a node that outputs zero items normally stops that branch, so a search with no match can silently end the workflow unless you enable Always Output Data. Third, Code nodes on self-hosted instances restrict imports by default, so allow any npm modules you need with NODE_FUNCTION_ALLOW_EXTERNAL.

How many hours does rebuilding each kind of Zap really take?

Nobody can give you a reliable universal figure, and we know of no independent benchmark worth quoting. The time depends on your familiarity with n8n, the quality of the vendor's API and how much undocumented behaviour your Zaps contain. What you can predict is the order of effort, from lowest to highest:

  • Tier 1, linear with native nodes: A trigger and 1 or 2 actions on mainstream apps. Work is mostly reconnecting accounts and remapping fields, and this tier is the cheapest once credentials exist.
  • Tier 2, logic-heavy with native nodes: Filters, branches and formatting across 5 or more steps. Effort goes into reproducing each condition and testing every branch, not just the most common one.
  • Tier 3, API-built integrations: At least one app needs the HTTP Request node. Add time for reading documentation, handling pagination and working out field IDs.
  • Tier 4, blocked by approval: The workflow is simple, but an OAuth app or vendor review is pending. Hands-on time may stay low while calendar time stretches well beyond it.
  • Tier 5, platform-dependent: The Zap relies on Tables, Interfaces or another Zapier-only feature. Estimate this as a small software project, because you are replacing a component as well as a workflow.

To get a number you can trust, timebox a pilot. Assign every Zap to a tier, then rebuild 2 from each of the first 3 tiers and log the time for building, testing and credential setup separately. Multiply each tier's average by its Zap count, and treat your first results as a ceiling for that tier only after you have rebuilt the second, since learning n8n inflates early timings. Add Tiers 4 and 5 as separate line items, each with its own estimate.

What replaces Zapier Tables, Interfaces and Storage?

n8n can replace some of these features directly, but others need a second self-hosted app. Choose the simplest replacement that fits how each feature is actually used, as these Zapier tools often do more than one job.

Zapier feature Replacement Tradeoff
Tables, as workflow memory n8n Data Tables Lives beside your workflows, but it is not a full collaborative database
Tables, edited by colleagues NocoDB or Baserow Spreadsheet-style editing and an API, but one more service to run and back up
Tables, with heavy queries PostgreSQL or MySQL nodes Powerful and durable, but you need to design a schema and write SQL
Interfaces, simple intake forms n8n Form Trigger Quick to build, with far less control over layout and multi-page apps
Interfaces, internal tools Appsmith or Budibase Closer to a real app builder, with a separate learning curve and deployment
Storage by Zapier Redis node or workflow static data Redis suits shared values, while static data suits small values within one workflow
Email by Zapier Send Email node with SMTP You must supply a mail provider and handle sender authentication

Migrate the data before you rebuild the workflows that depend on it. Tables can usually be exported as CSV, but check that linked records, field types and any stored record IDs survive the move. Formula or status fields may come across as plain values, so their logic has to be recreated.

Approval steps need separate thought. A workflow can pause on a Wait node and resume when someone follows its unique URL, which covers simple human sign-offs. If yours depend on role-based screens or audit trails, plan for an internal tool instead.

What does running n8n in Docker add to your workload?

The first start is the easy part: a single docker run command or a short docker-compose.yml can get n8n running. The workload that lasts is the operational work Zapier used to absorb. Expect these recurring jobs:

  • Persistent storage: Mount a volume at /home/node/.n8n, because that directory holds the default SQLite database and instance settings. Without it, recreating the container can wipe your workflows.
  • Database choice: SQLite is the default and suits small setups. PostgreSQL suits heavier production use, but it adds a second container to monitor, update and back up.
  • Updates: Pin a specific image version instead of tracking latest, then read the release notes before you upgrade. New versions can include breaking changes, so back up first and keep a route back to the previous tag.
  • Backups and restore tests: Back up the database, and export workflows if you want readable copies. A backup only counts once you have restored it to a separate instance and run a workflow.
  • Execution data growth: Saved runs can consume significant disk space. Review EXECUTIONS_DATA_PRUNE and EXECUTIONS_DATA_MAX_AGE, then choose a retention period that fits your debugging needs.
  • Scaling: One container handles many small workflows. If high volume starts to delay runs, queue mode adds Redis and separate workers, which increases both capacity and complexity.

Your hosting choice decides how many of these jobs stay on your list. A self-managed VPS, home server or NAS leaves the operating system, Docker and network setup with you. Yundera is a managed Personal Cloud Server, built on CasaOS, that installs self-hosted apps from an app store in one click rather than from hand-assembled compose files. Whichever you choose, workflow errors and retention decisions remain yours.

How do you run both platforms without firing every action twice?

Do not let both platforms perform the same live action at the same time. Instead, run n8n in shadow mode, with real triggers but harmless outputs, and move one workflow across at a time.

Before you begin, the instance needs a stable address so that you do not have to repoint senders and OAuth apps after testing. That could be a VPS with a reverse proxy, a home server or NAS with a tunnel, or Yundera. Yundera is a managed Personal Cloud Server, built on CasaOS, on which each app is reachable on a public HTTPS subdomain via NSL.SH mesh routing.

Then follow this cutover pattern:

  • Shadow outputs: Point n8n's final actions at a test Slack channel, a sandbox CRM account or a logging table. Compare those results with what the Zap actually did over the same period.
  • Webhook fan-out: If a sender allows only 1 destination URL, keep Zapier as the receiver for now and add a Webhooks by Zapier POST step that forwards the payload to n8n.
  • Duplicate protection: Add n8n's Remove Duplicates node, keyed on a stable value such as an order ID. It can skip events already processed in earlier runs, which protects you when a sender retries or an overlap occurs.
  • Clean polling cutover: Note the switch time, turn off the Zap, then activate the n8n workflow. Afterwards, look for records created during the gap and handle them by hand.
  • Reversible retirement: Turn off each Zap without deleting it. Keep the subscription through at least 1 full business cycle, including any month-end or quarterly workflows, so that you can switch back quickly if something fails.

Start with low-risk notifications, and move customer-facing or payment workflows last.

Error handling and retries after Zapier stops doing it for you

Zapier gives you Zap history, failure notifications and, on eligible plans, automatic replay of failed steps. n8n has comparable tools, but you must configure most of them. An unconfigured workflow can simply fail and record the failure in its execution list, where nobody will see it unless they look.

Need Zapier Self-hosted n8n
Automatic retries Autoreplay, where your plan includes it Retry On Fail, enabled in each node's settings, with tries and wait time
Failure alerts Built-in notifications An Error Trigger workflow, assigned in each workflow's settings
Continuing after an error Custom error handling on supported plans On Error setting, including a separate error output branch
Rerunning failures Replay from Zap history Retry from the Executions list
Forced failures Limited, usually through a Filter or Code step Stop And Error node with your own message
Platform health Zapier's responsibility Your monitoring, such as Uptime Kuma polling /healthz

Two gaps deserve particular attention. First, an error workflow runs inside n8n, so it cannot tell you when the whole instance is down. External monitoring has to cover that case, ideally from a different machine. Second, retries can repeat side effects. If a request created an invoice but timed out before the response arrived, a blind retry can create a second invoice. Use an idempotency key where the vendor supports one, and limit automatic retries on non-idempotent actions.

Build one shared error workflow that posts the workflow name, failed node, error message and execution link to a channel someone actually reads. Then assign it to every production workflow as part of your cutover checklist, since n8n has no alert path until you set one up.

Who should migrate now, who should wait and who should stay on Zapier?

Your Zap count matters less than who will maintain the result and how many of your Zaps fall into the harder tiers.

Profile Recommendation Main reason
Freelancer with mostly Tier 1 Zaps Migrate now Short workflows on mainstream apps are the cheapest to rebuild
Developer with webhook-heavy Zaps Migrate now Webhooks and APIs are already familiar ground
Team with a technical owner and growing workflows Migrate in phases Someone can own updates, alerts and restore tests
Agency using niche connectors Wait for the audit Each missing node adds API work
Team awaiting OAuth approvals Wait Vendor reviews set the timeline
Operations group built on Tables and Interfaces Wait or stay You must replace applications as well as workflows
Business with sensitive customer data Pilot first Control helps only if you can also secure the server
Non-technical owner without support Stay on Zapier Nobody would own failed runs or backups

Next steps

Migrate now:

  1. Deploy n8n and test a restore.
  2. Rebuild 1 low-risk Zap and run it in shadow mode.
  3. Move the remaining Zaps in order of risk.

Wait:

  1. Assign every Zap to a tier.
  2. Submit OAuth applications and resolve missing-node questions.
  3. Timebox a pilot of 2 Zaps per tier, then decide.

Stay:

  1. Document who owns each Zap.
  2. Export your Tables data periodically.
  3. Revisit the decision if your Zapier bill, data rules or in-house skills change.

A mixed setup is also legitimate. Keeping 1 or 2 Zaps that have no practical n8n route can be better than building a fragile replacement just to finish the migration.

Data sovereignty: what self-hosting n8n changes and what it does not

Self-hosting moves the automation layer onto infrastructure you choose. It does not remove the vendors from your data flow: a workflow that sends customer records to Slack, HubSpot or an AI API still shares them with those vendors.

Advantages:

  • Execution data location: Payloads and run history stay in your database instead of Zapier's platform.
  • Retention control: You decide how long runs are kept, and EXECUTIONS_DATA_SAVE_ON_SUCCESS=none can stop saving the details of successful runs.
  • Credential custody: API tokens stay encrypted in your instance instead of with another automation vendor.
  • Hosting location: You choose the jurisdiction, whether that is a VPS in a specific region, a home server, a NAS or Yundera. Yundera is a managed Personal Cloud Server, built on CasaOS, that lets the user keep their data on their own server rather than in a shared multi-tenant service.

Checklist:

  1. Map every destination: List the external services each workflow sends data to, because they remain part of your compliance picture.
  2. Check outbound connections: n8n can contact external services for diagnostics, version notifications and templates. Review settings such as N8N_DIAGNOSTICS_ENABLED, then confirm the result with your own network monitoring.
  3. Lock down the editor: Require strong logins, keep the instance patched and expose only the paths you need.
  4. Secure your backups: Database dumps can contain customer payloads, so encrypt them and limit their retention.
  5. Review legal duties: Laws such as the GDPR still apply. Self-hosting removes one processor, but your security and breach-response obligations remain.
  6. Read the licence: n8n's Sustainable Use License has terms of its own, so check them if you use n8n for clients or inside a product.

Key points: the Zapier to n8n rebuild at a glance

Moving from Zapier to self-hosted n8n means rebuilding your automations and taking over their operation, so your dependencies and available maintainer should drive the decision.

Point Details
Import path Expect to rebuild each Zap, since n8n has no native importer for them
Biggest risks Missing nodes, Zapier-only features, OAuth registration and inbound webhook addresses
Effort estimate Sort Zaps into 5 tiers, then time a pilot of 2 Zaps from each of the first 3
Safe cutover Use shadow outputs, Remove Duplicates and one-at-a-time switching, keeping Zapier through 1 full business cycle
New responsibilities Updates, tested backups, N8N_ENCRYPTION_KEY custody, error workflows and external monitoring
Limits of sovereignty Execution data moves to your server, but connected vendors still receive what you send them

Zapier deserves a fair hearing here. Its connector catalogue is broader, non-technical colleagues can usually build on it without help, and when its platform fails, someone else is responsible for fixing it. Those are real benefits, and a subscription can be cheaper than the staff time a poorly planned migration consumes.

In our judgment, n8n wins when you have a technical owner, workflows with real logic and a reason to control where execution data lives. Its item-based model and direct API access reward people who are comfortable thinking about data. Without that owner, we would stay on Zapier, and we see nothing wrong with that.

Start with the audit, because it costs little and commits you to nothing. Rebuild one low-risk Zap and restore one backup. If both go smoothly, you have earned the next step. If not, you have learned that cheaply.

Top comments (0)