n8n Automation

We talk clients out of self-hosted n8n regularly, and it seems worth leading with that. If you are running a handful of simple automations at low volume, Zapier or Make will cost you less in total than n8n once you account for the server, the deployment, and someone keeping it patched. Self-hosting starts winning when one of three things is true: your task volume is high enough that per-task pricing has become a real cost, your data cannot pass through a third party, or your logic is complex enough that per-task tools make it awkward. If none of those apply, we will say so, and you should keep the tool you have.

When self-hosting is right, the deployment matters more than most teams expect. A default n8n container running on a single small instance with SQLite behind it will work fine in testing and fall over under real load, and the failure is usually silent. Production deployments need Postgres rather than SQLite, queue mode with separate workers once concurrency rises, proper credential encryption, environment separation between staging and production, and a backup strategy for the workflow definitions themselves. Most of the broken n8n installations we inherit are broken because they were deployed as a quick experiment and then quietly became load-bearing.

The single most common gap in self-hosted n8n is that nobody finds out when it fails. The platform will happily record a failed execution and take no further action, so a workflow that has been erroring for four days looks identical to one that has had no work to do. Every deployment we build has a dedicated error workflow catching failures, alerting a named owner through Slack or email with the execution link attached, and distinguishing transient failures worth retrying from genuine ones needing attention. This is unglamorous plumbing and it is the difference between an automation you can rely on and one you have to check.

We build workflows to be read, because the whole argument for n8n over custom code is that non-developers can maintain them — and that benefit evaporates if the workflow is a sprawl of forty unnamed nodes. Ours use descriptive node names, sub-workflows for logic used in more than one place, sticky notes explaining anything non-obvious, and business rules held in variables rather than buried inside expressions. The test we apply is whether an operations person can open the workflow, follow what it does, and change a threshold without asking us. If they cannot, we have built something that only looks maintainable.

Migrations from Zapier or Make are rebuilds, not imports, and that is an opportunity rather than purely a cost. In practice a meaningful share of accumulated scenarios in any long-running account are dead — connected to tools nobody uses, duplicated during an experiment, or superseded and never turned off. We audit before rebuilding and typically find a portion that should simply be deleted. What remains gets rebuilt with proper error handling, which the original usually did not have, and we run both systems in parallel and compare outputs before switching anything off.

Version control and change safety are where self-hosted setups tend to be weakest. n8n workflows are JSON, which means they can and should live in a Git repository with a review step, rather than being edited directly in production by whoever last had an idea. We set up export and versioning so changes are tracked and reversible, and configure a staging instance so a modification is tested against real-shaped data before it touches live operations. The alternative — editing production directly — works right up until the day it does not.