How to run n8n in production using queue mode to prevent workflow failures

Self-hosted n8n commonly fails in production when heavy workflow executions overload the single process that also serves the UI and handles webhooks, causing editor freezes and silent workflow stops. A second common culprit is an unbounded executions table in Postgres that grows until it becomes a disk or performance bottleneck. N8n's recommended fix is queue mode, which splits the application into a main instance that manages the UI and webhooks and one or more worker instances that pull and execute jobs from a Redis queue. This separation means a heavy execution cannot block incoming webhooks, and workers can be scaled horizontally since all state is stored in Postgres. Key hardening steps include enabling execution pruning to cap history, scheduling verified database backups, pinning the n8n image version, and keeping Postgres and Redis off the public internet.