Every workflow tool comparison ranks the same four axes - connector count, pricing, ease of use, AI features - and skips the one that determines whether you can live with the choice: where the workflow actually executes.
There is a real fork in this market, and it is not between the tools people usually compare. It is between automation that runs on someone else’s infrastructure with your credentials, and automation that runs on infrastructure you control. Everything else is a detail.
Table of contents
- The axis the comparison tables leave out
- Three shapes of tool
- How the pricing models actually bite
- What self-hosting actually costs you
- A short decision procedure
- How this fits the rest of the stack
- FAQ
The axis the comparison tables leave out
Connector count is the headline number in every roundup, and it is close to meaningless past a certain point. Nobody uses eight thousand integrations. You use six, and the question is whether those six are good rather than whether there are eight thousand mediocre ones.
The genuinely load-bearing question is execution location. When your workflow fires, does the data pass through a vendor’s servers, or does it stay inside infrastructure you own? That single fact determines your compliance story, your credential blast radius, your latency, and whether your automation bill scales with usage or with compute.
It also determines what happens when the workflow breaks at 2am, which it will. On a hosted tool you read the vendor’s execution log and file a ticket. On self-hosted you read your own logs and fix it. Neither is strictly better; they are different failure modes and you should pick one deliberately.
Three shapes of tool
- Hosted no-code. Drag-and-drop, enormous connector catalogues, per-task or per-run pricing. Excellent for connecting SaaS products where the data was already in the cloud. The pricing model punishes high-volume workflows, sometimes dramatically.
- Self-hostable low-code. Node-based editors that you can also run yourself in a container. You bring the infrastructure and get to write real code in a node when the visual editor runs out. n8n is the widely-used example here.
- Code-first orchestrators. Airflow, Prefect, Argo, Temporal. Workflows are code in a repository, versioned and reviewed like anything else. Steep setup, and the correct answer for data pipelines and anything with complex retry semantics.
Teams get into trouble by picking from the wrong shape. A data pipeline built in a hosted no-code tool becomes unmaintainable around step twenty. A three-step Slack notification built in Airflow is a joke at your own expense.
How the pricing models actually bite
Hosted tools generally charge per task, per run, or per operation. That is fine when a workflow fires forty times a day. It becomes a problem when someone wires it to a webhook that fires on every record change, and the bill triples in a month nobody was watching.
Self-hosted tools charge you for compute, which is boring and predictable. A workflow that fires ten thousand times costs the same as one that fires ten, until you actually need a bigger container. The trade is that you now own an upgrade path, a backup, and a database behind it.
The break-even is usually lower than people expect. If you are running high-frequency workflows - anything triggered by webhooks rather than schedules - the self-hosted option often wins on cost within the first few months, and it wins on control immediately.
There is a subtler cost too. Hosted tools hold your credentials. Every API key for every system the workflow touches lives in someone else’s database. That is a perfectly normal thing to accept, and it is a decision worth making on purpose rather than by default.
What self-hosting actually costs you
Being honest about the other side: self-hosting an automation tool is not free. It needs a container that stays up, a Postgres database for execution history, environment variables for credentials, TLS on a domain, backups, and a plan for upgrades that do not lose your workflows.
That is a real list, and it is the reason plenty of teams stay on hosted tools despite the pricing. The list gets much shorter when the tool is deployed as a managed service rather than as a server you administer - the container, the certificate, the database, and the logs stop being separate projects.
The thing worth protecting is the middle position: your workflows and your credentials on your infrastructure, without you personally becoming the operator of a Docker host. That combination is where most small teams should land, and it is more available now than the roundups suggest.
A short decision procedure
- Count the workflows you actually need and how often they fire. Under a hundred runs a day of pure SaaS-to-SaaS glue: use a hosted tool and stop reading comparisons.
- Check whether any workflow touches data you would rather not hand to a third party - customer records, internal databases, anything under a compliance regime. If yes, self-hostable is the shortlist.
- Check whether any workflow needs custom code. If you can already see the JavaScript you would write, pick something with a code node rather than fighting a purely visual editor.
- Decide who operates it. If the answer is nobody, use hosted or use a managed deployment of a self-hostable tool. Do not pick self-hosted and then hope.
Most teams answer yes to steps two and three, which is why the self-hostable middle has grown so quickly. The reason they hesitate is step four, and step four is a hosting decision rather than a tooling one.
How this fits the rest of the stack
The tool comparison is the easy half; the operating cost is the half that decides whether the choice sticks. If self-hosting is on the table, the RunxBuild hosting calculator shows the container, the database behind it, and the bandwidth as separate line items so the comparison against per-task pricing is a real one. RunxBuild runs n8n as a managed tool - its own plan, custom domain, environment variables, autoscaling, and logs - with a managed Postgres beside it, starting from a $6 Basic plan.
Useful related references:
- Workflow Builders: What They Replace and Where They Stop
- n8n Workflow JSON: The Structure, and How to Edit It by Hand
- Coding Agents in 2026: The Real Cost, the Real Runtime, and the Real Workflow
- Services on RunxBuild
FAQ
What is the best workflow automation tool?
There is no single answer because the tools split into three shapes: hosted no-code for SaaS-to-SaaS glue, self-hostable low-code for teams that want their data and credentials on their own infrastructure, and code-first orchestrators for data pipelines. Pick the shape first; the tool within a shape matters much less.
Is self-hosting a workflow tool worth it?
It is when workflows fire frequently enough that per-task pricing hurts, or when they touch data you would rather not hand to a third party. The cost is that you now own a container, a database, certificates, backups, and upgrades - unless you deploy it as a managed service, which removes most of that list.
How many integrations do I actually need?
Usually about six. Connector count is the headline number in every comparison and it stops mattering once your specific systems are covered. Check that your six are well built rather than that the catalogue is large, and check whether there is an HTTP request node for everything else.
What is the difference between a workflow tool and an orchestrator?
Workflow tools are event-driven glue between applications, usually built visually. Orchestrators like Airflow or Temporal run code-defined pipelines with strong scheduling, dependency, and retry semantics. Use a workflow tool for business automation and an orchestrator for data pipelines; swapping them makes both jobs harder.
Can I move workflows between tools later?
Rarely without rewriting them. Workflow definitions are proprietary formats and there is no meaningful portability standard. Self-hostable tools at least let you keep running the old version indefinitely, which turns a forced migration into a scheduled one.