Deploying n8n on EKS: Mastering Queue Mode for Production

Deploying n8n on EKS is not just about getting it up and running; it's about ensuring it can handle production traffic efficiently. n8n is easy to try but harder to run under production conditions. To tackle this, you need to implement queue mode, which allows the main instance to manage workflow information and triggers while worker instances execute jobs from a Redis queue. This setup is crucial for maintaining performance and reliability as your workload scales.

In our implementation, we ran n8n in queue mode on EKS. The architecture involved dedicated webhook processors to handle production webhook traffic separately. We split ingress by traffic type, with public webhooks behind an internet-facing load balancer and internal webhooks using a private hostname. PostgreSQL was used to store workflow and execution data, while Redis managed queued jobs, and S3 was utilized for storing binary files. Additionally, we stored secrets in AWS Secrets Manager and synchronized them into Kubernetes using the External Secrets Operator (ESO), ensuring that sensitive information was managed securely and efficiently.

In production, be aware that the community chart supports queue mode and StatefulSet-based main pods, which are more suitable for high-traffic scenarios than the official chart that relies on a single shared PVC. This distinction is critical for performance tuning and reliability. The version of this setup is posted as of October 16, 2026, so keep an eye on updates and community feedback for further improvements.