n8n Self-Hosted vs Cloud: Cost and Control

Choosing between n8n Cloud and a self-hosted instance is not primarily a pricing decision. It is a decision about who owns availability, security patches, backups, and upgrades, and whether your organisation has the appetite to carry those responsibilities. Both options run the same workflow engine, so the feature list is nearly identical. What changes is the operational contract around it, and that contract is what teams underestimate. Cloud users inherit the provider's operational maturity along with its plan limits; self-hosted teams inherit full flexibility along with full accountability. Naming that tradeoff explicitly prevents a price comparison from turning into resentment when the first incident arrives.

A self-hosted install starts simply. One container, one Postgres database, an environment file, and a domain behind a reverse proxy is enough to run workflows for a small team. As usage grows, the shape changes: queue mode with separate worker containers, Redis for the queue, dedicated storage for binary data, and a process for database migrations during upgrades. None of that is exotic, but it is real infrastructure with real failure modes. If nobody on the team is comfortable running it, the savings on the subscription may not survive the first incident.

Security responsibility is the sharpest difference. With self-hosting, you own operating system patching, firewall rules, TLS certificates, secret storage, database access controls, and audit review. The n8n application still validates credentials and controls user access, but the layer underneath is yours. With cloud, the provider handles the platform while you still own credential hygiene, user roles, and what data you allow workflows to process. Neither option removes the need for least-privilege API keys and a credential rotation routine.

Data residency and retention often decide the question before cost does. Self-hosting lets you keep payloads inside a chosen network or country, log to your own systems, and delete data on your own schedule. Cloud plans offer region choices and reasonable controls, but execution history and stored data live in the provider's environment. If your contracts or regulators require that customer records never leave specific infrastructure, that constraint is usually the end of the discussion, and it should be documented before any build work begins.

The maintenance burden has a rhythm. Upgrades arrive regularly, some carry database migrations, and occasional breaking changes require reading release notes before applying them. Node runtimes receive security updates. Dependencies age. A reasonable self-hosted routine includes a staging instance that mirrors production, a tested restore procedure, and a calendar entry for upgrades rather than an impulse to click the update button on a busy Friday. Teams that treat upgrades as routine avoid emergency work later.

Scaling behaviour differs too. A single instance handles a surprising amount of work, but high-volume or long-running tasks eventually need queue mode, concurrency tuning, and worker capacity planning. Cloud absorbs some of that elasticity in exchange for plan limits, and its execution limits become the ceiling you design around. Self-hosting removes artificial ceilings but requires you to watch memory, database size, and queue depth yourself. Both are manageable; only one expects you to notice the problem first.

The cost comparison should be honest on both sides. A cloud subscription is predictable and includes hosting, platform-level backups, and upgrades. Self-hosting replaces that fee with server costs plus engineer time plus the opportunity cost of what that engineer is not doing. For a small number of low-risk internal workflows, the subscription usually wins. For high-volume processing or strict data controls, self-hosting can win clearly. Some teams use both: cloud for critical client-facing workflows and a self-hosted instance for internal, high-volume tasks.

Upgrade paths deserve their own plan. Cloud users should know how versions are rolled out, whether changes can be scheduled, and how to test against an upcoming version. Self-hosted users should maintain a staging environment, back up the database before every upgrade, review the changelog for breaking changes, and keep a rollback path that has actually been tested. The worst outcome is not an old version, it is an upgrade performed live with no backup and no way to revert.

A short decision checklist keeps the choice grounded. Does regulation or client contract restrict where data may live? Is there an internal owner with the skills and time to run infrastructure? Is the workload steady or spiky? How much does an hour of downtime cost compared with a year of subscription? Does the team need single sign-on and audit controls, and can it maintain them? Answering those five questions usually produces a clear answer, and a hybrid arrangement when it does not.

Whichever route you take, finish the decision properly. Document who owns the instance, where backups live, how a restore is performed, which credentials exist and when they were last rotated, and how upgrades are scheduled. Run one restore drill before you trust the backup. Finished work is not a running container; it is a service with a named owner and a tested recovery path that someone other than the original builder can follow.