What workflow automation is — and the question that comes next
Up front, the definition, so we can get it out of the way: workflow automation means a recurring business process runs without manual intervention, step by step, by fixed rules. An example: an invoice arrives by email, a workflow extracts the data, files the PDF, triggers the approval, and hands over to accounting. No human copies numbers from one system into another along the way.
Two neighboring terms, one sentence each: RPA (Robotic Process Automation) simulates clicks on user interfaces when a legacy system has no API. BPM (Business Process Management) is the discipline above it: modeling, measuring, and improving processes, with automation as one of the tools.
If you search for "workflow automation", you will find this definition in ten variations: Atlassian, IBM, and Automation Anywhere all explain to you what automation is.
What none of these corporate guides answer are the questions that come next in your project: Where do your data run? Who operates the tool, and under which license terms? What does a workflow really cost once you add up tasks, credits, and server costs? And when is the no-code builder no longer enough?
This article settles exactly these four questions: with dated prices, the license trap around the most popular tool n8n, and an honest answer on the cases where you need neither self-hosting nor an agency.
Takeaway: The question is no longer whether you should automate. The question is where your workflows run and who operates them.
Task, credit, execution: the pricing logic of Zapier, Make, and n8n
I will spare you the ninth "n8n vs. Make vs. Zapier" feature comparison; enough of those exist. The billing logic matters more: it decides which tool stays affordable at your volume, and the three vendors count different things.
Three vendors, three ways of counting
Zapier counts tasks: every successfully executed action costs one task. Triggers and built-in helper steps such as filters or formatters do not count; some AI steps count multiple times instead. A workflow with five counting actions therefore uses five tasks per run. The Professional plan starts at $19.99 per month for 750 tasks with annual billing; billed monthly it is $29.99 (zapier.com, retrieved August 18, 2026).
Do the math: 750 tasks at five counting actions per workflow means 150 runs a month. For serious process volumes, this logic gets expensive fast.
Make counts credits: since the pricing-model change, every module action costs one credit, and heavy actions cost several. The Core plan starts at $9 per month for 10,000 credits (make.com, retrieved August 18, 2026). That is far more headroom than Zapier, but the base logic stays the same: complex workflows with many steps eat your quota disproportionately.
n8n counts executions: a complete workflow run costs one execution, whether it has three steps or thirty. n8n Cloud Starter costs €20 per month for 2,500 executions, Pro €50 for 10,000, both with annual billing; billed monthly it is €24 and €60 respectively (n8n.io, retrieved August 18, 2026).
Add to that the Community Edition: self-hosted, free, with an almost complete feature set. For multi-step processes, the execution logic is the most predictable: your price depends on the number of business events, not the number of steps per event.
A worked example: 500 invoices a month
A worked example makes the difference tangible: say you automate your invoice intake with a workflow that runs eight counting actions per invoice, at 500 invoices a month. On Zapier that is 4,000 tasks, well beyond what the Professional entry plan covers.
On Make it is roughly 4,000 credits, comfortably within the Core plan. On n8n it is 500 executions, one fifth of the smallest cloud plan. The more steps your processes have, the more the math shifts toward n8n.
The pricing tables do not answer the question that should come before cost in a mid-sized company, though: where your data are processed in all of this.
Where your data run: third-country transfer as a due-diligence duty
As soon as a workflow moves personal data, and almost all of them do (customer names, email addresses, invoice data), the place of processing becomes a GDPR question. Blanket verdicts like "US tools are forbidden" will not help you here, so I differentiate by vendor:
Make is an EU company headquartered in Prague and, according to its own pricing page, hosts on AWS in the EU or in North America (make.com, retrieved August 18, 2026). If processing stays in the EU region, this is the least complicated SaaS option of the three from a third-country-transfer perspective: clarify in the data processing agreement which region applies to your account.
Zapier is a US vendor and processes in the United States. That is not a knockout criterion: the transfer can be addressed legally via standard contractual clauses and the EU-U.S. Data Privacy Framework.
But it is a due-diligence duty, not a formality: you need a data processing agreement, a documented transfer assessment, and a look at every connected app. I have described how to structure such an assessment in the practical guide to GDPR-compliant AI: the method is the same, whether AI service or automation platform.
Regardless of vendor, one thing holds: an automation tool is a processor with far-reaching access, because the credentials in your workflows hold logins to your CRM, accounting, and mailbox. So keep a register of which workflow moves which data categories: this inventory is the foundation of every privacy assessment, and for ten workflows it takes an afternoon, not a project.
n8n, self-hosted, shifts the question entirely: if the instance runs on your server with an EU provider such as Hetzner, the platform itself causes no third-country transfer at all. Your data leave your infrastructure only where you explicitly configure it, for example when a workflow calls a US API. That is exactly why self-hosting is our default route for processes with sensitive data: HR data, health data, financial data.
Takeaway: It is not the vendor's logo that decides your data protection, but the place of processing — and only with self-hosting do you control that entirely yourself.
The operating model: n8n on your infrastructure
Here is where many agency offers fall apart legally. n8n is licensed under the Sustainable Use License. It permits use "for your own internal business purposes or for non-commercial or personal use", and distribution only free of charge for non-commercial purposes (n8n LICENSE.md, retrieved August 18, 2026).
The n8n Help Center spells this out explicitly: consulting, setup, and maintenance on the customer's server are allowed. Anyone who instead hosts their customers' workflows and credentials permanently on their own agency instance and charges money for it needs a commercial license from n8n.
For context: this is not harassment but the business model behind the tool. n8n calls it fair-code: the source code is open and internal use is free, but whoever earns money with the product itself should share with the maker. For you as a customer, the distinction is decisive nonetheless, because an agency instance without a commercial license is a contractual risk you are buying into.
So if someone sells you "n8n hosting included" on agency servers, ask about the license. Our model is therefore consistently a different one: n8n runs on your infrastructure, set up and maintained by us. The instance belongs to you, the credentials stay with you, the workflows are your property. We come to your server as a service provider; your data do not come to ours.
What "set up and maintained" covers in practice, in three layers: Setup: provisioning a server with your provider (typically Hetzner), deployment via Docker, HTTPS, access protection, automatic backups. Operations: regular updates (n8n releases at a high cadence, and unpatched instances with stored credentials are a real risk), backup checks, monitoring with alerting, and credential hygiene: credentials are granted on a least-privilege basis and rotated. Evolution: new workflows, error analysis, adjustments when a connected API changes.
The most important side effect of this model: no lock-in. If you end the engagement, your instance simply keeps running. You lose a service provider, not your automation. What the model looks like in detail and what it costs is on our process automation page.
The honest cost calculation
What does n8n on your own infrastructure really cost? Let us run the numbers transparently, with dated prices and a formula instead of a flat figure.
The software: €0. The Community Edition is free and covers almost the full feature set (n8n.io, retrieved August 18, 2026). The server: for typical mid-sized workloads, a small cloud server is enough, at Hetzner for example the CX23 with 2 vCPU, 4 GB RAM, and 40 GB SSD: a single-digit euro amount per month, plus €0.50 net for the IPv4 address (docs.hetzner.com, retrieved August 18, 2026; hetzner.com shows the current server price, cloud prices change).
The maintenance: the honest line item that cost examples like to leave out. Updates, backups, monitoring, and credential care are work. As a rule of thumb from our projects: a stable instance with a handful of workflows takes one to three maintenance hours per month, less in quiet months, more after a breaking-change update.
Against that stand the managed options: n8n Cloud Starter at €20 per month with 2,500 executions, Pro at €50 with 10,000 executions, and for larger organizations the Business plan at €667 per month with a self-hosted option, SSO/SAML, and 40,000 executions (n8n.io, retrieved August 18, 2026).
In numbers, for a concrete scenario: the server costs under €10 per month, plus two maintenance hours. Apply an external hourly rate and you land at €200 to €400 monthly depending on the provider; if your own IT handles it on the side, it is essentially the server cost plus internal time. That is exactly why there is no serious flat answer, only a formula with your values.
The break-even as a formula rather than a flat figure: self-hosting pays off when server costs plus maintenance hours times hourly rate come in below the cloud plan of your volume tier, or when your data-protection requirements rule out the cloud options anyway.
Radically honest at this point: for a small setup with non-critical data, n8n Cloud wins on the numbers, because €20 per month undercuts any professionally maintained instance of your own. The math flips in three cases: at high volume (execution tiers disappear entirely with self-hosting), with sensitive data, and where your own infrastructure including an IT owner already exists.
When Make is enough anyway
Now the chapter that agency blogs usually skip: the cases where you need neither n8n nor us. Make (or Zapier, for that matter) is enough when four conditions hold at the same time.
Low volume: a few hundred events a month, no load spikes. The Core plan's 10,000 credits for $9 cover that (make.com, retrieved August 18, 2026). Pure SaaS coupling: you connect standard tools such as CRM, Slack, and spreadsheets, without wiring in systems of your own or legacy software.
No sensitive data: no HR, health, or financial data flow, and Make's EU hosting satisfies your privacy assessment. No in-house IT: nobody in the company wants to, or should, be responsible for a server, not even an externally maintained one.
If all four hold, self-hosting is plain overhead: you would be paying maintenance for a problem you do not have. Build the workflows in Make, document them properly, done.
If one of the conditions tips, the picture changes: as volume grows, credit costs climb month after month. If a legacy ERP system joins, you need webhooks and logic of your own. If HR data enter the picture, you want to bring processing in-house.
The usual path for our customers is therefore not either-or but a sequence: start with the SaaS builder, learn to understand your own processes, and move to your own instance at the first hard criterion. The workflow definitions do not export one to one, but you take the process knowledge with you completely, and it is the more valuable part.
The limits of low-code: when custom ETL becomes necessary
n8n is an orchestration tool, not a general-purpose development system. There is a line beyond which a visual workflow becomes a liability, and you recognize it by four criteria.
Data volume: n8n processes data in the instance's memory. Tens of thousands of records per run, large files, bulk synchronization between systems: a chain of visual nodes is not built for that. Error handling: a builder retry repeats a failed step. What it cannot do: cleanly roll back partial successes, resume idempotently, detect duplicates on re-delivery. As soon as a process books money or changes stock levels, you need exactly these semantics.
Tests and versioning: workflows live as JSON in the instance's database. Code reviews, automated tests, and clean deployments across test and production environments are doable with discipline, but you are working against the tool. Grown logic: as soon as real business logic accumulates in several function nodes, you are programming without a development environment: no types, no tests, no debugger.
Important here: the line is not an argument against n8n, but a question of division of labor. The mistake we keep correcting in projects is not "too much low-code" but the attempt to solve everything in one paradigm: either a hundred nodes in one unmaintainable giant workflow, or a fully handwritten solution where nobody but the developer can still see what the process actually does.
Our pattern for these cases: n8n as orchestrator, TypeScript as worker. The workflow remains the visible backbone with triggers, notifications, and approvals. The heavy work is done by a dedicated service with tests and version control, which n8n triggers via webhook.
An example from our project work: a customer synchronizes product data from several source systems. The first attempt as a pure n8n workflow failed on error handling during partial outages of individual sources. Today n8n triggers a TypeScript ETL pipeline that validates, transforms, and selectively re-runs failed records one by one. The workflow stayed; the logic moved. How we build services like this is on our custom software development page.
AI in the workflow: from text node to RAG connection
The second reason n8n is getting so much attention right now: the built-in AI connection. Through AI nodes, a workflow calls a language model and uses it as one step among many: classifying emails, extracting invoice data from PDFs, drafting replies. This is the pragmatic entry into AI automation, because the model sits inside a controlled process: validation before, human approval after. Exactly this control separates a usable AI workflow from flying blind.
The next expansion step is a knowledge base. A workflow that is supposed to pre-qualify or answer customer inquiries needs access to your documents: quotes, manuals, contracts.
For that, we couple n8n to a RAG stack on PostgreSQL with pgvector, in our projects usually on Supabase: your documents live as embeddings in your own database, and the workflow fetches the matching passages and hands them to the model as context. Why this route almost always comes before training a model of your own is explained in detail in the article RAG vs. fine-tuning.
And the agents? Autonomous AI agents that decide for themselves which steps to take are the big platform promise of the year. My sober assessment: for most business processes, a deterministic workflow with individual AI steps remains the better choice, because it is traceable and testable.
I have written up the distinction in the guide to agentic AI. And how you prioritize AI initiatives beyond individual workflows is covered in the guide to adopting AI in your company.
Typical first workflows in mid-sized companies
In case you are still looking for the entry point: these four processes show up most often as the first automation in our projects, because they are clearly scoped and bring immediate, tangible relief.
Invoice intake: monitor the mailbox, extract the attachment, read the data via AI, store it in the filing system, send an approval message to accounting. The classic, because the process looks almost the same in every company and the manual effort is directly measurable in hours.
Lead routing: enrich form inquiries with company data, assign them to the right salesperson by rules, create the CRM record, generate a first-contact task. Cuts response time from days to minutes, and in B2B sales, response time decides.
Onboarding: setting up new employees or customers often means eight systems, a checklist, and three weeks of waiting. A workflow creates accounts, distributes tasks, and reports progress in one place. Report distribution: collect figures from ERP and analytics, assemble a weekly report, send it to management. Unspectacular, but an hour saved every week and a report that is never forgotten.
Which of these processes comes first for you is not a tool question but a short effort-benefit review: How often does the process run? How much manual work is in each pass? How expensive is a mistake today? With this list in mind, an abstract "we should automate at some point" turns into a concrete candidate list with an order.
One piece of advice from experience for the start: do not pick a process with money or deadlines attached as your first workflow. The first workflow is your learning project; on it you discover where your data quality falters and which edge cases really exist. Report distribution is ideal for that: if it fails, a report is missing. If the automated invoice process fails, a payment is missing.
Next steps
If you have read this far, you know the four answers the big platform guides owe you: the billing logic decides your costs, the place of processing decides your data protection, the license decides the operating model, and the low-code line decides when custom development becomes necessary.
Here is how we proceed if you want to tackle the topic: in a first conversation, we look at your two or three most annoying processes and check honestly whether a SaaS builder is enough or an n8n instance of your own is the right route. Afterwards you get a recommendation with concrete numbers for your volume: no license surprises, no lock-in, and if Make is enough for you, we tell you exactly that.
The details on our operating model and the packages are on the process automation page. Or take the shortcut: book 30 minutes with me, we go through your process list together, and by the end you know whether automation pays off for you and in which operating model it should run.
