For a long time, "low-code automation" meant Zapier or Make and a monthly bill that scaled with how successful your automations became. n8n flipped that economics: it is source-available, runs anywhere Docker runs, and the marginal cost of a million executions is a slightly larger VM. We have shipped n8n as the workflow backbone for fourteen client projects in the last eighteen months. This is what we have learned about running it for real.
A note on where this sits commercially, since most people arrive here while shopping for workflow automation services rather than for a runtime. Those engagements usually cover three things: choosing the orchestration layer (n8n, a managed platform, or plain code), building the integrations between the systems you already run, and operating the result once it matters to the business. This post is about the third, which is the part vendors quote least honestly. If you want the shape of the whole engagement instead, that is our AI automation services work, and RPA vs AI agents covers how to decide which parts of a process should be deterministic and which need judgement.
When n8n is the right answer
n8n is not a replacement for code. It's a replacement for the seam between systems: the part where a CRM event needs to land in a spreadsheet, ping a Slack channel, and create a Jira ticket. Three things make it a fit:
- The integrations already exist. 400+ first-party nodes covers most SaaS APIs you would otherwise write a wrapper around.
- Non-engineers need to read the flow. A visual graph is a real artifact during stakeholder reviews. We have closed scope arguments by walking through a single workflow.
- The logic is mostly orchestration. If a step needs heavy data processing, do it in code and call it from n8n via an HTTP node. Don't torture yourself with twelve Set-nodes in a row.
Default mode vs queue mode
n8n's default execution mode runs everything in the main process. That's fine for ten executions an hour and miserable above that: one slow webhook stalls every other workflow. Switch to queue mode the moment you cross into hundreds of executions a day:
- The main process becomes the UI + webhook receiver only.
- A Redis instance acts as the job queue.
- Worker processes (we run 4-8 per VM) pull jobs and execute them in parallel.
Setup is environment-variable level: EXECUTIONS_MODE=queue, point at Redis, run n8n worker on as many machines as you need. Scaling out is then a Compose replica count.
The database choice that bites everyone
Default SQLite works until it doesn't, and the failure mode is silent slowness, not a clean error. We switch every deployment to Postgres on day one. Migration is straightforward with the official export/import scripts, and the performance gain on workflow listing and execution history is dramatic past a few thousand stored runs.
Secrets: stop pasting tokens into the UI
n8n has a credentials system that encrypts secrets at rest using N8N_ENCRYPTION_KEY. Three rules we enforce on every deployment:
- The encryption key lives in a secrets manager (Vault, AWS Secrets Manager, SOPS). It is never in
.envon disk. - API credentials are created via the API, not pasted into the UI by hand, so they go through your code review.
- External-secrets integration syncs credentials from your secrets store into n8n. Rotation is then a one-place change.
Workflow versioning
The single biggest weakness of low-code tools is that "the workflow" is a row in a database that anyone with the editor can change. We solve it with two practices:
- Workflows live in Git. n8n's source-control integration commits each workflow's JSON to a branch. Pull requests review changes the same way code does.
- Environments are real. Dev → staging → prod n8n instances, with promotion via Git merges, not the UI's "import" button.
Observability
The built-in execution log is fine for debugging a single run and useless for spotting trends. We pipe n8n.execution.finished events into the same observability stack as the rest of our services, usually Loki for logs and Prometheus for metrics. The three dashboards every n8n deployment should have:
- Executions per workflow over time, with a "failed" overlay.
- p95 execution duration per workflow, so the slow ones get refactored.
- Queue depth and worker utilization, so you scale workers before they backlog.
The eight integrations we ship most often
Across our client work, these account for roughly 80% of the node usage:
- HTTP Request: for everything that doesn't have a first-party node yet.
- Postgres / MySQL: reading from operational databases without giving n8n write access.
- Webhook: entry point for almost every workflow.
- Slack / Microsoft Teams: notifications and human-in-the-loop approvals.
- Google Sheets / Airtable: staff-facing read/write surface for things that don't deserve a real UI.
- OpenAI / Anthropic: classification, extraction, summarization steps inside flows.
- HubSpot / Salesforce: CRM hand-off, lead enrichment.
- S3 / GCS: file landing zones and archival.
What we still write code for
n8n is not the right place for: anything that needs sub-100ms latency, anything that runs millions of times a day with the same shape (write a worker instead), or anything where the failure mode is "lost money." Use it for the connecting tissue, not the load-bearing walls.
The honest summary: n8n replaces three Zapier seats, two manual ops engineers, and most of the "can someone write a quick script for…" Slack messages in a small team. It is not magic. It is a well-engineered piece of glue.
Starting points
- Start with
docker composein default mode for the first two weeks while you learn the editor. - Move to queue mode + Postgres before you have anything stakeholders depend on.
- Adopt the Git source-control integration before workflow #10.
- Wire metrics in before you cross 1,000 executions/day. After that, you can't retro-fit visibility. You'll be too busy firefighting.