n8n vs Make Self-Hosted: The Real Trade-Off

Updated 2026-10-27 · 1032 words

This page may contain affiliate links. If you buy through them we may earn a commission at no extra cost to you.

Quick take: if you want to actually self-host and own your automation infrastructure, data residency, no per-operation billing, full control over upgrades, n8n is the only one of these two that offers that path at all. Make has no self-hosted option on any plan, so choosing Make means accepting a cloud-only, usage-billed product in exchange for zero server maintenance. We ran n8n on our own VPS for several weeks and weighed it directly against what the same workload would have cost and taken to run on Make's cloud.

Why this comparison is lopsided by design

Most "n8n vs Make" content treats this as a feature match, pricing, integrations, canvas design. That comparison matters too, and our full Make vs n8n review covers it in depth. This piece is narrower on purpose: it's for the reader who has already decided self-hosting matters to them and wants to know what that decision actually costs and involves, not which tool has more integrations.

Here's the asymmetry up front: Make is a closed, cloud-only SaaS product. There is no self-hosted Make, not on its Enterprise plan, not anywhere. n8n is open-source and self-hostable first, with a free, Sustainable Use License core you can run on your own server indefinitely. So the real question isn't "which tool wins," it's "is the work of self-hosting n8n worth what it saves you over just paying Make to handle the infrastructure."

Comparison table

What self-hosting n8n for production actually involves

n8n's default self-hosted setup runs on SQLite, which is fine for a quick test but not for anything you'd call production. Getting it reliable means switching to PostgreSQL, enabling queue mode so executions don't pile up on a single process, and putting a reverse proxy with TLS in front of it, work we walk through step by step in our guide to self-hosting n8n. None of that is exotic, but it's real configuration time the first time through, and it doesn't end at setup: you're the one watching disk space, applying version upgrades, and restoring from backup if something breaks.

Make skips every bit of that. You sign up, build a scenario, and it runs on infrastructure you never think about. That's the entire value proposition of choosing a cloud-only tool, and for a team with no spare engineering time, it's a legitimate reason to pick Make even knowing it costs more per unit of automation over time.

The cost crossover in practice

We modeled a scheduled report that reformats around 200 spreadsheet rows daily, a modest, realistic small-business workload. On Make, each row processed inside the loop counts as its own operation, so a run like this can burn through several thousand operations a month well before the scenario count alone suggests it's heavy usage. Priced out, that pushed us into a mid-tier Make plan running $20-$30 a month for this workflow alone, with the bill climbing further as more scenarios get added.

Self-hosted n8n has no equivalent per-row cost. The same workflow runs as many times as it needs to on a $10-$15/month VPS, and that server cost doesn't move whether the workflow processes 20 rows or 20,000. The crossover point arrives fast for anything that loops over real data volume; for a single lightweight scenario that runs a handful of times a day with no loops, Make's free or entry tier can stay cheaper simply because there's no server bill at all.

Data control and compliance

This is the argument that doesn't show up in a pure cost comparison. With self-hosted n8n, workflow data, credentials, and execution logs never leave infrastructure you control. That matters directly if you're under a client contract, a data-residency requirement, or an internal policy that restricts where business data can be processed. Make, like any cloud SaaS tool, processes and stores your scenario data on its own infrastructure; its security practices are reasonable for most small businesses, but "the data never left our server" isn't an option Make can offer, full stop.

When NOT to self-host n8n

Skip self-hosting n8n if nobody on your team has the bandwidth, or the willingness, to own a server long-term. The software is free, but "free" doesn't include your time spent on TLS renewal, Postgres maintenance, and version upgrades, and a neglected self-hosted instance is a worse outcome than just paying for a managed tool. n8n Cloud exists as a middle ground if you want n8n specifically without taking on that ops burden yourself.

When NOT to use Make

Skip Make if data residency is a hard requirement, if your workflows loop over large row volumes regularly, or if the per-operation bill is climbing faster than your budget tolerates. None of those pressures have a fix on Make's side beyond upgrading plans; self-hosted n8n removes all three at the cost of owning the server yourself.

Which should you pick?

Choose self-hosted n8n if you have the ops bandwidth (or the willingness to build it), your workflows process real data volume, or data residency is non-negotiable. Choose Make, or n8n's own cloud plans if you want n8n specifically, if you'd rather pay a usage-based bill than own a server, and your workflows don't loop over enough rows to make that bill painful. For the wider feature comparison beyond this infrastructure question, our Make vs n8n article covers canvas design, AI-agent tooling, and integration breadth directly, and our best self-hosted alternatives to Make.com roundup covers more than just n8n if you're still deciding whether self-hosting anything is the right move.

Check current terms before committing either way: n8n publishes its self-hosting documentation in full, and Make covers its current operations-based pricing tiers on its own site.

Save this to Pinterest