When does Make.com stop being cheaper than self-hosted n8n?
Hosted automation bills per operation, self-hosting bills per server. The crossover is real, and it is usually further along than people expect.
Per-operation pricing is a good deal when you are starting out. You pay for what you use, there is nothing to run, and a working automation can exist the same afternoon. The awkward part is that the bill grows with success: the more the business automates, the more the automation costs, and the increase arrives without anyone deciding on it.
Self-hosting changes the shape of the cost rather than simply lowering it. You pay for a server whether it runs ten tasks or ten million. The question is where the two lines cross for you — and that depends on more than the headline numbers.
Count operations, not scenarios
The usual surprise is not how many automations you have but how many operations each run consumes. A scenario that loops over a list of records can use one operation per record, per step. A daily job over a few hundred rows adds up far faster than its description suggests.
Before comparing anything, look at actual consumption rather than the number of workflows. It is also worth knowing that scenarios can often be restructured to do identical work for noticeably fewer operations — sometimes that alone settles the question.
The costs people leave out of the self-hosted side
A server is the smallest part. Self-hosting also means somebody keeps the platform patched, takes backups, tests upgrades before they land, holds the third-party credentials securely, and notices when it stops. Those are real costs, whether they appear on an invoice or quietly consume someone's week.
This is precisely why managed hosting exists as a middle option: the cost model of self-hosting without having to become the operator of it.
The costs people leave out of the hosted side
On the hosted side, the figure that gets forgotten is the cost of the ceiling. When automation is metered, teams start rationing it — not automating something worth automating because of what it would add to the bill. That is a genuine cost, just not one that appears on a statement.
The other is portability. Scenarios built in a hosted builder do not move. Changing platform later means rebuilding rather than exporting, which is worth knowing while volumes are still small.
A reasonable way to decide
Three questions settle most cases. How many operations are you actually consuming each month, and how fast is that growing? Does the data moving through these workflows include customer or financial records you would rather keep on infrastructure you control? And is there anyone to look after a self-hosted platform, or would it need to be managed for you?
If volumes are modest and growth is flat, hosted is the sensible answer and we will say so. If consumption is climbing, or the workflows carry data you would prefer to keep close, self-hosted automation is worth pricing properly.
Whichever side you land on, add the error handling
This matters more than the platform choice. Both hosted and self-hosted builders make the happy path easy, so it is natural to ship a workflow that has never been tested against a timeout, a rate limit, or a malformed response.
Add two things to anything that matters: make every step that writes to another system safe to run twice, and put a check in front of the workflow that notices when it stops. A disabled workflow or an expired credential raises no error at all — things simply stop happening, which is the failure mode that takes longest to spot.