Keeping Make and n8n Cloud can be deliberate: one may own a different job, a staged migration, or a bounded fallback. It can also leave the same job running twice while two different billing units make the overlap hard to see.
This guide is for the question “Do I need both Make and n8n Cloud?” It gives you a narrow, non-ranked way to map one duplicated workflow, translate its documented usage units, and record the evidence you need before changing a subscription. It does not name a winner, estimate a guaranteed saving, or make claims about speed, quality, reliability, or ease of use.
Evidence status — source review: September 5, 2026. The billing and account-boundary statements below link to current first-party documentation. The arithmetic and decision conditions are Practical Solo Ops editorial aids. No Make or n8n Cloud account, workflow, retry, export, cancellation, retention setting, or billing screen was exercised for this article. Recheck the linked vendor sources before relying on them for a live account decision.
Scope boundary. “n8n Cloud” means n8n’s hosted service. Self-hosted n8n has a different infrastructure, maintenance, retention, recovery, and cost model. Do not transfer a Cloud statement to a self-hosted installation.
Start with one duplicated job
Do not start with a feature catalog. Choose one workflow that appears to run in both platforms and describe its useful outcome in one sentence.
For example:
When an approved intake record arrives, create the same project record and send the same internal alert.
Record the boundaries of that job before looking at price:
| Question | Record |
|---|---|
| What starts it? | One named trigger and its authoritative source |
| What does it change? | Records, messages, files, or notifications |
| Which steps are genuinely duplicated? | Named actions, not a broad feature label |
| Which steps are distinct? | A required destination, permission, approval, or dependency |
| What happens if one copy stops? | A manual fallback and the person who reviews it |
If the Make and n8n versions do different work, document that distinction first. A second subscription is not automatically redundant just because both platforms can perform a similar category of task.
The two billing units are not interchangeable
Make and n8n Cloud answer different usage questions. Translate the same bounded workflow into each documented unit rather than comparing a headline plan price.
Make: credits with a standard-action boundary
Official documented fact — MAKE-001. Make describes credits as its current billing currency. For most fixed-usage apps, the documented default is one operation equal to one credit; some modules can consume more than one credit or use dynamic consumption.
Let:
D= monthly runs of the workflow that is duplicated across both platforms; andA= average standard Make operations that process one run.
For a simple planning estimate:
Estimated Make standard-action credits = D × A
This is not an invoice forecast. Mark A as an assumption unless you have authorized account evidence. AI features, dynamic or token-based modules, bundles, data volume, branches, and other module rules can change the credit treatment. Do not silently turn those cases into “one credit.”
Make also documents account paths when credits are exhausted, including upgrading, buying extra credits, or enabling extra-credit auto-purchasing (MAKE-002). Those paths describe possible settings, not the state of a reader’s organization.
n8n Cloud: one complete workflow run is one execution
Official documented fact — N8N-001. n8n’s Cloud pricing page describes an execution as one run of an entire workflow. The page says the execution count does not change with the number of steps or the amount of data processed in that workflow.
For the same duplicated job:
Estimated n8n Cloud executions = D
That does not mean every Cloud plan has unlimited storage, concurrency, history, or execution capacity. Those are separate plan boundaries. It also does not describe self-hosted n8n.
Illustrative translation, not a price comparison
Suppose the duplicated job runs 80 times in a month and its Make version has 4 successful, standard fixed-usage actions per run:
| Documented unit | Editorial translation for the same hypothetical job | Estimate |
|---|---|---|
| Make credits | 80 runs × 4 standard actions | 320 estimated credits |
| n8n Cloud executions | 80 complete workflow runs | 80 estimated executions |
The units differ because the vendors count different things. The example does not prove that either service is cheaper, that a plan will fit, or that switching is safe.
Use three inputs, then keep the unknowns visible
The first pass needs only three values from your own records:
- Monthly duplicated workflow executions —
D, the same bounded job completing in both systems. - Average standard Make actions per execution —
A, clearly labeled observed or assumed. - Current combined monthly bill — one total for both subscriptions, taken from your current billing records rather than a stale public price card.
The private overlap worksheet calculates the disclosed workload translations in the browser. It does not save the inputs or invent a savings amount. Results should return the numbers you entered so the record is auditable.
Keep these cases outside the first arithmetic pass:
| Uncertainty | Record instead of guessing |
|---|---|
| AI, dynamic, or bundled Make modules | Module name and current credit rule to recheck |
| Branches or filters | Which actions actually run in the bounded case |
| Errors or retries | Error type, retry setting, and a safe test requirement |
| Near a plan allowance | Current account allowance and what the account does at the boundary |
Check the subscription boundary before a change
The usage estimate is only one part of the decision. Capture the account facts that a public article cannot know.
Make account and exit checks
Make documents scenario-blueprint export as a JSON file and notes that an imported blueprint still needs its account connections configured (MAKE-004). Treat this as an export path, not proof that credentials, history, schedules, permissions, or an operating fallback will travel.
Make documents cancellation from the organization subscription area for an owner or admin, a move to the free plan at the end of the billing cycle subject to its one-free-organization rules, and no transfer of unused credits to that plan (MAKE-005). Confirm your role, billing cadence, attached services, and final account screen before taking action; none were tested here.
n8n Cloud account and exit checks
The n8n Cloud help center documents an Admin Dashboard path through Manage → Export, where an administrator chooses a backup date and downloads workflows (N8N-003). That does not establish the contents of a chosen backup, connection portability, or import success for your workspace.
n8n’s cancellation guidance says to cancel from the Admin Dashboard’s Manage tab; it says the subscription will not renew on the next billing cycle and that account data and backups are kept for 90 days after the subscription ends before permanent deletion (N8N-004). Treat that as a policy checkpoint. Record which execution history, workflow definitions, credentials, logs, and external records must remain available, then verify the current account and role.
Write a conditional record, not a cancellation command
Use the following conditions as prompts for an owner review:
| What your record shows | Non-ranked next action |
|---|---|
| Make and n8n Cloud each have a distinct dependency, approval, destination, or deliberate fallback | Keep both jobs visible and set the next review date |
| The same bounded job is duplicated and one platform covers the required dependency and recovery conditions | Mark the overlap as a consolidation candidate for owner review |
| Make credit treatment, retries, branches, or plan settings are unresolved | Pause the comparison and resolve the unit uncertainty |
| Export, retention, rollback, data, role, or cancellation evidence is incomplete | Keep the decision open until the missing exit check is recorded |
These are conditions, not a score. The reader decides whether to keep, change, or retire a subscription.
What this article does not test
The source-led comparison does not prove:
- a current Make or n8n Cloud price, allowance, overage, or plan fit for your account;
- how a particular Make module, branch, retry, bundle, or error will be billed;
- whether a workflow export imports cleanly or preserves connections, history, permissions, or schedules;
- speed, reliability, support experience, output quality, migration effort, or a guaranteed saving;
- whether stopping one live workflow will avoid duplicate writes, missed records, or external messages.
If a workflow can send externally, write an authoritative record, handle client data, or change access, use the automation platform test method with an owner-controlled account and synthetic data. Missing access is “Not tested,” not a negative score.
Keep the record for the next renewal
Save the workflow sentence, D, A, combined bill, source-review date, account evidence, export result, retention question, and next review date together. Re-open the official sources when terms change or before a consequential account action. The right conclusion can change when the job, owner, or billing rules change.
If you want those cost, renewal, automation-risk, and exit records in one editable workbook, the Solo Ops Control Kit is an optional implementation aid. It does not rank Make against n8n Cloud or replace the source and account checks above.
Sources and evidence notes
MAKE-001andMAKE-002— Make: Credits — current credit terminology, standard fixed-usage boundary, and limit paths; no Make account was tested.MAKE-004— Make: Blueprints andMAKE-005— Make: Cancel your subscription — documented export and cancellation paths only.N8N-001— n8n: Plans and Pricing — Cloud execution unit and plan-boundary documentation; no n8n Cloud account was tested.N8N-003— n8n Cloud: Export workflows andN8N-004— n8n Cloud: Cancel a paid subscription — documented exit and retention policy checkpoints only.METHOD-001— Practical Solo Ops editorial policy — distinguishes sourced facts, editorial calculations, examples, and unperformed tests.
All source rows were reviewed on September 5, 2026. Re-open the first-party pages before an owner preview or account action.