Keeping n8n running after the build is finished

Where it runs, and what each choice costs

n8n can be self-hosted, and the platforms it is usually compared against cannot. Make and Zapier run on somebody else's infrastructure by design. n8n can run on yours, and that single fact settles most of the architecture conversation for a business holding data it cannot send anywhere.

Self-hosting is a commitment rather than a saving. The smallest sensible version is a container on a small server with a managed Postgres database behind it. The embedded database that ships by default is fine while somebody is learning the tool and becomes a liability the moment execution history and concurrent runs start to matter.

Queue mode is the next step up: a main process handling triggers and the interface, a broker in the middle and separate workers running the executions. It is worth the extra moving parts once long workflows block each other, once webhook responses slow under load, or once one restart takes the whole instance down.

Whatever shape it takes, the database is the system. Workflows, credentials, settings and execution history all live in it, so a backup that excludes the database is not a backup, and a restore nobody has performed is a plan rather than a capability.

• One container on one server with Postgres, for a small and predictable load
• Queue mode with a broker and separate workers, once executions block each other
• A public endpoint with TLS for webhooks, which is a firewall decision rather than an n8n one
• Database backups on a schedule, with at least one restore actually carried out
• The image pinned to a specific version rather than following the latest tag

Credentials, and the blast radius of one of them

Credentials in n8n are stored encrypted, using a key held in the instance's environment. Two things follow, and both tend to be discovered the hard way. The key belongs in the backup and in a password manager, because a database restored without it holds credentials nobody can decrypt. And anybody with access to the instance can use every credential in it, whether or not they can read the secret.

The second point is what makes least privilege worth the effort. A workflow that reads a calendar does not need an account that can delete a mailbox. A service account per integration, scoped to what that integration genuinely does, turns a compromised credential from a company problem into a workflow problem.

The most common failure has nothing to do with security. An integration gets connected through an employee's personal account because it was quicker on the day, and it stops working the week they leave. Every credential should carry a named owner and a note of what it was created for, and that owner should be a role rather than a person.

• The encryption key stored separately from the database and named in the recovery plan
• A service account per integration, scoped to that integration's actual needs
• No personal accounts sitting behind anything the business depends on
• An inventory of every credential, its owner, its scope and what breaks when it rotates
• Rotation scheduled deliberately rather than triggered by an incident

Errors, retries and the workflow that fails quietly

n8n gives every node a retry setting and every workflow somewhere to send its errors, and a surprising number of production instances use neither. What that produces is a workflow which stops halfway through on a temporary network fault and tells nobody.

Retries belong on the failures worth retrying. A rate limit, a gateway error or a timeout will often succeed on a second attempt a few seconds later. A rejected request, an expired credential or a missing record will fail identically every time, and retrying it three times only delays the alert. Sorting each node's likely failures into those two groups takes a few minutes per workflow and changes how the whole instance behaves.

Continuing on failure deserves particular suspicion. Switched on without thought, it produces a workflow that reports success while writing nothing, which takes months to notice. Where it is genuinely wanted, the branch catching the failure has to do something visible with it.

Every production workflow should point at an error handler, and that handler should do more than write a line to a log. It should name the workflow, the execution and the item that failed, put the item somewhere a person can find it, and tell somebody in a channel they read.

• Retry on failure set only where the failure is plausibly temporary, with a wait between attempts
• Continue on failure used deliberately, with the failure branch doing something visible
• An error handler attached to every production workflow, not only the important ones
• Failed items queued for a person, with enough context to act on without opening the instance
• Writes designed so that rerunning a workflow cannot create a second record

Upgrades, drift and knowing before the client does

n8n releases often, and nodes carry a version of their own, so an existing workflow generally keeps the behaviour it was built with while newly added nodes get the current one. Upgrading is therefore usually undramatic and occasionally not, and the difference is only visible if somebody looks.

The practice that makes upgrades boring is a second instance kept on the same version as production, the upgrade applied there first, a small set of workflows run against known inputs, and a database snapshot taken before production is touched so that rolling back is a restore rather than an improvisation.

The changes that break more workflows are the ones nobody made. A supplier adds a field, renames another, starts returning a number where it used to return text, or changes an error code. The workflow keeps running and starts producing subtly wrong records. A validation step on incoming data, checking that the fields you depend on are present and the right shape, turns that into a clean failure with a name on it.

Execution history is the other thing that changes without anyone touching it. It grows, and on a busy instance it will fill the disk. Check what the pruning settings are on the version you are running rather than assuming them, then set a retention period deliberately: enough history to investigate last week's complaint, not so much that storage becomes the outage.

• A staging instance held on the same version as production
• A snapshot before every upgrade, so a rollback is a restore
• Incoming data validated for shape, so a supplier's change fails loudly
• Execution history pruned on a schedule, with a retention period somebody chose
• Alerts on workflows that stopped being triggered at all, since those produce no errors

What a handover pack actually contains

Ownership is a claim until somebody tests it. Give the pack to a competent person who has never seen the system and ask them to restore it and keep it running. Most handover documents fail inside the first hour, usually because the environment was never written down.

A pack that passes contains a map, a description per workflow, an inventory, a runbook and a restore procedure that has been performed rather than described.

The purpose here is commercial rather than administrative. A business that cannot restore its own automation has bought a dependency, and dependencies get repriced at renewal. A business that can restore it keeps a partner because the work is good.

• A diagram of what triggers what, including the schedules and the webhooks
• One page per workflow: purpose, trigger, inputs, outputs and what it does when it fails
• The credential inventory, with owners and scopes and no secrets written in it
• The environment recorded: version, hosting, database, broker and backup location
• A runbook for the five failures most likely to happen, with the fix for each
• A restore procedure somebody has run end to end, with the date they ran it
• Access handed over properly, including the encryption key and the account owning the server

When operating it yourself is the wrong call

If a business runs four simple workflows and has nobody technical in the building, self-hosting is a liability. The honest recommendation there is managed hosting, or a simpler platform entirely. Running your own instance pays back where volume is real, where data cannot leave, or where the workflows are involved enough that platform limits start to bite.

If the workflows change every week, operational discipline is the wrong investment until they stop changing. Version control and staging instances protect something stable. Applied to a process that is still being argued about, they add ceremony to the argument.

And if the current instance runs fine and nobody has been woken up in months, an operations retainer may be solving a problem that does not exist. The check is the failure list. If it is short and somebody is reading it every week, the system is already being operated, whoever happens to be doing it.

Common questions

Should we self-host n8n or use the hosted version?

Self-host when data cannot leave your own infrastructure, when volume makes per-execution pricing uncomfortable, or when you need control over versions and networking. Use the hosted version when nobody in the business wants to be responsible for a server, which is a legitimate answer rather than a compromise. The overhead of self-hosting is real and worth paying only when one of those applies.

What does it take to keep n8n running in production?

Database backups somebody has actually restored from, the encryption key stored where a restore can reach it, an error handler on every production workflow, alerts that fire when a scheduled workflow stops running, a pruning policy for execution history, and a staging instance to test upgrades on. None of it is difficult and all of it gets skipped.

What happens when an n8n workflow fails?

By default the execution stops, the failure is recorded in the execution list, and nobody is told. A production setup adds retries on failures that are plausibly temporary, an error handler that names what failed and puts the item where a person will see it, and writes that survive being rerun.

How should credentials be handled in n8n?

One scoped service account per integration rather than a personal login, an inventory recording the owner and scope of each credential, and the instance's encryption key stored separately and named in the recovery plan. A database restored without that key holds credentials nobody can decrypt, which is best discovered during a drill.

Is upgrading n8n risky?

Usually not, because existing nodes generally keep the behaviour they were built with, though occasionally a change matters and there is no way to know without checking. Upgrade a staging instance first, run a small set of workflows against known inputs, snapshot the database before touching production, and pin the version.

What should we receive at handover?

A diagram of what triggers what, a page per workflow covering purpose and trigger and failure behaviour, the credential inventory with owners and scopes, the environment written down, a runbook for the likely failures, and a restore procedure that has been performed rather than described. The test is whether a stranger could restore it.