Does self-hosting n8n cost less than Make credits?
Self-hosting usually moves cost from a recurring credit bill to infrastructure, staff time and the one-time work of rebuilding scenarios, so the outcome depends on your credit volume and scenario mix. Start by pulling your current Make plan and its monthly credit consumption from your own account, since Make's prices are not stated here and must come from your contract or the plan page you are billed under. Then list the scenarios that consume the most credits. Those are the ones where the comparison matters most. n8n's free Community edition removes the license fee for self-hosted use, but it is not the whole bill. Your costs will include the servers or cloud accounts that run the main instance and any workers, storage and backups for PostgreSQL, monitoring, patching and on-call coverage. If you need SSO through SAML, log streaming or Git-based environments, those features sit in the Business plan at 667 euros per month billed annually, which n8n lists as self-hosted only. Enterprise is priced by quote. Confirm the current figures on n8n's pricing page before you build a budget.
The counting model is where credit-heavy scenarios behave differently. n8n counts an execution as one run of a whole workflow regardless of how many steps it contains, while per-operation credit models charge for each action a scenario performs. A multi-step scenario that runs often can cost far less under an execution count than under credits, but a workflow with many AI steps, code nodes or loops still adds compute and third-party API charges that you pay directly. Test your heaviest scenario on a self-hosted instance under realistic volume and compare the resource use with your current credit burn. Also ask whether your AI model providers bill per token, since those costs will remain regardless of platform.
Which cost components change when you move from Make to self-hosted n8n
This table compares each cost component of running Make against running self-hosted n8n, showing who is paid, whether the cost is one-time or recurring, and what drives it. Read it as a checklist for a quote request, since the largest differences usually sit in scenario rebuild and staff time rather than in license fees.
| Cost component | Make (credits and plan) | Self-hosted n8n (edition, servers, staff) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Recurring plan fee, with credit allowance set by the plan tier chosen | Community edition runs without a license key. Business and Enterprise need a license key; n8n's pricing page lists Business at 667 euros per month billed annually, self-hosted only | Recurring for Make and for any paid n8n license; Community has no license fee |
| Infrastructure | Hosted by Make in its US or EU zones, so no servers to size or patch | Virtual machines or containers, a PostgreSQL database and, for queue mode, Redis. Sizing depends on execution volume and workflow complexity | Recurring (cloud or hardware, database backups, storage) |
| Implementation and scenario rebuild | Scenarios exist already and are paid for through credits each time they run | Each scenario is rebuilt as an n8n workflow. Make blueprints show modules and mapped values, but connections must be recreated and testing is manual | One-time, sized by the number and complexity of scenarios |
| Migration and cutover | Scenarios keep running until switched off | Parallel running, credential re-entry, webhook URL changes and a cutover window. Confirm the plan with the team that owns each scenario | One-time |
| Monitoring and support | Vendor-operated uptime; support tiers come with the Make plan | Your team monitors executions, errors, queue depth and worker health. Community has no vendor SLA; Enterprise adds dedicated support with an SLA per n8n's pricing page | Recurring staff time, plus support fees if you buy a license |
| Upgrades and patching | Handled by Make as a hosted service | Your team applies n8n releases, reads release notes and tests workflows after each upgrade | Recurring |
| Internal skills | Visual scenario building; credit usage is the main thing to watch | Operating Node.js services, database administration, encryption key handling for credentials and, for queue mode, Redis | Recurring, and rises with each added runtime component |
How n8n license edition changes the self-hosted bill
The first decision that shapes the self-hosted bill is the n8n edition. Without a license key, n8n runs as the free Community edition, so the software itself carries no license fee. Adding a Business or Enterprise license key enables those editions. On the pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, and Enterprise adds dedicated support with an SLA. Check which of those features your current Make scenarios or governance rules actually depend on, such as single sign-on for operators or audit-driven log export. Those features are what move the bill from zero to a recurring license cost, so confirm the Business price and terms directly with n8n before you build the budget.
Single sign-on is the most common reason teams step up. n8n's SAML single sign-on is available on the Business and Enterprise plans, and n8n publishes step-by-step setup guides for Okta Workforce Identity and Azure AD. Multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments and is not available in the Community edition. If your Make replacement must survive a single main instance failure, that requirement alone points toward Enterprise. Ask your architects whether a single main instance with tested backup and restore is an acceptable availability target before assuming Enterprise is required, and ask n8n to confirm what the Enterprise license includes for your deployment shape.
The license terms matter as much as the price. The Sustainable Use License permits use or modification only for your own internal business purposes or for non-commercial or personal use. Files with .ee in their names or directories are not covered by that license and require a valid Enterprise License. If you plan to run n8n for customers, embed it in a product, or operate it as a service for other organizations, treat that as a license review item before the project starts, not after go-live. Involve legal and procurement early, and get written confirmation of current edition terms from n8n, since the license and plan features can change.
What moves the Make versus n8n comparison
The gap between a Make bill and a self-hosted n8n bill depends on how the work is shaped, not on a list price. The drivers below push cost in different directions, so model them together before comparing totals.
Credit volume and steps per scenario
Make bills by credits, so every module run in a scenario consumes them, and a long scenario with many steps uses more per execution than a short one. n8n counts an execution as one run of a whole workflow regardless of the number of steps, so a multi-step workflow costs the same executions on n8n that it would consume in several Make operations. Ask Make for the credit use of your top scenarios, then count the executions and steps they run each month. The bigger the step count per run, the more the comparison favors n8n, while low-volume scenarios may not change the answer.
Number of users and environments
Make charges according to the plan and credit allocation you buy, and additional seats or environments can change the total. n8n's pricing page states that all plans include unlimited users, workflows and every integration, so headcount does not add a license line on the self-hosted path. Count how many people build and approve scenarios, and how many separate environments you run for development, test and production. More users and environments raise the cost of a per-seat model and add little to a self-hosted license, but they also add administration work for your team.
SSO, Git and log streaming needs
On n8n, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. If your security baseline requires SAML single sign-on, source control of workflows or exported logs, the license tier becomes a cost driver rather than a footnote. Confirm which of these you must have on day one and whether your identity provider setup fits the documented SAML guides. Request the current price for the required tier in writing, since the self-hosted Business plan is listed as a fixed monthly figure and Enterprise is custom.
Availability requirements and queue mode
A single n8n instance is the simplest and cheapest setup. Queue mode splits work so the main instance handles triggers and webhooks while a pool of workers runs executions through Redis, with workflow data kept in PostgreSQL. Each added component is more infrastructure to host, monitor and patch, and workers must share the main instance's encryption key. Multi-main high availability is limited to Enterprise self-hosted deployments. If your scenarios must keep running through a node failure, add the cost of Redis, extra workers and the license tier that supports them to your estimate.
Internal skills for PostgreSQL and upgrades
Self-hosting moves the database, backups, patching and version upgrades from the vendor to your team or your implementation partner. Someone must size and back up PostgreSQL, rotate credentials, restore workflow data and plan n8n upgrades against the release notes. Make has no cost for these tasks because it runs the platform for you. Estimate the hours your current team can absorb, the skills you would need to hire or contract, and whether a retainer for upgrades and monitoring is cheaper than building that capacity in house. Ask any partner for the scope of each recurring task in writing.
Licensing and AI steps
n8n's main codebase is under the Sustainable Use License, which allows internal business use but restricts redistribution and commercial hosting for others, and files with .ee in their name need an Enterprise License. Make's AI-related steps also consume credits, so AI-heavy scenarios can raise the Make bill faster than plain data movement. Confirm with counsel that your internal use fits the license, and list which of your scenarios call AI models so you can model them separately. Costs for AI steps depend on the model provider you choose, which you pay directly on either platform.
How credit-heavy scenarios and AI steps change the comparison
Many small, frequent scenarios are where a per-operation meter is most visible. A scenario that fires on each form submission or ticket update can run thousands of times a month while each run touches only two or three modules. On Make, the credit allowance is drawn down by operations, so the bill tracks how many steps run, not how much value each run produces. On self-hosted n8n, the main cost is a host, a database and backups, which do not rise with each trigger. Volume still costs compute, so the work is to size the infrastructure for peak load.
- Trigger volume: count webhook and polling triggers separately, and ask Make how idle polling runs that find nothing are counted.
- Steps per run: a three-step scenario draws more from a per-operation meter than a one-step scenario that does the same job.
- Fixed host cost: an n8n instance costs roughly the same whether a trigger fires ten times or ten thousand times, within the capacity you provision.
- Queue workers: when volume climbs, n8n queue mode adds workers that read from Redis and write to PostgreSQL, which is an operating cost you must size and monitor.
Before comparing totals, count triggers per day and steps per run for each scenario, using the blueprint exports from Make.
Long scenarios with iterators, aggregators and routers are where n8n's counting model can favor the self-hosted route. Make's operation-based meter grows with every module that runs, and an iterator over a list multiplies that count for each item. n8n's pricing page counts an execution as one run of a whole workflow regardless of the number of steps, so a long chain uses the same execution count as a short one. This is illustrative: a scenario that loops over 500 line items uses one execution on n8n but many operations on a per-step meter. The loop still consumes memory and CPU on your hosts, so the saving depends on how heavy each step is.
- Execution counting: a long chain on n8n is one execution, which removes the step multiplier from the bill.
- Loop compute: large iterations need enough memory and CPU on your workers, which should be tested with real payload sizes.
- Rebuild effort: iterators, aggregators and routers map to n8n nodes, and the rebuild is usually the largest one-time cost.
- Failure handling: long chains need retry logic and partial-failure paths, which must be tested on both platforms.
Ask for a run history of your longest scenario on Make, then count its operations and measure its wall-clock time on a test n8n instance.
AI steps add cost that exists on both routes. The model provider charges for tokens or requests whether the call is made from Make or from n8n, so that spend does not disappear by moving the workflow. What changes is the platform layer on top. Make AI modules draw from the same operation-based meter as other modules, while n8n AI and code nodes run on your own compute. If you serve a model inside your network, the GPU, hosting and operations cost is new and sits entirely on your side. Confirm the current rates on both platforms, because they change.
- Shared model spend: provider charges for tokens or requests appear on either route, so compare them directly.
- Platform meter: on Make, confirm how AI and LLM steps are counted against your plan.
- Self-hosted models: a model served inside your network replaces provider spend with hardware, power and operations effort.
- Data path: prompts and outputs go to hosted model providers unless you choose otherwise, so check each provider's data processing terms.
- Code steps: custom JavaScript or Python runs on your workers, so set timeouts and resource limits to control compute.
Ask both sides for the AI step count per run, the provider's per-request cost for your chosen model, and the compute you expect to need.
The most reliable comparison comes from measuring a representative month on both sides before deciding. Pick a full month that includes peak days, export the scenarios, and record runs, operations, AI calls, failures and peak concurrency for each one. Then run the top scenarios on a test n8n instance and compare execution counts and host load. Licensing belongs in the same model: the Community edition is free, but the n8n pricing page places SSO, LDAP, Git environments and log streaming in the Business and Enterprise plans, and lists the Business plan at 667 euros per month billed annually, self-hosted only, at the time of research.
- Baseline export: Make blueprint files show modules, settings and mapped values, which gives you a complete inventory. Connections are not included and must be recreated.
- Monthly counts: record runs, operations, AI calls and failures for the whole month, not an average day.
- Shadow test: run copies of the highest-volume scenarios on n8n and compare execution counts and host load.
- License fit: if you need SSO or log streaming, price the Business or Enterprise plan from the current pricing page.
- Operating load: queue mode needs a shared encryption key across workers and a PostgreSQL database, which adds ongoing upkeep.
Request a written quote built from these measured counts, so the comparison reflects your workload rather than a generic estimate.
How to build the cost model with your own numbers
This sequence turns Make credit consumption and your scenario inventory into a three-year comparison against self-hosted n8n, with each cost line sourced from your own environment and from n8n's published pricing. The output is a model you can take into a renewal or procurement discussion.
Inventory every Make scenario
List each scenario in your Make organization, its owner, its trigger type, how often it runs and the number of modules it contains. Export each scenario as a blueprint .json file from the scenario editor, since the file holds the modules, module settings and mapped values that drive the rebuild effort. Note that Make's blueprint export does not include connections, so each app connection must be recreated after import and should be counted as a separate line. Done when every active scenario has a row with module count, trigger, schedule and owner.
Pull a month of Make credit consumption
Use your Make account's usage views to record credits consumed per scenario over a representative month, including any peak periods such as month-end reporting. Compare the total with the plan tier you are paying for and ask Make to confirm how credits are counted for multi-step scenarios, routers and error handling, since those choices change the total. Done when you have a monthly credit figure for each scenario and a list of the scenarios that account for most of the spend.
Price the n8n license option
Start from n8n's pricing page, which lists a free self-hosted Community edition and a Business plan that is currently self-hosted only, along with Enterprise at custom pricing. Note that the Community edition does not include SSO and LDAP, environments with Git, or log streaming, and that those features sit in the Business and Enterprise plans. Confirm the current figures on the pricing page at the time of your review, because they change. Also confirm that n8n counts an execution as one run of a whole workflow regardless of step count, which differs from how Make consumes credits. Done when you have the license line for each edition you would consider, with the features each one includes.
Estimate hosting for main, worker and database
Size the self-hosted runtime as separate components. A queue mode deployment has a main instance that handles triggers and webhooks, a pool of workers that run executions, Redis to pass executions between them, and PostgreSQL to store workflow data. Estimate compute, storage and network for each component based on your execution volume, and add the cost of the platform team's time to keep these running. Note that queue mode requires the main instance's encryption key to be shared with every worker and webhook processor, so include key management in the design. Done when you have one hosting line per component, each marked as recurring, and a note on which cloud or data center account pays for it.
Add the rebuild effort per scenario
For each scenario in your inventory, estimate the effort to rebuild it in n8n, scaled by module count, branching, error handling and the number of custom apps that need a code node or an HTTP request. Scenarios with routers, iterators or aggregators usually take more review time than linear flows, so mark them separately. Decide whether the rebuild is done by your own staff or by an implementation partner under a written, fixed scope, and record the one-time cost of each. Done when every scenario carries an effort estimate and an owner, and the total is recorded as a one-time line in the model.
Add monitoring, backup and on-call time
Add the recurring operating costs that a cloud subscription hides: monitoring for the main, worker and database components, backups of PostgreSQL and the encryption key, patching and upgrades for n8n, and on-call coverage for failed executions. Confirm which of these your team already runs for other services, so you count only the new load. If you need n8n Enterprise support with an SLA, add that as a separate quoted line. Done when each operating activity has an owner, an hour estimate from your own staff or partner, and a recurring cost line.
Compare three years with one-time and recurring lines
Build a three-year table with two sections, one-time costs (rebuild, connection recreation, initial setup, testing) and recurring costs (Make subscription, n8n license, hosting, operations). Keep Make's recurring cost as it is today and show the self-hosted option with the same scenario volume, so the comparison is like for like. Mark which lines grow with execution volume and which stay fixed, and run the table at your current credit consumption and at a higher one. Ask for written quotes for every line that you do not own. Done when the table shows cumulative cost by year for each route and the assumptions behind each row are written next to it.
What the scenario rebuild costs in time and risk
The main cost of moving off Make is not the n8n license or the server. It is the work of rebuilding each scenario. A Make blueprint exported as .json carries the scenario's modules, module settings and mapped values, but it does not carry connections. Per Make's help center, connections must be recreated after import. In n8n, that means every credential is created or re-authorized, then tested against the live service. Credential recreation is a per-app task, and it is easy to underestimate when a scenario touches many services. Ask your team to inventory every connection referenced in each blueprint before scoping the work.
Structure is the second cost. Make routers, iterators and aggregators do not map one to one onto n8n nodes. Routers usually become IF or Switch nodes, iterators typically become item-level processing that n8n handles by default, and aggregators need an explicit node such as Aggregate or a Code node. Error handling, data mapping and scheduling also differ, so each rebuilt flow needs its own test pass rather than a copy of the original logic. Effort rises with the number of branches, nested loops, custom functions and error routes in each scenario. Group scenarios by class (simple sync, branching, looping, AI-assisted) and estimate each class with your own team or a written scope from a partner, since no reliable per-scenario figure applies across environments.
Cutover is where most operational risk sits. Run the old Make scenario and the new n8n workflow in parallel for a defined period, compare outputs for the same inputs, and only then disable the Make scenario. Plan for duplicate side effects during overlap, such as two invoices or two CRM updates, and disable write actions in one of the two systems if the target app cannot tell them apart. Also confirm that n8n's execution model fits your workloads, because n8n counts an execution as one run of a whole workflow, which changes how you read volume after migration. Keep the Make scenarios paused, not deleted, until the parallel run is signed off.
Questions buyers ask before comparing Make and n8n costs
Is a self-hosted n8n instance free to run?
The software has no license fee in the Community edition, but running it still costs money. n8n's pricing page lists a free self-hosted Community edition, so the license line is zero for that edition. The recurring costs sit elsewhere: compute and storage in your cloud account or data center, backups, a PostgreSQL database and, in queue mode, Redis and worker capacity, monitoring, and the staff time to patch and upgrade. If you need a paid edition, the Business plan is listed at 667 euros per month billed annually and is self-hosted only. Ask for a model that separates one-time build cost from these monthly running costs, so you can compare it with your Make bill line by line.
How long does it take to rebuild Make scenarios in n8n?
The duration depends on how many scenarios you have and how complex each one is, so no single timeline fits every account. Start with an inventory. A Make blueprint export holds each scenario's modules, module settings and mapped values, which gives the rebuild team a concrete source. Connections are not included, so every app login must be recreated on the new platform. Work grows with routers, iterators and aggregators, custom code, error handling, field-level data mapping and the testing needed before you switch off the originals. Ask for an estimate built from your inventory, with scenarios grouped by complexity, and confirm which assumptions it depends on.
Can our team rebuild and run n8n without outside help?
Many teams can do it in-house if they already run containers, operate PostgreSQL and manage secrets. A common pattern is to rebuild the simplest scenarios first and bring in outside help for the complex ones. The skills to check are container deployment (Docker Compose is a documented install path), TLS and a reverse proxy, database backup and restore, encryption key handling, and JavaScript or Python for code nodes. In queue mode, the main instance's encryption key must be shared with every worker and webhook processor, so key distribution becomes a design decision. Upgrades also need review against n8n's release notes. Capacity matters as much as skill, because the people rebuilding scenarios usually keep their current duties.
Do we need n8n Business or Enterprise for SSO or high availability?
For SSO, yes. SAML single sign-on is available on the Business and Enterprise plans, and n8n's pricing page places SSO and LDAP in those tiers. High availability through multi-main setup is restricted to Enterprise self-hosted deployments and is not available in the Community edition. Log streaming and environments with Git are also listed only for Business and Enterprise. Queue mode, which uses Redis and a worker pool, is a separate question, so confirm with n8n whether your target edition supports the architecture you plan. Budget for the license key, the identity provider configuration (n8n documents guides for Okta Workforce Identity and Azure AD) and the operational work of running two or more main instances.
Is commercial use allowed under the Sustainable Use License?
It depends on the specific use. The Sustainable Use License permits use or modification for your own internal business purposes, and for non-commercial or personal use. Automating your company's internal processes falls within internal business use. Offering n8n-based automation to customers as a hosted service, embedding it in a product you sell, or distributing it commercially goes beyond that grant. Files with .ee in their name or directory require a valid n8n Enterprise License. Have your legal team confirm your planned use in writing before you commit to a deployment model, and include that confirmation in the scope you send for a quote.
How does n8n's execution counting affect cost compared with Make credits?
n8n counts an execution as one run of a whole workflow, regardless of how many steps it contains, and all its plans include unlimited workflows. Make bills by credit consumption under its own model, so confirm exactly how your scenarios consume credits on Make's current pricing before comparing the two. On the n8n side, the cost drivers shift to the runtime: executions per month, worker capacity in queue mode, and the compute and database sizing you choose. Self-hosted Community has no per-execution fee. AI steps and large payloads add compute and model usage in your own bill, so model them as a separate line item rather than folding them into the platform figure.
How do we request a fixed-scope quote from DeployOpen?
Send a written scope, and DeployOpen prepares a quote from it. DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, customizes, hardens, backs up, documents and supports self-hosted platforms in your own cloud accounts, data centers or air-gapped networks, and ongoing support is available as a retainer. To make quotes comparable, include your scenario inventory and blueprint exports, the systems each scenario reaches, the hosting target, the n8n edition you need, your testing and documentation expectations, and whether you want a handover or ongoing support.
What remains on the Make side during and after migration
Plan on paying for Make for longer than the rebuild itself. A Make subscription usually continues through parallel running and cutover, because live scenarios stay in production until each n8n workflow has matched its output over real traffic. The main operational risk in this window is duplicate processing. A webhook registered in both platforms, or two polling triggers reading the same app records, can create double orders, duplicate tickets or repeated messages. Assign one owner for each trigger, and switch the Make scenario off at the point where n8n takes over. Keep the disabled scenario in place for a fallback period instead of deleting it.
Set the decommission date from a checklist, not from the calendar. Before the date is fixed, confirm that every scenario has a working n8n equivalent, that each connection has been recreated and tested in n8n, and that the team has run through at least one full billing cycle without incidents. Ask the Make account owner to confirm in writing when the current billing period ends, what happens to the plan if scenarios are removed, and how cancellation takes effect. Make's current terms and help center set these details, so confirm them against the live documents rather than relying on this page. Connections are not in the blueprint, so keep a separate inventory of every connection and its owner.
Blueprints are the main artifact that leaves Make. Each Make blueprint export is a JSON file with the scenario's modules, module settings and mapped values, but it contains no connections or credentials. Store the files in your own version control with the migration record, and treat them as design documentation, not as a restore point. Before closing the account, confirm with Make which execution history, error logs and scenario run data remain accessible after cancellation, and export anything your auditors or incident teams need. On the n8n side, decide where execution logs go, since log streaming is included only in the Business and Enterprise plans.
How DeployOpen scopes a fixed-price n8n implementation
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Make to n8n move, we start from a written scope that lists which scenarios, credentials, integrations and environments are in and out before any build work begins.
How we scope
- We inventory your Make scenarios and their monthly credit use, using blueprint exports as the starting point.
- The written scope names which scenarios move, which stay on Make, and which are retired.
- We record every connection that must be recreated, along with the owner who holds each credential.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy n8n in your environment, choosing the license edition your written scope requires.
- Scenarios are rebuilt as n8n workflows, with routers, iterators and aggregators mapped to equivalent nodes.
- Each rebuilt workflow is tested against its Make output, including error paths and retries.
- Credentials are stored under your encryption key management, and access is restricted to named roles.
How we hand over
- We document every workflow, its trigger, owner, dependencies and the Make scenario it replaces.
- Runbooks cover deployment, backup and restore, upgrades and the procedure for rotating the encryption key.
- Your team receives the cutover plan, with a parallel run period and a defined rollback path for each workflow.
- Licensing notes record the Sustainable Use License terms that apply to your internal use case.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainer scope can cover monitoring setup, n8n version upgrades and periodic workflow regression tests.
- Ask any provider to confirm the n8n release you will run, and the support terms in writing before you sign.
- Your quote should list build, licensing, hosting and retainer costs as separate line items for comparison.
