n8n's self-hosting story is its main advantage and its main risk: the quick-start container is easy, and it is also what falls over when a hundred webhooks arrive in a minute or the disk fills. A production setup is not complicated, but it has parts that the quick start skips, and each one is learned the hard way if it is skipped.

Database and queue mode

Run n8n against Postgres, not the default SQLite, from day one. Enable queue mode with a Redis instance and separate worker processes so webhooks are received by one process and executed by others; this is what keeps the instance responsive under load and lets you add workers when volume grows.

Credentials and secrets

Set the encryption key explicitly and back it up separately from the database — without it, every stored credential is unreadable after a restore. Use the environment or a secrets manager for infrastructure credentials, and n8n's credential store for app credentials, with access limited to the workflows that need them.

Backups and version control

Nightly database backups, tested by restoring them. Workflows exported as JSON to a git repository on every change, so a broken edit can be rolled back and a change can be reviewed. Separate staging and production instances, with workflows promoted rather than edited live.

Monitoring

Execution failures alerted to a channel with the workflow name and the error. Webhook endpoints monitored from outside for availability. Disk, memory and queue depth watched. Execution data pruned on a schedule so the database does not grow without limit. With these in place, an n8n instance runs a GTM team's automations for years without drama.