I’ve set up n8n for solo media buyers running three offers out of a laptop, and I’ve set it up for agencies pushing tens of thousands of executions a day across a dozen client accounts. The deployment decision looks trivial from the outside — it’s a toggle between “let n8n host it” and “host it yourself” — but I’ve watched teams burn months and real money getting it wrong in both directions.

Here’s the pattern I see most often. A solo affiliate signs up for n8n Cloud Pro because a YouTube tutorial told them to, then discovers three months later that their lead-enrichment workflow (which polls an API every five minutes) has already blown through the monthly execution allowance twice. On the other end, an agency spins up a $5/month VPS to “save money,” and six weeks later their tracking-sync workflow goes down at 2 a.m. because nobody renewed the SSL cert or watched the disk fill up with execution logs. Both mistakes are avoidable. Both come from treating this as a feature comparison instead of a business decision.

This isn’t a rehash of n8n’s own pricing page. It’s what I’d tell you if you sat down with me before signing anything — for a one-person affiliate operation, a growing agency, an internal automation team, or a shop running AI-heavy workflows that chew through executions faster than anyone expects. The right call depends on your execution volume, your team’s tolerance for babysitting infrastructure, and how sensitive the data flowing through your workflows actually is. Get it wrong and you’re either paying for headroom you don’t need or doing unpaid sysadmin work at odd hours.

Where control lives in each model: n8n owns the server on Cloud, you own it self-hosted.

What Are the Differences?

Skip the marketing copy — here’s what actually changes between the two:

Dimension	n8n Cloud	Self-Hosted
Hosting	Managed by n8n, data stored in Frankfurt	You choose the server, region, provider
Maintenance	None — n8n handles it	You patch, monitor, troubleshoot
Updates	Automatic, no downtime to manage	Manual, on your schedule and risk
Security	n8n’s infrastructure and access controls	Your responsibility end to end
Scalability	Capped by plan tier and execution allowance	Limited only by your infrastructure
Pricing	Fixed monthly fee tied to execution count	Free software, variable infra cost
Control	Limited to app-level settings	Full control over environment, networking
AI integrations	AI Assistant with monthly credit allowance	Bring your own API keys, no credit ceiling

The trap is reading this table and picking based on which column has more checkmarks. That’s not how the decision works. A solo affiliate running four workflows doesn’t need “full control over networking.” An agency running client data through a dozen automations can’t get away with “limited to app-level settings.” Match the row that actually matters to your situation, not the one that sounds most impressive.

When n8n Cloud Is the Better Choice

If you’re starting out, n8n Cloud is almost always the right first move, and I say that as someone who leans self-hosted for anything serious. The reason is simple: your first few weeks with n8n are about learning how the tool thinks — nodes, expressions, error workflows — not about learning Docker networking. Paying $20–24/month to skip that entire second problem is a good trade.

This holds for solo affiliates testing whether automation even fits their workflow, for MVP projects where you’re validating an idea before committing engineering time, and for internal tools that a non-technical team member needs to own without calling you every time something breaks. If nobody on your team can explain what a reverse proxy does, self-hosting isn’t saving you money — it’s deferring a cost and adding risk on top of it.

n8n Cloud’s honest limitations: the Starter plan’s 2,500 executions disappear fast if any workflow polls on a schedule rather than firing on webhooks — a five-minute polling trigger alone burns roughly 8,600 executions a month, blowing through Starter in about nine days. Concurrent execution caps (5 on Starter, 20 on Pro) matter more than people expect once you’re running parallel enrichment or scraping jobs. And the AI Assistant credit allowance, while generous for exploration, isn’t unlimited — heavy AI-node users hit the ceiling before they hit the execution ceiling.

When Self-Hosted Is the Better Choice

The switch to self-hosted usually isn’t triggered by price. It’s triggered by hitting a wall the Cloud plan wasn’t built to solve. I’ve seen three walls repeatedly: execution volume outgrowing what a reasonable Cloud tier covers, data sensitivity that makes routing client information through a third party’s servers a real compliance concern, and workflow complexity — long-running scrapes, custom code nodes, queue-mode concurrency — that Cloud’s plan tiers weren’t designed around.

Agencies running automation for multiple clients hit this earlier than solo operators because execution volume multiplies fast — five clients each running a dozen workflows adds up well before anyone notices. Media buying teams pulling spend data across ad accounts every few minutes, running AI-heavy enrichment or creative generation, or processing thousands of conversion events a day are the clearest self-hosting candidates on this list. So are teams handling anything they wouldn’t want sitting on infrastructure they don’t control — offer terms, payout data, tracker credentials.

The self-hosted Community Edition itself costs nothing and comes with unlimited executions — you’re only paying for the server. The honest trade-off: you’ve traded a monthly bill for an ongoing maintenance obligation. If that obligation has no owner on your team, self-hosting isn’t actually cheaper, it’s just a cost you haven’t paid yet.

Pricing Comparison

Comparing subscription price to VPS price is the wrong comparison. Here’s the real math, scenario by scenario.

Solo affiliate. n8n Cloud Starter runs about $24/month billed monthly (roughly $20/month if you commit annually), covering 2,500 executions. A cheap VPS — something like a Hetzner CX22 at around $4.50/month — runs the free Community Edition with no execution ceiling at all. On price alone, self-hosting wins by a wide margin. But add setup time (Docker, reverse proxy, SSL, roughly 1–4 hours the first time) and ongoing maintenance (1–2 hours a month), and at any reasonable hourly rate that “$4.50/month” server costs more than the Cloud plan for the first few months. Where self-hosting pays off is month four onward, once the setup cost is sunk and you’re just running the thing.

Small agency. Cloud Pro runs about $60/month billed monthly (roughly $50 annually) for 10,000 executions and 20 concurrent runs. A dedicated VPS sized for production — enough RAM for Postgres plus n8n plus a Redis queue for concurrency, realistically $15–30/month — again undercuts Cloud on raw infrastructure cost, but now you’re also budgeting for backups, monitoring, and someone who actually owns the box. Managed self-hosted platforms (single-click n8n deployments on providers built for it) sit in between, typically $10–20/month, trading a little control for skipping the Docker/nginx/SSL setup entirely — often the right call for an agency that wants self-hosted economics without hiring DevOps help.

Large media buying team. At this volume, Cloud’s Business tier (roughly €667/month billed annually, around $800/month, for 40,000 executions plus SSO and Git-based version control) starts looking expensive fast, especially once overage kicks in — n8n bills Business overage in blocks of 300,000 executions at €4,000 per block, which is a brutal number if you’re consistently over. Self-hosted infrastructure at this scale — a properly sized VPS or small cluster running queue mode with multiple workers, plus a managed Postgres instance — typically lands in the $50–150/month range including redundancy. The gap between that and $800/month Cloud pricing is large enough that most teams at this volume self-host, provided they have someone technical enough to run it.

Approximate all-in monthly cost by scenario, including infrastructure and upkeep on the self-hosted side.

Team Size	n8n Cloud	Self-Hosted (all-in)
Solo affiliate	~$24/mo (2,500 execs)	~$5–10/mo VPS + your time
Small agency	~$60/mo (10,000 execs)	~$15–30/mo VPS or managed
Large media buying team	~$800/mo (40,000 execs, Business)	~$50–150/mo incl. redundancy

The hidden costs nobody puts in a pricing table: backups that actually get tested (not just scheduled), monitoring that pages someone before customers notice downtime, the engineering hours spent debugging a broken update at an inconvenient time, and the opportunity cost of your best technical person spending Tuesday afternoon on server maintenance instead of building the automation that makes the business money.

Performance

For most affiliate use cases — webhook-triggered workflows, moderate data volumes, a handful of concurrent runs — you won’t notice a meaningful speed difference between Cloud and a reasonably provisioned self-hosted instance. Where the gap opens up is concurrency and queue handling at scale. Cloud’s concurrent execution caps (5 on Starter, 20 on Pro, 200+ only at Enterprise) become a real bottleneck once you’re running parallel scraping jobs, bulk API enrichment, or AI-node workflows that fan out across many items. Self-hosted queue mode, run with Redis and multiple worker processes, scales concurrency to whatever hardware you’re willing to add — I’ve run instances with dozens of parallel workers that no Cloud tier below Enterprise could match.

Large, complex workflows — the kind with dozens of nodes, heavy data transformation, or big loops — behave the same on both, since it’s the same n8n engine either way. The practical limitation on Cloud is less about raw performance and more about hitting plan ceilings (concurrent executions, saved execution storage) before hitting any actual processing limit.

Scenario	Recommended Option
Webhook-triggered, low-moderate volume	Either — no meaningful difference
Parallel scraping / bulk enrichment	Self-hosted (queue mode)
AI-agent workflows fanning out across items	Self-hosted
Occasional, low-concurrency automations	n8n Cloud

Security

For most affiliate businesses, the security question isn’t “which option is more secure in the abstract” — it’s “where do you want your credentials and data to physically live.” On Cloud, workflow data for hosted plans is stored on n8n’s infrastructure in Frankfurt, Germany, under n8n’s access controls and encryption. That’s a reasonable, professionally-run setup for most use cases, and it means you’re not the one responsible for patching a database or rotating disk encryption keys.

Self-hosting puts that responsibility entirely on you — which is a feature if you have someone competent handling it, and a real liability if you don’t. If your workflows touch tracker credentials, payout details, or anything you’d rather not have a third party processing even under a solid privacy policy, self-hosting closes that gap. It also gives you full control over backup cadence and disaster recovery, rather than trusting a vendor’s retention window (Cloud’s saved-execution retention runs from a few days on Starter up to a year on Enterprise — beyond that window, your own exports are what you’ve got).

What actually matters for most affiliate teams: credential storage (both options encrypt credentials at rest), who can access production data, and whether you have a tested recovery plan if a server or account gets compromised. Self-hosted doesn’t automatically mean more secure — an unpatched VPS with a default SSH config is worse than n8n’s managed infrastructure. Security here is a function of who’s actually maintaining the thing, not which column you picked.

AI Workflows

AI-heavy automation is where the deployment decision matters more than people expect, because AI nodes quietly consume executions and, on Cloud, AI Assistant credits, at a rate that catches teams off guard. A workflow that calls OpenAI, Claude, or Gemini for content generation, ad copy variation, or creative scoring, then loops over dozens of items, can burn through a monthly execution allowance in days rather than weeks — especially with batch processing or agent-style workflows that make several model calls per item.

One “task” that loops over 20+ items becomes 20+ executions — and, on Cloud, 20+ AI credit draws.

On Cloud, you’re working within the plan’s AI credit allowance (2,300/month on Starter, up to 13,700 on Pro) in addition to your execution count, and self-hosted AI Assistant support is still rolling out rather than fully available. On self-hosted, you bring your own API keys for whichever model provider you’re using, so there’s no platform-side credit ceiling — your only constraint is what you’re paying the model provider directly, and your own execution volume, which is unlimited on the Community Edition. For teams running local LLMs to avoid per-call API costs entirely, self-hosting is close to a requirement, since that setup depends on infrastructure you control.

The practical guidance: if your workflows lean on AI nodes for anything beyond light, occasional use, model the execution math before picking a plan. A content pipeline generating variations across dozens of ad sets, run daily, adds up fast — and it’s cheaper to catch that in planning than after an overage invoice.

Scaling: How This Actually Evolves

Migration usually happens at the boundary between Stage 2 and Stage 3.

Stage 1 — Solo affiliate. A handful of workflows, low execution volume, no dedicated technical staff. Cloud Starter or free Community Edition on a cheap VPS both work; the deciding factor is whether you personally want to touch a terminal.

Stage 2 — Small agency. Multiple clients, execution volume climbing into the thousands monthly, first hires with some technical capability. This is where Cloud Pro or a managed self-hosted platform earns its keep — enough structure to collaborate without the overhead of running raw infrastructure yourself.

Stage 3 — Growing media buying team. Tens of thousands of executions monthly, AI-heavy workflows, multiple people building and maintaining automations. This is the stage where self-hosting usually starts making financial sense, and where queue mode with dedicated workers becomes worth setting up rather than optional.

Stage 4 — Large automation infrastructure. High-volume, business-critical automation with compliance requirements, dedicated DevOps capacity, and workflows that would be genuinely expensive to lose. Self-hosted with proper redundancy, or Enterprise (hosted or self-hosted) if you want n8n’s support SLA without giving up scale.

Migration typically happens at the boundary between Stage 2 and Stage 3 — once execution volume and team size justify the maintenance overhead, and once the cost gap between Cloud’s higher tiers and self-hosted infrastructure becomes too large to ignore.

Migration

Most migrations from Cloud to self-hosted happen for one of two reasons: the execution math stopped making sense, or the team hired someone who can actually run infrastructure and wants the control. Rarely is it planned well in advance — usually it’s triggered by an invoice or an overage warning.

The mistakes I see most often: migrating without first exporting and testing all credentials in the new environment (some credential types don’t transfer cleanly and need to be re-entered), underestimating how much of the Cloud plan’s convenience was doing invisible work (backups, SSL renewal, version upgrades), and cutting over production workflows before running them in parallel on the new instance for at least a few days. I’ve also seen teams migrate their workflows but forget that scheduled triggers start firing immediately on import — if you’re not ready for a workflow to run the moment you activate it, don’t activate it yet.

Test in this order before cutting production traffic over.

Before switching, test in this order: import workflows into a self-hosted instance running in parallel (not yet handling production traffic), re-enter and verify every credential works, confirm webhook URLs update everywhere they’re referenced externally (ad platforms, trackers, forms), and let scheduled workflows run once on a non-critical schedule before trusting them with real data. Only cut DNS or webhook endpoints over to the new instance once all of that has held for a few days without issues.

Task	Completed
Export all workflows as JSON	☐
Stand up self-hosted instance in parallel	☐
Re-enter and verify every credential	☐
Update webhook URLs everywhere referenced	☐
Run scheduled workflows once, non-production	☐
Hold in parallel a few days with no issues	☐
Cut over DNS / webhook endpoints	☐

Pros and Cons

n8n Cloud

Pros: nothing to maintain, automatic updates, predictable monthly cost, fast to get running, solid choice if nobody on the team wants ownership of infrastructure.

Cons: execution ceilings that bite harder than expected for polling-heavy workflows, concurrent execution limits that become real bottlenecks at scale, AI credit ceilings on top of execution limits, and a genuine loss of control over exactly where your data sits.

Self-Hosted n8n

Pros: unlimited executions on the free Community Edition, full control over environment and data location, no AI credit ceiling, scales concurrency as far as your hardware allows, and it’s genuinely cheaper at volume.

Cons: you own every outage, every security patch, and every 2 a.m. SSL expiry. Enterprise-grade self-hosted features (SSO, Git-based workflow versioning) aren’t actually free — Business-tier self-hosted pricing applies there too. And if nobody on the team enjoys server administration, “free” software becomes an ongoing tax on someone’s time and patience.

Decision Matrix

If you are…	Best Choice
Solo affiliate just starting out	n8n Cloud (Starter)
Small agency, a few clients	n8n Cloud (Pro) or managed self-hosted
Enterprise / compliance-heavy	Self-hosted Business or Enterprise
AI-heavy workflows, high volume	Self-hosted
Developer on the team	Self-hosted
Non-technical marketer, no dev support	n8n Cloud
Budget-conscious, willing to maintain	Self-hosted on a VPS

The one question that decides most of this: who owns server maintenance?

Common Mistakes

The single most common mistake is self-hosting too early — before anyone on the team can actually own the maintenance, treating “free software” as if it means “free to run.” A close second is underestimating maintenance itself: assuming a VPS runs itself once it’s set up, then discovering six months later that nobody’s applied a security patch since launch.

Ignoring backups is the mistake that actually costs money, not just time — I’ve seen teams lose weeks of workflow history because backups were “scheduled” but never verified to actually complete or restore. Weak security — default credentials, an exposed n8n instance with no authentication in front of it, API keys committed to a public repo — is more common than it should be given how much sensitive data flows through these workflows. Poor monitoring means you find out about downtime from a client asking why their leads stopped coming in, rather than from an alert.

On the other side, choosing Cloud despite running tens of thousands of executions a month is its own mistake — at that volume, you’re paying a real premium for convenience you may not even need anymore if your team has grown into the technical capacity to self-host.

Future Trends

AI agents are pushing execution volume up across the board — agentic workflows that reason across multiple steps and call tools repeatedly generate far more executions per “task” than a simple linear automation did two years ago, which is quietly changing the economics of Cloud pricing for anyone building agent-style workflows. MCP (Model Context Protocol) adoption is extending this further, letting n8n workflows connect to a growing ecosystem of tool servers rather than hand-built API integrations for every service.

Self-hosting continues to grow as containerized deployment gets easier — managed platforms that offer one-click n8n hosting on your own infrastructure are closing the gap between “self-hosted” and “as easy as Cloud,” which is shifting some of the historical cost/convenience trade-off. I’d expect more teams to land on a hybrid setup: Cloud for quick, low-stakes internal tools, self-hosted for anything client-facing, AI-heavy, or handling sensitive data — rather than treating the decision as all-or-nothing across an entire team.

Conclusion

If you’re a beginner or solo affiliate just testing whether automation fits your business, start on n8n Cloud Starter. Don’t self-host to save $15 a month when you’re still learning what a workflow even is.

If you’re an experienced affiliate with a handful of stable, well-understood workflows and execution volume that’s been climbing for a few months, this is your migration window — move to self-hosted before an overage invoice makes the decision for you.

If you’re running an agency, the calculus depends on client count and technical staffing: Cloud Pro or a managed self-hosted platform for a handful of clients, full self-hosted infrastructure once you’re managing double digits.

If your workflows are AI-heavy, self-host. The execution and credit math on Cloud rarely favors heavy AI-node usage once volume climbs past casual experimentation.

If you’re operating at enterprise scale with compliance requirements, self-hosted Business or Enterprise, with the support SLA that comes with Enterprise if you need vendor accountability written into a contract.

FAQ

Is self-hosted n8n free?

The Community Edition is free software with unlimited executions. You pay for the server it runs on and, if you want Business or Enterprise features (SSO, Git version control, audit logging), a license fee on top.

Is n8n Cloud worth paying for?

For anyone without a dedicated technical person, yes — the maintenance you’re skipping is worth more than the subscription in most cases, at least until execution volume grows past what a mid-tier plan comfortably covers.

Can I migrate later?

Yes, and it’s a well-worn path. Export your workflows, set up a self-hosted instance, re-enter credentials, test in parallel, then cut over. Budget more time for credential re-entry than people expect.

Which option is faster?

Neither, for typical workflows — same engine underneath. Self-hosted pulls ahead once you need concurrency beyond what your Cloud tier allows.

Which is cheaper?

Self-hosted, almost always, once you account for the fact that “free” software still needs a home. The gap widens with execution volume and narrows (or reverses) if nobody on your team can maintain a server without paying someone else to do it.

Can beginners self-host n8n?

Technically yes, practically not recommended. If you don’t already know what Docker Compose does, you’ll spend your first month learning infrastructure instead of building automations.

Does self-hosting require Docker?

Not strictly, but it’s the standard path and the one with the most documentation and community support. Some managed platforms abstract this away entirely.

Can I use AI with both versions?

Yes. Cloud includes an AI Assistant with a monthly credit allowance. Self-hosted lets you bring your own API keys for any model provider, with no platform-side credit ceiling — self-hosted AI Assistant support is still rolling out.

Is n8n Cloud secure?

Yes, for the vast majority of affiliate use cases — data for hosted plans is stored in Frankfurt under n8n’s access controls. If your data sensitivity requirements go beyond that, self-hosting gives you full control instead.

Which option is better for affiliate marketers?

Depends entirely on stage. Solo and early-stage: Cloud. Agency or team with real execution volume and technical capacity: self-hosted. There’s no single right answer independent of where you are.

Can I run n8n on a $10 VPS?

Yes, comfortably, for low-to-moderate execution volume. Once you add queue mode with Redis for concurrency and a properly sized Postgres instance, budget closer to $15–30/month for something you’d actually trust with production traffic.

How difficult is migration?

Moderate. The workflows themselves import cleanly; the friction is almost always credentials, webhook URL updates, and making sure scheduled triggers don’t fire unexpectedly the moment you activate an imported workflow.