Surface
Choosing automation tooling by brand familiarity is how teams end up with three overlapping Zap sprawls, a forgotten self-hosted box, and a half-migrated service in the monolith. The useful question is which *runtime* fits the constraint: hosted SaaS connectors, self-hosted n8n, or custom code inside your product. Logos are marketing. Runtimes have failure modes.
This piece assumes you already passed the filter in when n8n automation is worth it. You have a handoff worth automating. Now pick where it runs.
Three runtimes, three jobs
Hosted SaaS automation (Zapier-class and peers) optimizes for speed to first integration and a large connector catalog. You trade control of data plane, pricing at volume, and deep custom logic.
Self-hosted n8n optimizes for control: where data lives, how credentials are stored, custom nodes, and cost curves when execution volume rises. You trade operational burden: upgrades, backups, access control, and monitoring.
Custom code optimizes for product-grade behavior: tests, typed contracts, deploy pipelines, SLAs, and UX that is the product. You trade build time and ongoing engineering ownership.
None of these is universally "best." Mixing them without a rule creates the sprawl.
Pick the runtime by constraint
Hosted SaaS
Speed to glue
Watch: Cost + lock-in at volume
Self-hosted n8n
Control + custom nodes
Watch: Ops ownership required
Product code
Core UX + hard SLAs
Watch: Engineering lead time
Insight: choose the runtime for the constraint you cannot negotiate (data boundary, cost curve, or product SLA), not for the template gallery.
Numbers that change the conversation
Use these as planning inputs, not as vendor scorecards:
| Dimension | Hosted SaaS (typical pattern) | Self-hosted n8n | Product code |
|---|---|---|---|
| Time to first useful glue | Hours–days | Days (plus host setup) | Weeks for a durable service |
| Cost shape | Per task / per seat, steep at high volume | Infra + operator time | Eng salary + maintenance |
| Review / versioning | Often light | Possible with export/Git discipline | Native PRs + CI |
| Data plane control | Vendor region + policy | Your VPC / host | Your stack |
| Fit for core UX SLA | Poor | Risky | Best |
A practical volume heuristic we use when advising teams: if a glue path is heading toward tens of thousands of executions per month with non-trivial custom logic, model hosted task pricing against a small always-on n8n host before you "just keep adding Zaps." The break-even point moves with vendor pricing; the discipline of modeling it does not.
McKinsey's research on tech modernization keeps repeating a related lesson: tools without operating model changes under-deliver. Automation runtimes are the same. A canvas without change control is not a platform.
Decision table
| Dimension | Hosted SaaS automation | Self-hosted n8n | Custom code in the app |
|---|---|---|---|
| Time to first workflow | Fastest | Fast for API-friendly glue | Slowest initially |
| Data residency / network control | Limited | Strong if you operate it well | Strong |
| Cost at high execution volume | Often steep | More predictable infra + ops | Engineering time dominated |
| Secrets and credential hygiene | Vendor features + your discipline | Your vault, your policies | Your vault, your policies |
| Versioning and review | Often light | Possible with export/Git discipline | Native (PRs, CI) |
| Custom logic / odd APIs | Constrained | Strong (code nodes, custom nodes) | Strongest |
| Vendor lock-in | High on connectors and history | Medium (workflows portable with work) | Low on the workflow itself |
| Fit for core product UX | Poor | Risky | Best |
When self-hosted n8n earns its keep
Choose self-hosted n8n when several of these are true:
- Data residency, VPC, or private network access matters
- You need custom nodes or heavy transformation that SaaS plans punish
- Execution volume would make per-task SaaS pricing uncomfortable
- Ops can own upgrades, backups, and access roles honestly
Self-hosting is not "free n8n." It is a small platform. If nobody will patch it, you have bought a liability with a friendly UI.
When hosted SaaS is enough
Hosted automation is fine for low-to-moderate volume glue, teams without appetite for infra, and workflows that are clearly disposable experiments. Treat them as experiments with an exit criteria: graduate, delete, or rewrite when they touch money, customers, or regulated data in ways the vendor boundary cannot satisfy.
When product code should own the workflow
Ship in code when:
- The path is customer-facing and part of how you sell trust
- You need strong idempotency, transactional guarantees, or complex state machines
- Multiple teams must review changes through normal engineering process
- Latency and SLAs are product promises, not ops conveniences
A useful graduation signal: the workflow is discussed in product reviews more than in ops standups. That is when canvas debt starts costing more than a service.
For staffing the build itself, the same ownership questions appear in staff augmentation vs dedicated team and MVP build vs hire engineers: who will maintain this after the first ship matters as much as who can demo it this week.
A practical sequencing rule
1. Prove the handoff with the lightest runtime that clears security and data constraints 2. Instrument failures and ownership from day one (see production failure modes) 3. Graduate to code when the workflow becomes product, not when someone gets bored of the canvas
Where AI fits in the choice
LLM steps do not change the runtime decision by themselves. They change the risk profile inside whichever runtime you chose. Keep AI nodes narrow; we cover that in AI inside n8n. Unbounded "agent" loops belong in carefully designed product workflows, not as a default Zap.
If you are weighing delivery partners for integration-heavy work, start from how we work rather than from a vendor logo on a comparison blog.
