n8n Use Cases: What It Is Genuinely Good At, and What It Is Not

n8n is a workflow automation tool: a visual editor where nodes connect a trigger to a sequence of actions across APIs, with the option to drop into JavaScript when the visual layer runs out. It is genuinely good at API glue, alerting, scheduled synchronisation, form and webhook handling, and internal tooling. It is a poor fit for high-volume data processing and for business logic complex enough to need tests.

The honest framing is that n8n replaces a category of small scripts nobody wants to own — the ones that live on someone’s laptop, break silently, and are understood by one person.

Table of contents

• The shape it fits
• Replacing the scripts nobody wants
• Where it stops being the right tool
• Self-hosting: what it actually involves
• Practical patterns worth adopting
• Running it without owning the server
• How this fits the rest of the stack
• FAQ

The shape it fits

A workflow is a trigger plus a chain of nodes. Triggers are webhooks, schedules, or polling an API. Nodes call services, transform data, branch on conditions, and loop.

That shape suits work that is mostly moving data between systems with light transformation, where the value is in the connection rather than the computation.

• Form to CRM to notification — a submission creates a record, tags it, and posts to a channel.
• Scheduled sync — pull from one API nightly, reconcile, push to another.
• Alerting with context — a monitoring webhook fires, the workflow enriches it with the customer record and recent activity, then routes it.
• Content pipelines — a new item triggers formatting, image generation, and posting to several destinations.
• Internal tooling — a form that provisions an account, updates a spreadsheet, and emails the requester.
• Data enrichment — a new signup triggers lookups against enrichment APIs and writes the result back.

The common thread: several systems, no single owner, and a process that changes often enough that a compiled service would be annoying to redeploy every time.

Replacing the scripts nobody wants

The real competitor is not another automation platform. It is a cron job on a server somebody set up in 2022.

That script works. It also has no error visibility, no retry, no history of runs, and exactly one person who understands it — and when that person is away and it stops, the failure is discovered by its absence rather than by an alert.

What a workflow tool adds is not capability but legibility: the logic is visible to people who are not the author, each execution is recorded with its input and output, a failed step is inspectable, and retries are configuration rather than code.

That is a genuine operational improvement and it is the main reason to use one. It is also why “I could write this in fifty lines of Python” misses the point — you could, and then you own it.

Where it stops being the right tool

• High-volume data processing. Every item flows through the node graph with per-item overhead. Tens of thousands of records is slow and memory-hungry; that is a job for a script or a database query.
• Complex business logic. Once branching gets deep, a visual graph becomes harder to read than code, not easier. There is no meaningful diff, no unit tests, and code review is comparing screenshots.
• Sub-second latency. There is startup and node overhead per execution. Fine for a webhook that has a second to spare; not fine in a user-facing request path.
• Anything needing real version control. Workflows are JSON. You can commit them, but reviewing a change is not the same experience as reviewing a diff.
• Long-running computation. Executions have time limits and holding one open for a long job is fighting the model.

A reasonable rule: if the workflow has more than about fifteen nodes or three levels of branching, consider whether the logic wants to be a small service that n8n calls. Keeping the orchestration visual and the logic in code is usually better than either extreme.

Self-hosting: what it actually involves

n8n can be self-hosted, and the fair-code licence permits internal business use. The word “free” does some work there, because the software is free and running it is not.

• A server that stays up, since a scheduled workflow that is down does not run and does not tell you.
• A database. SQLite works for a trial; Postgres is the right answer for anything real, because execution history grows quickly and SQLite handles concurrent writes poorly.
• TLS and a domain, because webhook providers will not post to an unencrypted endpoint.
• Backups of the database — the workflows and credentials live there.
• Upgrades, which are frequent, and occasionally require attention.
• Execution data pruning, or the database grows without bound. This one surprises people.

That last item is the most common self-hosting complaint. Every execution stores its input and output data by default; a workflow running every minute produces a lot of rows, and the disk fills before anyone thinks to look.

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
DB_TYPE=postgresdb

Setting SAVE_ON_SUCCESS=none keeps failures for debugging while discarding successful runs, which is usually the right trade and dramatically reduces growth.

Practical patterns worth adopting

• Put an Error Trigger workflow in place first. Without one, a failed workflow is silent. This is the single highest-value thing to set up.
• Make workflows idempotent. Webhooks get delivered twice. Check whether the record exists before creating it.
• Use credentials, never inline keys. Credentials are stored separately and not exported with the workflow JSON.
• Validate webhook payloads early. An unexpected shape should fail at the first node with a clear message, not four nodes later as an undefined property.
• Split large workflows. Sub-workflows are reusable and far easier to reason about than one enormous graph.
• Keep Code nodes small. A hundred lines of JavaScript in a node is a service that has not admitted what it is.

The error-trigger point deserves repeating. A workflow that has been failing quietly for three weeks is worse than no workflow, because everyone believes the thing is happening.

Running it without owning the server

The self-hosting list above is the actual cost of “free”, and for a small team it is usually the deciding factor — not because any single item is hard, but because they arrive together and never finish.

The middle ground is a managed deployment: n8n running with its own plan, a domain, TLS, environment variables, autoscaling, and logs, with a managed Postgres beside it for the execution data. You keep the self-hosted properties that matter — your workflows, your credentials, your data — without the upgrade and backup routine.

That is what n8n as a managed tool on RunxBuild is: n8n on a $6 Basic plan with a managed Postgres beside it, custom domains and environment variables included, logs in the dashboard, and autoscaling if the workflow volume is spiky. The pruning settings above still apply — they are about your data volume rather than who runs the server.

How this fits the rest of the stack

n8n fits API glue, scheduled sync, alerting with enrichment, webhook handling, and internal tooling — the category of small integrations that otherwise become undocumented cron jobs. It fits high-volume data processing, deeply branched business logic, and latency-sensitive paths considerably less well.

If you self-host, use Postgres rather than SQLite, set the execution pruning variables before the disk fills, and build an Error Trigger workflow on day one. If you would rather not run the server, the RunxBuild hosting calculator shows what n8n and a managed Postgres cost as separate line items.

Useful related references:

• JavaScript Capitalize First Letter: The One-Liner and Its Edge Cases
• Key Value Databases: The Data Model, the Tradeoffs, the Use Cases, and the Three Real Options
• A Private Network for Cloud Apps: The Three Meanings, the Three Use Cases, and the One Most Teams Skip
• Services on RunxBuild

FAQ

What is n8n used for?

Connecting APIs and automating processes that span several systems — form submissions into a CRM, scheduled data synchronisation, alerting enriched with customer context, webhook handling, content pipelines, and internal tooling. It suits work where the value is in the connection between services rather than in heavy computation.

When should I not use n8n?

For high-volume data processing, where per-item node overhead makes it slow; for deeply branched business logic, where a visual graph becomes harder to read than code and cannot be unit tested; and for latency-sensitive paths in a user-facing request, where execution overhead matters.

What do I need to self-host n8n?

A server that stays up, Postgres rather than SQLite for anything real, TLS and a domain so webhook providers will post to it, database backups, a plan for frequent upgrades, and execution data pruning. That last one catches people out — without it the database grows until the disk fills.

How do I stop the n8n database growing out of control?

Set EXECUTIONS_DATA_PRUNE=true with an EXECUTIONS_DATA_MAX_AGE in hours, and set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none so only failed executions retain their data. Successful runs are rarely inspected, and they are the bulk of the volume on a frequently-triggered workflow.

Is n8n better than writing a script?

For integrations that several people need to understand and change, usually yes — you get execution history, inspectable failures, and retries as configuration rather than code. For heavy computation or logic that needs tests, a script or small service is better. Many setups do both, with n8n orchestrating and calling services for the hard parts.