MMS Vegas

Tag: make

  • Make Pricing Explained: What You Actually Pay For

    Last updated: June 2026

    Table of contents

    1. The one idea that explains the whole bill: the credit
    2. What the plan tiers actually change
    3. Is Make’s free plan enough?
    4. How to estimate your monthly cost
    5. Three ways people overpay (and how to not)
    6. Frequently asked questions

    I’m going to deliberately avoid quoting you a dollar figure, and I want to tell you why up front: Make changes its prices, and the exact numbers differ by billing cycle and region. A dollar amount in an article like this rots within months and then it’s actively misleading. So I’ll teach you the structure of the pricing — which is stable — and send you to the one place the live numbers live. Learn the structure and you’ll never be confused by the price page again.

    The one idea that explains the whole bill: the credit

    Make meters work in credits. (You may still see the older word “operations” in tutorials and forum posts — Make renamed the billing unit to credits on August 27, 2025. Same idea, new label.) The rule of thumb is simple:

    Most modules that run cost one credit each — but not all of them, and the exceptions are where cost estimates go wrong.

    Here are Make’s actual rules, because they matter for predicting a bill:

    • Triggers cost 1 credit per run — even when they check and find nothing new. A trigger that polls every minute spends a credit every minute, all day.
    • Search modules cost 1 credit per run — even if they return ten rows. The search itself is one credit.
    • Action modules cost 1 credit per bundle they process. This is the one people miss. If a search returns ten rows and the next “update” module acts on all ten, that update costs ten credits, not one. Per-bundle, not per-module.
    • Iterators cost 1 credit to split a list, then everything after the iterator runs once per item — so iterating ten items through two modules is twenty more credits. (See iterators vs. aggregators for why this is the sneakiest cost in Make.)
    • Aggregators cost 1 credit per aggregation. Combining many bundles back into one — the natural partner to an iterator — is a single credit, not one per bundle. Cheap on the way back in.
    • Filters and routers are free. Adding a filter to decide whether to continue, or a router to branch your scenario, doesn’t cost credits. You can be liberal with flow control without touching your bill.
    • AI features and Make Code are different. AI modules can use dynamic credits based on token usage, and Make Code is billed by execution time (2 credits per second). If you’re leaning on those, the “1 credit per run” rule of thumb doesn’t apply — check the live docs.

    So your monthly bill isn’t “how many modules you have” — it’s how many credit-consuming operations actually fire, including the per-bundle multiplier on actions. A scenario that looks small on the canvas can be expensive if one search feeds an action that runs on hundreds of bundles.

    This reframes the cost question entirely. You’re not paying for the automation — you’re paying for how often it runs and how many bundles it chews through. A complex scenario that fires twice a day can be cheaper than a simple one that fires every minute. For the full mechanics — what counts as a credit, what doesn’t, and the per-bundle edge cases — read the dedicated piece on operations vs. credits.

    What the plan tiers actually change

    Make’s plans look like a wall of features, but for almost everyone the differences come down to three levers. Start with these; the other limits (file size, data transfer, scenario execution time) matter too, but usually only once you’re scaling.

    Lever 1: How many credits per month

    This is the big one. Each tier comes with a monthly credit allowance, and the allowance climbs as you go up. The free plan gives you a modest monthly allowance — enough to learn on and run a light automation or two. Paid tiers multiply that. Estimate your monthly credit burn first, then pick the smallest tier that covers it with headroom. Buying a tier for its name instead of its credit count is how people overpay.

    Lever 2: How fast your scenarios are allowed to run

    Make limits how frequently a scheduled scenario can check for new work. On the free plan the minimum interval between runs is longer (15 minutes); paid plans tighten that minimum down to as little as one minute. If your business needs near-real-time reaction — a lead hits your form and you want the follow-up out in 60 seconds, not 15 minutes — that interval is the line item you’re actually buying when you move off free.

    Lever 3: Advanced features and team controls

    Higher tiers unlock things like more active scenarios, advanced scheduling, priority execution, and team/organization controls. Real, but secondary — most solo operators never bump into these until they’re scaling. Team and enterprise plans add team roles, collaboration, and admin controls; if you’re pricing one of those, check the current structure on Make’s pricing page rather than assuming, since it changes. Plan choice is also tangled up with Make’s hard limits — file size, execution time, active scenarios — so skim those before you commit to a tier.

    Is Make’s free plan enough?

    Make’s free plan is not a crippled trial — it’s a genuinely usable tier for learning and light production. You get a monthly credit allowance, you can run a couple of active scenarios, and the only real constraints are that monthly credit ceiling and the longer minimum run interval. For “I want to find out whether automation pays for my business before I spend a dime,” it’s exactly right.

    My honest advice: start free, build one automation that solves a real, annoying problem, and watch the credit meter for a couple of weeks. You’ll learn your actual burn rate from reality instead of guessing — and then you’ll know precisely which paid tier (if any) you need. That’s how you buy the right plan instead of the impressive one.

    Want to predict your bill before you build? The free Builder’s Companion Kit includes a cost estimator that turns “how often does this run?” into a credit-burn number — so the meter never surprises you.

    Get the free Builder’s Companion Kit →

    How to estimate your monthly cost (without quoting you a wrong number)

    Here’s the back-of-envelope method that actually works:

    1. Count the credit-consuming operations, not the modules. Trigger (1) + each search (1) + each action × the bundles it processes. Skip filters and routers — they’re free. Watch for actions that run per-bundle: a search returning 50 rows feeding an update is 1 + 50 credits, not 2.
    2. Estimate how many times it runs per month. Be honest — a “real time” scenario polling every minute runs ~43,000 times a month, and that volume is what bites people.
    3. Multiply. Credit-consuming operations per run × runs per month ≈ credits per month for that scenario (remembering the per-bundle multiplier on actions). Add up your scenarios.
    4. Match to the smallest tier with headroom. Take that total to make.com/pricing and pick the plan whose credit allowance covers it comfortably.

    Notice what this method does: it puts run frequency at the center, because that’s the variable that explodes a bill. Two scenarios with identical modules can cost wildly different amounts purely because one polls every minute and one runs once an hour. Before you set a scenario to run constantly, ask whether it actually needs to — most don’t.

    Three ways people overpay (and how to not)

    • Polling when a webhook would do. A scenario that checks for new data every minute burns credits all day, even when nothing’s there. If the source can push to you via a webhook, it fires only when there’s real work — a fraction of the cost. (More on this in the companion guide to Make webhooks.)
    • Buying a tier for its features when you only needed its credits. Decide based on credit allowance and run interval first. The fancy features are usually not the reason you’re moving up.
    • Letting broken scenarios re-run. An error that triggers retries can quietly burn credits in a loop. Good error handling isn’t just reliability — it’s cost control.

    If you’ve decided Make is your platform, you can start on the free plan here, build a real automation, and let your own credit meter tell you what you need. That beats any pricing estimate I could hand you — including this one.

    Frequently asked questions

    What’s the billing unit? The credit. Most standard operations = 1 credit; actions are 1 per bundle; iterators 1 to split, aggregators 1 per aggregation; filters/routers free; AI/Make Code dynamic. Renamed from “operations” Aug 27, 2025.

    What drives my bill the most? Run frequency first; bundle volume and dynamic AI/Code modules second.

    What do plan tiers really change? Monthly credit allowance, minimum run interval, and advanced/team features.

    Is the free plan usable for real work? Yes — for learning and light production. Monthly credit cap + 15-min minimum interval are the main limits.

    Team/enterprise plans? Add team roles, collaboration + admin controls; check make.com/pricing for current structure.

    Where are the live dollar figures? make.com/pricing — always confirm there; prices change.

    How much does Make cost per month? It depends entirely on how many credits you burn, which depends on how many credit-consuming operations your scenarios run and how often — remembering that action modules cost a credit per bundle they process, while filters and routers are free. Make has a usable free plan and paid tiers that scale up the monthly credit allowance and tighten the minimum run interval. Because exact dollar figures change by billing cycle and region, check make.com/pricing for current numbers — but estimate your credit burn first so you buy the right tier.

    What is a credit in Make? A credit is Make’s billing unit — as a rule of thumb, one standard module operation running one time. Most modules cost one credit per run, but there are exceptions worth knowing: action modules cost one credit per bundle they process, filters and routers are free, and AI modules and Make Code are billed dynamically. Make renamed this unit from “operations” to “credits” on August 27, 2025; you’ll still see the old word in older content.

    Is the Make free plan good enough to start? Yes. The free plan gives you a monthly credit allowance, lets you run a couple of active scenarios, and is genuinely usable for learning and light automations. The main constraints are the monthly credit ceiling and a longer minimum interval (15 minutes) between scheduled runs. Most people should start here.

    Why is my Make bill higher than I expected? Almost always because a scenario runs more often than you realized. Polling every minute fires roughly 43,000 times a month, and each run spends credits. Switching high-frequency polling to webhooks, lengthening run intervals where real-time isn’t needed, and fixing error loops that cause retries are the three biggest fixes.

    Does adding more apps or connectors cost extra? No — Make doesn’t charge per app or per connector. You pay for credits, which are consumed when modules run. Connecting to ten apps costs nothing by itself; running modules against them is what spends credits.

    Sources: Make pricing, help, and developer documentation (make.com). Platform facts current as of early 2026. Pricing dollar figures change frequently and vary by billing cycle and region — always confirm current numbers at make.com/pricing.

  • Make vs n8n: Which Automation Platform Is Right for You?

    Last updated: June 2026

    Table of contents

    1. What each one actually is
    2. The honest tradeoff, in one table
    3. The pricing difference that actually decides it
    4. Where Make is the right call
    5. Where n8n is the right call
    6. The decision, made simple
    7. Quick reference
    8. Frequently asked questions

    I build automations the way a marketer builds them — to save time and make money, not to admire the architecture. So this isn’t a feature-matrix beauty contest. It’s the question you actually care about: which one do I put my next two hours into?

    Make vs n8n, in one line: Make is better for non-technical operators who want hosted, visual automations fast. n8n is better for technical teams that want self-hosting, long multi-step workflows, or execution-based pricing.

    What each one actually is

    Make (the platform formerly called Integromat) is a hosted, drag-and-connect automation builder. You log in, drag modules onto a canvas, wire them together, and Make runs the whole thing on its servers. You never touch a command line. You pay by usage — Make meters work in credits (the billing unit it renamed from “operations” on August 27, 2025), and most standard credit-consuming operations cost one credit each.

    n8n is a source-available automation tool. Its code is openly visible and you’re free to self-host and modify it — n8n calls its model “fair-code,” distributed under the Sustainable Use License. (Worth being precise here, because people get it wrong constantly: n8n is not open-source in the strict OSI sense — the license puts limits on commercial use, so n8n itself declines the “open-source” label. For your purposes it behaves a lot like open-source for internal business use: free to run, modify, and self-host.) Run it on your own server, a cheap cloud box, or a Docker container, and the executions don’t carry a per-step fee — you’re paying for the server, not per task. Or skip the server work entirely and pay for n8n Cloud, n8n’s managed hosting, which looks much more like Make from a “just log in and build” standpoint.

    That single difference — hosted-and-metered versus self-hostable-and-flat — drives almost everything else.

    The honest tradeoff, in one table

    What you care aboutMaken8n
    Time to first working automationMinutes. Nothing to install.Fast on n8n Cloud; slower if you self-host first.
    How you’re billedPer credit — most modules ~1 credit per run (filters/routers free; actions per bundle)Per workflow execution (whole run = 1) on Cloud; flat server cost if self-hosted
    Many-step workflowsMore credit-consuming steps add upStep count doesn’t change the execution count — long workflows stay cheaper at the meter
    High-volume runsCredits climb with usageSelf-host and volume barely moves the cost
    Pre-built app connectionsVery large library, polishedLarge and growing; occasionally more “wire it yourself”
    Infrastructure controlRuns on Make’s serversSelf-host and the instance runs on hardware you control
    Visual clarity for non-codersExcellent — the canvas is the productGood, but assumes more comfort with logic
    Who maintains the plumbingMake doesYou do (self-hosted) or n8n does (Cloud)

    The pricing difference that actually decides it

    This is the part most “Make vs n8n” pages skim, and it’s the part that should drive your decision, so let’s be concrete.

    Make charges by the credit, and credits track the steps that do work. Most modules cost about one credit each time they run; the exceptions are worth knowing — filters and routers are free, and an action that processes many bundles costs a credit per bundle. The practical effect still holds: the more credit-consuming steps in your automation, and the more often it runs, the more the meter moves. A scenario with ten credit-consuming operations that runs a thousand times spends on the order of ten thousand credits. (The full credit model — per-bundle actions, free flow control, dynamic AI usage — is in the companion Make pricing guide.)

    n8n charges per whole workflow run. On n8n Cloud, one execution is one complete workflow run, no matter how many steps are inside it. A three-step workflow and a thirty-step workflow each count as a single execution. So the same job — a ten-step workflow running a thousand times — is about ten thousand credits on Make but only a thousand executions on n8n.

    Read that difference carefully, because it drives most of the crossover:

    • Short, frequent automations tend to favor Make — few steps means few credits, and you get Make’s polish and zero infrastructure for free.
    • Long, multi-step or high-volume automations tend to favor n8n — because piling on steps doesn’t multiply your bill the way per-step credits do.

    Two honest caveats so you don’t over-trust the headline. First, Make has a usable free plan and isn’t expensive at modest volume — the per-step model only becomes the thing you watch as scenarios get long or run constantly. (For exactly how Make’s meter works, read the companion piece on Make pricing and the deeper one on operations vs. credits.) Second, n8n Cloud’s execution tiers have their own caps, and — this catches people — n8n Cloud is paid, with a trial rather than a permanent free plan. The genuinely free path on n8n is self-hosting the Community Edition, which has unlimited executions but hands you the server to run.

    Where Make is the right call

    Make is the right starting point for most small operators. Here’s why.

    You want to be building, not provisioning. With Make there is no server to stand up, no Docker to learn, no security patch to remember. You open the canvas and the only problem in front of you is the automation itself. For a busy owner, that removed friction is worth real money — the automation you actually ship beats the elegant one you never get around to self-hosting.

    The connector library is broad and maintained. When you need to talk to a CRM, a spreadsheet, a payment processor, or an email tool, Make usually has a polished, ready module for it. That saves you the “wire up the API by hand” tax you’ll occasionally pay on either platform for less-common apps.

    The visual model teaches you as you go. Make’s canvas — modules, routers, filters, iterators, and aggregators — is genuinely good at showing you how the data flows. For someone learning automation thinking for the first time, that legibility is a feature, not decoration.

    The honest caveat: Make’s pricing is usage-based, so the better your automation works, the more it runs, and the more credits it burns. That’s fine — and frankly a good problem — until you’re running long workflows or very high volume, at which point the per-step meter is the thing you start watching. If you want to understand it before it surprises you, the limits guide and the pricing guide cover it.

    Before you build anything in Make: grab the free Builder’s Companion Kit — the reference cards, six importable starter blueprints, and a cost estimator so the credit meter never surprises you.

    Get the free Builder’s Companion Kit →

    Where n8n is the right call

    n8n earns its place in a few specific situations.

    You run long or high-volume workflows and the per-step meter hurts. This is the classic crossover. Because n8n bills per whole workflow run rather than per step, multi-step automations and heavy throughput cost far less than they would on a per-step credit model. If you’re firing complex workflows tens or hundreds of thousands of times a month, self-hosted n8n flattens the bill: you pay for the server, and a busy automation costs about the same as a quiet one.

    You want to own the infrastructure. Self-hosting puts the n8n instance — and the execution data and credentials it holds — on hardware you control. For some teams that control is the whole point: a regulated industry, a client contract, an internal policy that says the automation engine lives on your own box. Be precise about what that does and doesn’t guarantee, though (more on that in a second).

    You (or someone on your team) are comfortable owning infrastructure. Self-hosting is not free in the way “free to download” sounds free. Someone has to update it, secure it, back it up, and fix it at the worst possible moment. If you have that person, n8n’s flexibility is a gift. If you don’t, that “free” tool has a salary attached. And if you want n8n without the server work, n8n Cloud removes most of that burden — you just give up the flat-cost advantage and step back onto execution-based tiers.

    One thing people overstate about self-hosting

    You’ll hear “self-host n8n and your data never leaves your servers.” That’s only half true, and the half that’s wrong matters. Self-hosting keeps the n8n instance, its execution logs, and your stored credentials on your infrastructure — real and valuable. But the moment a workflow calls an external service (Stripe to charge a card, Google to read a sheet, an AI API to summarize text, your CRM to update a record), data goes to that service. Self-hosting controls where the automation engine runs; it does not magically keep every byte on-premises if your workflow’s whole job is to talk to other systems. So the accurate claim is: self-hosting gives you control over the engine and its data store — not a blanket guarantee that nothing ever leaves. If true data isolation is the requirement, you have to design the workflows for it too, not just self-host the platform.

    The decision, made simple

    Strip away the feature comparisons and it comes down to two questions:

    1. Do you want to own the infrastructure? If no — and for most small operators the answer is no — start with Make.
    2. Are your workflows long or high-volume enough that a per-step meter becomes your biggest line item? If yes, and you have someone to run a server, self-hosted n8n is worth the move.

    Here’s the move I actually recommend for someone choosing today: start on Make. Build your first real automation this week, prove the workflow earns its keep, and learn how automation thinking works on a platform that won’t make you fight infrastructure to get there. If you later hit a volume or step-count wall where the credit meter genuinely hurts, you’ll port the logic you learned to self-hosted n8n in an afternoon — and you’ll port it knowing exactly what you need, because you’ll have run it for real. The reverse path — standing up infrastructure you have to maintain before you’ve proven a single automation pays — is how good ideas die in a half-configured Docker container.

    If you go the Make route, you can create a free Make account here and have your first scenario running today. The free plan is enough to learn on, and it costs you nothing to find out whether automation pays for your business.

    Quick reference

    If this is you…Start with
    Small operator, no infra person, wants results this weekMake
    Learning automation for the first timeMake
    Mostly short automations, modest volumeMake
    Needs the broadest library of ready connectorsMake
    Running long, multi-step or very high-volume workflowsn8n (self-hosted)
    Wants the automation engine on infrastructure you controln8n (self-hosted)
    Wants n8n’s model without server workn8n Cloud (paid tiers)

    Frequently asked questions

    Is n8n open-source? Not in the strict sense. n8n’s source code is openly available and you’re free to self-host and modify it, but its Sustainable Use License places limits on commercial use, so n8n itself declines the “open-source” label and uses the term “fair-code” instead. In practice, for internal business use it behaves much like open-source: free to run, modify, and self-host. The accurate words are source-available, fair-code, and self-hostable.

    Is Make or n8n cheaper? It depends on your workflows. Make bills by credits tied to credit-consuming operations (most modules ~1 credit, actions per bundle, filters and routers free), so short automations at modest volume are inexpensive and come with zero infrastructure. n8n bills per whole workflow run (on Cloud) or a flat server cost (self-hosted), so long, multi-step, or very high-volume workflows get dramatically cheaper on n8n. The crossover is driven by step count and run frequency: the longer and busier your automations, the more n8n’s model wins; the shorter and lighter they are, the more Make’s convenience wins.

    Does n8n have a free plan? Self-hosting the n8n Community Edition is free and has unlimited executions — you only pay for the server it runs on. n8n Cloud, the managed option, is paid — it offers a trial rather than a permanent free plan. So “free n8n” means self-hosted Community Edition, not cloud.

    Can I move from Make to n8n later? Don’t expect a one-click migration — Make and n8n use different formats — but the automation logic you learn on Make (triggers, filters, routing, iterating over data, handling errors) ports directly because the concepts are the same. Most people who switch rebuild the workflow rather than convert a file, and it goes quickly because they already know exactly what they need.

    Which is better for someone who can’t code? Make. Its visual canvas is the cleanest on-ramp for non-coders, and the broad connector library means you rarely have to hand-wire an API. n8n is approachable too, especially on its cloud plan, but it leans slightly more toward people comfortable with logic and the occasional bit of technical setup.

    How does Make compare to Zapier instead of n8n? That’s a different axis — Zapier is also hosted and metered, like Make, so the comparison is about pricing model and depth of logic rather than hosted-vs-self-hosted. We cover it in the companion article, Make vs. Zapier.

    Sources: Make help, developer, and pricing documentation (make.com); n8n documentation, license, and pricing (n8n.io, docs.n8n.io). Platform facts current as of mid-2026 — pricing, plan structures, and execution limits change often, so confirm specifics on each vendor’s live pricing and licensing pages before committing.

    Sources

    Verified against the official docs: