Self-Hosting n8n vs Activepieces at Scale (2026): Queue Mode, High Availability & the License Line

Most comparisons stop at the first container. This one starts where a single box runs out of headroom — and shows which scaling and security features each platform quietly puts behind a paid license.

Who this guide is for

This is not a "which tool should I try" article — we wrote that comparison already, and a separate Docker setup and day-2 operations walkthrough covers the first deploy. This guide is for the moment after that: your single container is pinned at 90% CPU, a long-running workflow is blocking webhooks, and someone in security is asking who can see production credentials.

In other words, it's for B2B teams moving from "it runs" to "it runs reliably for the whole company." We'll compare the two platforms on the three things that actually matter at that stage: how they scale horizontally, what high availability really requires, and where the license line falls on the security and governance features auditors ask about.

Scaling at a glance

The pattern is worth saying out loud: raw scaling is free on both. What costs money is resilience (active-active HA) and governance (secrets, SSO, RBAC, audit). Budget for those, not for workers.

The shared architecture (and where it diverges)

Under the hood, both platforms converge on the same proven shape once you scale: a lightweight front layer that receives triggers, a message queue that holds pending jobs, a pool of stateless workers that execute them, and a database that persists everything.

The divergence is in the details:

• n8n calls this queue mode. The main instance handles timers, webhooks, and the editor UI; it hands execution IDs to Redis, and worker processes pick them up. Per n8n's docs, queue mode requires Redis and a real database — running it on SQLite is explicitly unsupported.
• Activepieces ships stateless app and worker containers. You separate workers from the app server using three environment variables; workers authenticate with a JWT signed by the same AP_JWT_SECRET as the app and fetch their config from it. Crucially, workers have no direct access to Redis or the database, which shrinks the blast radius if a worker is compromised.

That last point is a genuine architectural difference, not marketing. n8n workers connect directly to Redis and Postgres; Activepieces workers talk only to the app server. If your threat model worries about a malicious piece of code exfiltrating database credentials, Activepieces' isolation is a real advantage.

Scaling n8n: queue mode, workers, and the concurrency dial

A single n8n process in "regular" mode runs everything in one event loop, so one heavy workflow can starve your webhooks. The fix is queue mode, and the good news is it's available in the free Community Edition.

What you turn on

• Set the execution mode to queue and point n8n at Redis.
• Run one or more dedicated worker processes. Each worker is a separate Node.js process that can run several executions in parallel.
• Tune N8N_CONCURRENCY_PRODUCTION_LIMIT per worker — n8n recommends a concurrency of 5 or higher. Throughput then scales with workers × concurrency.
• Optionally run separate webhook processes so inbound webhooks never compete with execution for CPU.

As a rough capacity anchor: as of mid-2026, n8n community guidance and host benchmarks suggest a well-tuned instance on 4 vCPU / 8 GB RAM with PostgreSQL can sustain 200+ active workflows and thousands of executions per day. Beyond that, you add workers rather than a bigger box. Always confirm against your own workload — execution weight varies wildly between a 2-node ping and a 40-node data pipeline.

Scaling Activepieces: stateless workers you just add

Activepieces' scaling story is deliberately boring, which at scale is a compliment. Because the app and worker containers are stateless, horizontal scaling is mostly "run more worker containers behind the app server."

What the separation looks like

• On the app machine, set AP_CONTAINER_TYPE=APP.
• Generate a worker token via the CLI (npm run workers token), signed with your shared AP_JWT_SECRET.
• Start worker containers pointed at the app server; they pull configuration automatically — no separate Redis/DB credentials handed to each worker.
• Give each worker a persistent volume to cache pieces and flows. The first uncached execution of a piece is slow; the cache fixes that, so don't skip it on ephemeral nodes.

The two practical wins here are simpler credential management (workers never hold database secrets) and true active-active scaling without a license gate — you can sit several identical app+worker stacks behind a load balancer yourself. The trade-off is that you own that HA design; there's no managed leader-election feature doing it for you, and the production-hardening docs are thinner than n8n's.

High availability: the honest gap

This is where the two diverge most, and where teams get surprised after go-live.

n8n gives you a supported, documented HA design — multi-main with automatic leader handoff if the leader crashes or its event loop stalls — but it lives behind the Enterprise license. You get a vetted answer; you pay for it.

Activepieces gives you the building blocks for HA (stateless containers) under MIT, but no managed control-plane redundancy. You get freedom; you own the design and its edge cases.

Neither is "better" in the abstract. If you have a platform team that can stand up redundant stateless stacks and a load balancer, Activepieces' approach is cheaper and unrestricted. If you'd rather buy a supported HA path and put your engineers on product work, n8n Enterprise is the faster route to a signed-off architecture.

The license line at scale (the part that bites)

At one workflow, licenses are an afterthought. At company scale, they decide what you can legally do. Here's the distinction that matters most:

n8n: fair-code, free for internal use

n8n's Sustainable Use License lets you use, modify, and self-host for free as long as the automation serves your own internal business purposes. Profit is fine — automate a million-dollar process all you like. What's prohibited is turning n8n itself into the product: embedding it in a SaaS you sell, reselling automation as a service to clients, or letting external users trigger workflows as a paid offering. (Consulting and building workflows for clients is explicitly allowed.) Cross that line and you need a commercial agreement.

Activepieces: MIT engine, paid enterprise add-ons

The Activepieces automation engine is MIT — about as permissive as it gets. You can embed it, ship it, and build on it. The paid edition (in the packages/ee tree) covers SSO, audit logs, custom project permissions/roles, and white-label embedding. So the engine is free to commercialize; the enterprise governance features are not.

Security & governance at scale

Once more than a handful of people share an instance, auditors care about four things. On both platforms, the enterprise-grade versions of these are paid — so plan budget regardless of which you pick:

• External secrets. n8n Enterprise integrates HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, and Infisical. On the free tier, credentials live encrypted in n8n's own database — workable, but not what a SOC 2 reviewer hopes to see for a fleet.
• SSO & enforced 2FA. SAML/OIDC/LDAP and instance-wide 2FA are Enterprise on n8n; SSO is in Activepieces' paid edition. Below that, you manage users in-app.
• RBAC. Custom roles and per-project permissions are paid on both. Free tiers give coarse access control only.
• Audit logging / log streaming. Pushing events to your SIEM is Enterprise on n8n and a paid feature on Activepieces. Without it, your audit trail is whatever the UI shows.

The takeaway for a scaling B2B team: the free versions of both are perfectly fine for an engineering-team automation backbone. The moment compliance, finance, or external-facing data enters the picture, you're buying an enterprise tier on either one — so compare those quotes, not just the open-source feature lists.

Resource & cost reality at team scale

Self-hosting "free" software at scale still has a real bill. It breaks into three buckets:

1. Compute. A production baseline of ~4 vCPU / 8 GB for the main/app tier, plus worker nodes sized to your execution volume. Both platforms let you scale workers horizontally, so this grows roughly linearly with load.
2. Managed dependencies. A real PostgreSQL and a Redis instance. Self-managing these is possible but, at HA scale, a managed database/cache is usually cheaper than the on-call burden.
3. License (optional). Zero if internal-use and you can live without enterprise governance — or an annual Enterprise contract (custom-quoted, sales-assisted on both) once you need HA/SSO/secrets/audit.

One efficiency note worth flagging: there is no per-execution metering on either self-hosted engine. Unlike usage-based cloud automation, doubling your run volume costs you compute, not a bigger SaaS invoice — which is exactly why high-volume teams self-host in the first place. If your volume is modest and predictable, though, a managed cloud tier can still be cheaper than paying engineers to run Redis at 2 a.m.

n8n at scale: pros & cons

Activepieces at scale: pros & cons

Who should choose which at scale

• You're embedding automation into a product you sell. Activepieces — the MIT engine is the only legal option of the two.
• You need a signed-off, supported HA architecture fast. n8n Enterprise (multi-main) buys you a vetted answer and a support SLA.
• You have a capable platform team and want maximum freedom at minimum license cost. Activepieces — DIY active-active on stateless containers, no per-feature gate on the engine.
• Your workflows touch dozens of niche enterprise systems. n8n — connector depth wins, and you'll likely need its enterprise secrets/RBAC anyway.
• Security wants minimal credential exposure on execution nodes. Activepieces — workers never hold DB/Redis secrets.
• You'd rather not run Redis and workers at all. Either platform's managed cloud — buy back the ops time until volume justifies self-hosting.

Still deciding on the tools themselves rather than the scaling model? Our full n8n vs Activepieces comparison weighs connectors, UX, and pricing, and the Docker self-hosting guide walks the first deploy step by step. If your stack also leans on Notion or Slack, see our Notion API integrations guide and Slack–HubSpot integration walkthrough for connector patterns worth automating.

Frequently asked questions

Methodology

Based on our research, this comparison was built by reviewing the official n8n and Activepieces documentation, licenses, and community announcements in July 2026, focusing specifically on horizontal scaling, high-availability architecture, and the boundary between free/open-source and paid enterprise features. We did not load-test the platforms ourselves; capacity figures are drawn from vendor guidance and published host benchmarks and should be validated against your own workloads. Licensing summaries reflect the Sustainable Use License (n8n) and MIT plus commercial enterprise edition (Activepieces) as documented at the time of writing; verify current terms before making procurement decisions.

Ken Hayashi

Technology consultant with 10+ years in the Japanese tech industry. Specializing in SaaS evaluation, workflow automation, and B2B tool integration.