'Which automation platform is better — n8n or Make' is a malformed question. They have different deployment models, different architectures, different economics, and different scenarios where one beats the other. This piece covers the 12 parameters where the choice actually diverges, and four typical PR scenarios with a concrete verdict for each. Every Kelva workflow product — Media Comment Generator, Case Study Generator, Tender Docs App — is built on n8n, so our position is clear, but the reasoning is honest.
What we're comparing, and for whom
Let's fix the context up front — this is a comparison for PR and creative agencies, not enterprise IT. What that means:
- Teams of 5–50 people; a tooling budget in the low thousands of dollars a month, not the tens of thousands
- Workflows — handling media requests, generating comments, preparing case studies, monitoring mentions, syncing the CRM
- No dedicated DevOps team; either one tech lead, or all technical support sits with an external contractor
- Data protection (GDPR, SOC 2) is a constant backdrop, especially when client data enters the workflow
In that context, n8n and Make are both workable. Each covers most scenarios, but the architectural differences set different ceilings and a different cost of ownership 6–12 months out.
The 12 comparison parameters
| # | Parameter | n8n | Make |
|---|---|---|---|
| 1 | Deployment model | Self-hosted (Docker, your VPC/GCP/AWS) or Cloud | Cloud SaaS only |
| 2 | Data residency for workflows with client PII | Covers it (self-hosted in your own boundary) | Doesn't — data goes to the vendor's region |
| 3 | Billing | Per-execution on n8n.cloud / fixed on self-hosted | Per-operation (every step is a meter) |
| 4 | Barrier to entry | Higher — you need to stand up an instance or deploy Docker | Lower — sign up and you're in the editor |
| 5 | Visual editor for a non-engineer | Good, but local-only without cloud share | More polished, natively cloud-shared |
| 6 | Custom integrations | HTTP node + JS code or a custom node | HTTP module + limited inline JS |
| 7 | Workflow versioning | JSON export → git (our pattern) | Snapshot inside the platform |
| 8 | Local development / testing | Full — n8n runs on a laptop | None — cloud only |
| 9 | Limits per workflow | Effectively none (instance RAM/CPU) | Hard operations/min caps by plan |
| 10 | Webhook endpoints | Your own domains + basic auth | Vendor domains, Bearer tokens |
| 11 | Log history | Self-hosted — as much as the disk holds | 7–30 days depending on plan |
| 12 | Vendor lock-in | Low (JSON export, open-source core) | High (snapshots inside the platform) |
The main architectural watershed is points 1–2 (self-hosted vs cloud) and point 12 (vendor lock-in). Everything else is shading. If your workflows touch client PII, or you want a migration guarantee, choose n8n. If there's neither PII nor a long-term migration concern, Make is often faster in the first months.
Four typical scenarios
Paper comparisons are useful, but decisions get made on concrete tasks. Four scenarios where we've seen both platforms in production, and a verdict on each.
Scenario 1. Monitoring client mentions in the press
Take a keyword list, query a media aggregator, filter for relevance, push to the client's Slack/Telegram channel and/or Notion.
What's involved: Runs 4–6 times a day. Data — public mentions, not PII. Volume — dozens to hundreds of mentions a day.
Make wins. Simply because the workflow is generic, there's no PII, and Make has native integrations with most aggregators out of the box. Startup cost and time-to-production are lower.
n8n works. If you already have n8n infrastructure running for other workflows, adding one more is trivial.
Scenario 2. Generating spokesperson comments for media
A request arrives from a publication → gather context on the topic → pick a spokesperson → draft a comment with a quote → clear it with the spokesperson → send to the editor.
What's involved: Runs a few times a week. Data — the spokesperson's name, their company, title, quotes (all of it personal data, plus client data depending on the company). Volume — 10–30 comments a week at a large agency.
n8n, strictly. A prompt carrying the spokesperson's name, title, and company is PII processing. Routing it through a cloud-only SaaS means processing in a region you don't control, which breaks your data-residency commitments under GDPR/SOC 2. Self-hosted n8n inside your own boundary closes the requirement. This isn't "n8n is more convenient," it's "Make is legally off the table."
This is the scenario we built the Media Comment Generator for — inside an n8n workflow, with an LLM (Gemini or a self-hosted open model) wired in.
Scenario 3. Syncing HubSpot ↔ Notion ↔ Slack for a sales team
A lead lands in HubSpot → create a matching Notion page from a template → notify the owner in a Slack channel → update status across the lifecycle.
What's involved: Runs dozens of leads a week. Data — lead contact details (PII). Volume — small.
Make wins. The native HubSpot, Notion, and Slack integrations are well polished. Startup cost is minimal. But: lead PII in Make means moving it to the vendor's region. Whether that's acceptable depends on your compliance posture and where your data subjects are based.
n8n is the safer call for a mixed audience. If your leads span multiple jurisdictions with conflicting residency rules, self-hosted n8n keeps both perimeters covered. Universal solution, higher barrier to entry.
Scenario 4. Producing a large agency case study with AI
Sources — emails, call transcripts, team notes, client materials. Assemble into one document. Run through an LLM for storytelling. Format into Google Docs. Hand to the editor.
What's involved: Runs 2–4 times a month. Data — confidential client materials, potentially with PII. Volume — large per single workflow run (dozens of sources, thousands of tokens in the prompt).
n8n, the only option. You can't send client materials into a third-party cloud — one. The operation count per run approaches Make's plan limits — two. n8n's flexibility in composing prompts and handling sources is substantially greater — three.
This is the scenario we built the Case Study Generator for — n8n + a self-hosted LLM or managed API, all inside your own boundary.
When Make is the right call
So that "always n8n" doesn't read as bias — three scenarios where Make is objectively better:
- A simple integration between 2–3 public SaaS tools with no client PII. Skipping Make for n8n here is over-engineering that spends the team's time on infrastructure instead of the product.
- A team with no technical support at all. Make has a more polished UX and fewer edge cases requiring the CLI. If nobody inside the agency can stand up a Docker container, n8n turns into a risk.
- Prototyping — testing a hypothesis over 2–3 weeks. Spinning up on Make is faster. Porting a working prototype to n8n later is standard procedure.
In these cases, steering a client to n8n for "sovereignty and self-hosting" is consultant theatre, not real value.
When n8n is the only path
And the reverse — when Make is off the table:
- Any workflow with regulated personal data under a strict residency regime. There's no debate here — Make moves data to a region you don't control, which under GDPR often requires explicit consent and frequently can't be made compliant on paper.
- A contract with a regulated-sector or public-sector client. Most such procurements mandate localized processing on certified infrastructure. Make doesn't pass.
- A long-term product with resold access (a white-label workflow for the agency's clients). Make's vendor lock-in means exposure to future price hikes or policy changes. n8n under an Apache license gives you independence.
- A workflow with a high operation count per run. Make plans cap operations/min — a large data-processing batch hits the ceiling.
Cost of ownership over 12 months
Comparing on single-payment startup cost is misleading. Twelve months out, the picture looks different.
Make. A Pro-tier plan runs roughly $40–150/month depending on the operations limit. A typical B2B agency workflow at 2–5 million operations a month runs around $100–300/month. Over a year — $1,200–3,600.
n8n self-hosted. A small instance (2 vCPU / 4 GB) runs around $20/month. Add managed PostgreSQL — another $15/month. Total around $35/month, independent of operations volume. Over a year — about $420.
n8n self-hosted with a GPU for an in-house LLM. If a local open model runs on the same machine, you add a GPU instance ($1,000–1,500/month). But then you save on per-token LLM billing.
The main difference isn't the dollars, it's the predictability. n8n is fixed CAPEX. Make is a linear function of usage with an unpredictable ceiling.
The architectural consequence — vendor portability
One of our main arguments for n8n is JSON-exporting workflows and storing them in git. That buys three wins:
- Code review for workflows. A pull request changing
workflow.jsonshows up in the git diff and gets discussed by the team. Make snapshots live inside the platform, not cross-team. - CI/CD for workflows. We run a test run of the workflow on a PR against a staging n8n instance, then deploy to prod. Make offers nothing like this.
- Reversibility. A broken workflow =
git revert. On Make it's a manual snapshot restore, with 7–30 days of retention depending on plan.
For small agencies these three wins sound like over-engineering. But after 12 months running 10–20 production workflows, the difference becomes critical — a git-based pipeline gives collective quality control, which a Make-only setup structurally can't.
Make the tool choice deliberately
If you're evaluating automation for an agency and standing between Make and n8n — let's talk. We'll walk through your team's concrete scenarios and propose an architecture that holds up over time: where you can start on Make for speed, where you need n8n from day one, where a hybrid makes sense.
