What we build in n8n

What it is, and where it sits

n8n is a workflow automation platform you can self-host. Workflows are node graphs, similar in shape to Make, but with first-class code nodes and a JSON representation that lives happily in version control.

The reason to choose it is almost always economics or data residency rather than features. When one of those applies it is decisively the right answer; when neither does, Make is usually the easier tool.

What we build in it

• High-volume event processing where per-operation pricing would be punishing
• Workflows handling regulated or residency-constrained data that cannot leave your infrastructure
• Data transformation pipelines using real code inside the workflow
• Custom API integrations for systems with no off-the-shelf connector
• AI orchestration with retries, fallbacks and structured-output validation
• Internal tooling where workflows are version-controlled alongside application code

How it is priced

Two very different models.

n8n Cloud charges per execution — one whole workflow run regardless of how many steps it contains. This inverts Make's incentive: a 40-step workflow costs the same as a 3-step one, so complex workflows become cheap.

Self-hosted charges nothing per anything. You pay for a server — typically $10 to $40 a month for a small cloud instance — and run unlimited executions. The constraint becomes CPU rather than billing.

The saving at volume is real and can run to thousands a year. It evaporates if self-hosting consumes an afternoon a month of someone expensive, so count that honestly.

When it is the right choice

• Execution volume is high — above roughly 100,000 operations a month, this is usually decisive
• Data cannot leave your infrastructure for compliance or residency reasons
• Your transformations involve genuine programming rather than field mapping
• You want workflows in Git with review and rollback
• You already run containers or a cluster, so the marginal cost of one more service is near zero

Limits worth knowing before you commit

• Self-hosting is a commitment. Patching, backups, monitoring and upgrades. Not hard, but not nothing, and it needs an owner.
• Smaller connector library than Make. More things need custom HTTP nodes, which is fine for us and less friendly for your team later.
• Less approachable for non-technical staff. The code-node flexibility that makes it powerful also makes workflows harder for an operations manager to read.
• You own the uptime. If your server is down, your automations are down, and that is your problem rather than a vendor's.