# Running n8n in Production: Lessons from a Real Deployment on Kubernetes
## The Challenge of Scaling n8n Beyond a Demo
n8n is an open-source workflow automation tool that’s surprisingly simple to spin up for testing. A single container with a built-in database can handle a quick demo with ease. But when real users and real business processes depend on it, the complexity increases dramatically. Production deployments need multiple components working together — including background workers, webhook handling, a proper database, a message queue, file storage, secret management, traffic routing, and a thoughtful upgrade strategy that protects workflow history.
Engineering teams increasingly turn to n8n to connect internal tools, process incoming webhooks, and automate mission-critical data workflows. More recently, it’s also been adopted for AI-related workloads such as self-hosted agents and retrieval-augmented generation (RAG) pipelines — use cases that add even more strain on background processing, secret handling, and state management.
One team ran n8n on Amazon Elastic Kubernetes Service (EKS) under genuine production traffic. Eventually, they made the decision to transition from a community-maintained Helm chart to n8n’s official Helm chart — without changing the underlying platform, database, queue system, object storage, IAM configuration, or stored secrets.
—
## Starting with the Community Chart
The community chart provided a solid foundation for reaching production. It supported queue-based execution, custom ingress settings, and StatefulSet-based main pods — all of which aligned with the team’s architectural needs at the time.
The team ran it successfully for roughly a year. Over time, though, relying on unsupported features and maintaining local patches became increasingly difficult to justify. After evaluating the options, the team chose to move to the official chart, which offered a clearer path for ongoing maintenance, active community support, and future version upgrades.
—
## How the Architecture Was Structured
The production setup ran n8n in queue mode on Amazon EKS. In this mode, the main instance is responsible for managing workflow definitions and handling triggers, while dedicated worker instances pull jobs from a Redis queue and execute them. Separate webhook processor instances handled all incoming production webhook traffic, keeping that workload isolated from general execution.
Traffic was split by type using ingress rules. Public-facing webhooks were routed through an internet-facing load balancer, while internal webhooks used a private hostname. This separation matched the team’s actual traffic patterns and helped maintain clean boundaries between different types of requests.
Behind the scenes, each component had a clear role:
– **Workers** handled the actual execution of workflows.
– **PostgreSQL** stored all workflow definitions and execution records.
– **Redis** managed the job queue.
– **Amazon S3** held binary files and attachments.
Because running multiple main pod replicas requires an Enterprise license, the team needed a reliable way to share configuration and encryption keys across all pods. They stored those secrets in AWS Secrets Manager and used an external secrets synchronization tool to bring them into Kubernetes as native Secrets. This kept application credentials, API keys, and environment variables consistent and secure across the entire deployment.
—
## What Changed During the Migration to the Official Chart
The community chart had been running the main pod as a StatefulSet, with each replica getting its own persistent volume. This approach avoided complications with AWS gp3 volumes, which support only single-attach in ReadWriteOnce mode. Workers and webhook processors had already been running as standard Deployments.
The official chart took a different approach: the main pod ran as a Deployment, and persistence relied on a single shared persistent volume claim (PVC). Because that shared volume couldn’t be attached to multiple main pod replicas running on different nodes, a standard in-place Helm upgrade wasn’t a viable option. The team treated the migration as a full cutover instead.
The key design consideration was whether anything on the main pod’s local disk actually needed to survive the transition. The team reviewed every piece of stored data and concluded:
– **PostgreSQL** already held all workflow and execution data.
– **Redis** already held all queued jobs.
– **S3** already held all files and attachments.
– **AWS Secrets Manager** already held the encryption key and all application secrets.
Since nothing critical was tied to the main pod’s local disk, the team made the decision to disable local persistence entirely for the new deployment. A fresh main pod could start up and reconnect to all the shared services without needing its own dedicated volume.
—
## Migrating Traffic Safely
The team followed a disciplined approach to ensure nothing was lost during the transition. The database, object storage, IAM role, and all secrets remained untouched throughout the cutover. Everything else was recreated from scratch using the new chart’s configuration values.
Before touching live traffic, several precautionary steps were taken:
– Rollback procedures were tested thoroughly in a non-production environment.
– A full snapshot of the database was captured.
– All secrets were backed up to a secondary location.
– The n8n container image version was kept identical. A version change could trigger a database schema migration, which the team wanted to keep completely separate from the migration process.
With the non-production environment validated — pods healthy, known workflows completing successfully, and all required endpoints reachable — rollback was also confirmed to work in that setting. Only then did the team proceed with the production cutover.
The Helm release itself changed, but the core services — PostgreSQL, Redis, S3, IAM, and secrets — all stayed the same.
For teams looking for reference configurations that include external PostgreSQL and Redis connections, queue mode with horizontal pod autoscaling, resource limits, ingress and webhook setup, and optional task runners, sample value files are publicly available in a community repository.
—
## Frequently Asked Questions
**What is n8n used for?**
n8n is a workflow automation platform that lets teams connect different applications and services, process incoming webhooks, and automate repetitive data tasks. It’s also used in AI workflows involving agents and RAG pipelines.
**Why run n8n in queue mode?**
Queue mode separates the main instance from the workers. The main instance handles workflow management and triggers, while worker instances process execution jobs from a shared queue. This makes it easier to scale execution capacity independently.
**What’s the difference between the community Helm chart and the official one?**
The community chart is maintained by volunteers and may include features that aren’t officially supported. The official chart is maintained by the n8n team, receives regular updates, and offers a clearer upgrade path. However, it may use a different workload model that can require adjustments to your existing setup.
**Why did the team disable persistence for the main pod?**
All critical application data — workflow definitions, execution records, queued jobs, files, and secrets — was already stored in external services (PostgreSQL, Redis, S3, and AWS Secrets Manager). The local disk of the main pod wasn’t holding anything that needed to persist, so the team removed it to simplify the migration.
**What precautions should be taken before migrating a production n8n deployment?**
Always test rollback in a non-production environment, capture a database snapshot, back up all secrets separately, and avoid changing the container image version during the migration to prevent unexpected database schema changes.
**Is running multiple main pod replicas a licensing concern?**
Yes. Using multi-replica main pods is classified as an Enterprise feature of n8n, so organizations need an appropriate license for that configuration.
—
## Conclusion
Running n8n in production on Kubernetes requires careful planning around architecture, persistence, secrets management, and migration strategy. The journey from a community-maintained Helm chart to the official one is entirely achievable — as long as you understand the differences in workload models, know exactly what state lives where, and follow a methodical cutover process. By keeping external services stable and testing every step before touching live traffic, teams can make the transition smoothly and with confidence.
Thank you for reading
