n8n Publishes Production Kubernetes Scaling Guide for Workflow Automation.

n8n has released a new guide for running its workflow automation platform on Kubernetes, covering the path from a single-pod deployment to a production-ready, horizontally scaled architecture. The guide addresses when to introduce queue mode, worker nodes, Redis, PostgreSQL, and the n8n Helm chart as workloads grow.

The guide targets technical teams already operating n8n in containerized environments who need to scale beyond basic single-instance setups. It walks through the architectural decisions required to support higher throughput, reliability, and separation of concerns between workflow execution and API handling.

The guide starts with the simplest Kubernetes deployment: a single n8n pod handling both the web UI and workflow execution. This works for light workloads but becomes a bottleneck as execution volume increases or when long-running workflows block the UI.

The first major scaling step is enabling queue mode. In this architecture, n8n splits into separate main and worker processes. The main process serves the UI and API, while worker pods execute workflows. A Redis instance acts as the job queue, decoupling execution from user-facing services. This separation allows teams to scale workers independently based on workflow demand.

n8n recommends PostgreSQL over SQLite for production deployments at this stage. PostgreSQL supports concurrent writes from multiple workers and provides better performance for larger workflow histories and execution logs.

Once queue mode is active, teams can scale worker pods horizontally using Kubernetes replica sets. The guide covers how to configure resource limits, autoscaling policies, and pod anti-affinity rules to distribute workers across nodes for fault tolerance.

The n8n Helm chart simplifies these deployments by bundling Redis, PostgreSQL, and n8n into a single managed release. The chart includes values for queue mode, worker replicas, ingress configuration, and secret management. Teams can override defaults to match their infrastructure, including external databases or managed Redis services.

The guide highlights several production concerns:

• Persistent storage for workflow definitions, credentials, and execution data
• Redis cluster mode for high-availability job queues
• Database connection pooling to avoid exhausting PostgreSQL connections under load
• Resource requests and limits to prevent worker pods from starving other workloads
• Monitoring and logging integration with Prometheus and Kubernetes-native tools

n8n also covers when to introduce multiple worker types. For example, teams can run separate worker pools for lightweight tasks and resource-intensive AI workflows, tagging each pool to handle specific execution types. This prevents expensive operations from blocking faster jobs.

This guide builds on n8n's focus on giving technical teams control over their automation infrastructure. Unlike managed platforms, n8n's self-hosted model requires teams to handle scaling, but it also allows them to optimize for their exact workload patterns and compliance requirements.

For teams exploring n8n's AI capabilities, such as those previously covered in memory architecture guides, the Kubernetes scaling approach supports parallel agent execution and high-volume retrieval tasks. Worker pools can be tuned for GPU-enabled nodes or allocated specifically for model inference.

The guide is available on n8n's blog and GitHub repository. It includes YAML examples, Helm value snippets, and a decision tree for when to adopt each scaling feature.