An n8n automation agency for workflows you can self-host, secure and keep running

What you should get from an n8n automation agency

Anyone can import a template. An n8n partner should add the parts templates leave out: a process worth automating, workflows that fail loudly instead of silently, a platform that survives a server restart and a security advisory, and someone who will say when n8n is the wrong tool. This page covers those decisions. For step-by-step installation, see our n8n self-hosting guide for 2026.

Self-hosted n8n vs n8n Cloud

Our usual advice: choose n8n Cloud if nobody on your side will own a server and your data rules allow it. Self-host when credentials and payloads must stay in your network, when volume makes execution-based plans expensive, or when you need custom nodes and metrics. Self-hosting is cheaper in licence terms and more expensive in attention.

The licence: fair-code, not open source

n8n’s source is public, but it is not OSI open source. The community edition uses the Sustainable Use License, a fair-code licence that permits use only for your own internal business purposes or for non-commercial or personal use. Files marked .ee fall under a separate enterprise licence. n8n’s licence FAQ draws the practical line:

• Allowed: running n8n for your own business, paying an agency to build and maintain your workflows, and using n8n behind the scenes in your product where users trigger automations you built.
• Needs a commercial agreement with n8n: hosting n8n as a service where clients build their own workflows, letting your product’s end users configure workflows, white-labelling n8n, or forking it into your own automation product.

We build inside your instance, under your licence, which keeps the question simple. If your plan involves selling automation to your own customers, talk to n8n before you build.

Queue mode: Redis, Postgres and workers

By default, one n8n process does everything. In queue mode, the main instance handles the editor, timers and incoming webhooks and puts execution IDs on a Redis queue. Workers pick them up, read the workflow from PostgreSQL, run it and write the result back. Optional webhook processors take incoming HTTP load off the main instance. What catches people out:

• Every main, worker and webhook process needs the same encryption key, or workers cannot read credentials.
• Workers default to ten concurrent jobs. Many workers with low concurrency can exhaust the Postgres connection pool.
• Binary data cannot sit on a local filesystem in queue mode; use S3-compatible storage.
• Multi-main high availability is an Enterprise feature. Without it, plan for a fast restart of the main instance rather than zero downtime.

Hardening checklist

• Set and back up the encryption key. Set N8N_ENCRYPTION_KEY explicitly and store it outside the container. Lose it and every saved credential becomes unreadable. In 3.0, encryption key rotation is always on, so plan for rotation rather than a key that never changes.
• Keep the editor off the public internet. Put the UI behind a VPN or an identity-aware proxy and expose only webhook paths.
• Use SSO and two-factor authentication. SSO (SAML or OIDC) and LDAP come with the paid self-hosted Business and Enterprise plans. On Community, enforce 2FA at minimum.
• Lock down code execution. Since 2.0, Execute Command and Local File Trigger are disabled by default and the Code node cannot read environment variables. Keep it that way, block other nodes you do not use, and run Code in external task runners, which n8n calls the only isolation layer between user code and the instance.
• Authenticate every webhook. Use header, basic or JWT authentication on the Webhook node, verify provider signatures and rate-limit at the proxy.
• Patch on a schedule. CVE-2025-68613, an expression-injection flaw rated 9.9 in its GitHub advisory, let authenticated users run code on the server; CISA added it to its Known Exploited Vulnerabilities catalogue in March 2026. CVE-2026-21858, rated 10.0, exposed server files to unauthenticated attackers through certain form-based workflows. Fixes existed for both, yet public scans kept finding unpatched instances online.
• Export metrics. Set N8N_METRICS=true, scrape /metrics with Prometheus, use /healthz/readiness for container probes and route failures through an error workflow to your alerting.

n8n vs Make vs Zapier at volume

The shape of the pricing matters more than the price list. Illustrative example: a ten-step workflow that runs 20,000 times a month is 20,000 executions on n8n Cloud, but somewhere between 180,000 and 200,000 billable steps on a per-step model. For a few two-step automations the gap is small, and Zapier’s app catalogue may win.

Planning the n8n 2.x to 3.0 upgrade

n8n announced version 3.0 with a beta on 27 October 2026 and a stable release planned for early December 2026. It removes legacy nodes (Function, Function Item, Item Lists, Cron, Interval, the legacy OpenAI node and older AI Agent modes), ends npm and npx installs so self-hosting runs on Docker, and tightens security defaults. The upgrade is one-way. Our plan:

1. Update to the latest 2.x release and open Settings > Migration Report (available from 2.39).
2. Fix, replace or consciously skip each flagged workflow and setting. Many fixes apply from the report and save as new workflow versions.
3. If you install with npm today, move to Docker first, still on 2.x, so you change one thing at a time.
4. Back up the database and the encryption key.
5. Clone production to staging, upgrade staging and run your critical workflows against test data.
6. Upgrade production in a quiet window once 3.x is stable, with the backup as your rollback.

Dates to plan around: 2.x keeps security and critical fixes for 12 months after 3.0 goes stable, and 1.x support ends on 31 December 2026. There is no direct path from 1.x to 3.0, so 1.x users should move to 2.x now.

What drives the cost of n8n work

• How many workflows you need and which systems they touch, especially systems with no ready-made node.
• Error handling and data quality: retries, deduplication and reconciliation take longer than the happy path.
• Platform needs: single instance or queue mode, high availability, backups and monitoring.
• Security and compliance: SSO, network isolation, audit trails and DPDP or contract requirements.
• Licence: Community is free, while SSO, Git-based version control and multiple environments need a paid n8n plan.
• Ongoing support: patching, upgrades and on-call cover, if you want them.

Common mistakes

• Leaving the editor public with the owner account and no 2FA.
• Letting n8n generate its encryption key inside a container volume that later gets recreated.
• Running production on SQLite, then trying to add workers.
• No error workflow, so customers discover failures first.
• Building core product logic in n8n because it was quick, then fighting it at scale.

How to choose an n8n automation agency

1. Ask how they would host it. Expect queue mode, Postgres, tested backups and an editor that is not public.
2. Ask how they track security advisories and how fast they patch.
3. Check that workflows are exported to Git and documented, not just left in the editor.
4. Ask about error handling: error workflows, retries and alerts.
5. Confirm they understand the Sustainable Use License for your use case.
6. Ask for their 3.0 upgrade plan before you sign.
7. Prefer an agency that will tell you when Zapier, Make or plain code fits better.