Our company is currently using n8n, a self-hosted deployment with version 0.214.2. Our database is RDS (PostgreSQL on AWS). The n8n deployment, worker, and workflow nodes are running inside a Kubernetes environment as Pods. We need to upgrade n8n to the latest stable version. Can anyone please share the steps on how to do the upgrade without disrupting the existing environment?
N8N has come a LONG way since 0.214. Version 1.0 introduced a few breaking changes, so your flows might need to be updated by hand. Certainly checked thoroughly against some test data and predictable output/results before putting them into production. Depending what you’re doing, you might also need more memory/cpu per container.
Most likely you’re going to want to bring up the new system in parallel and then move flows from the old to the new system one at a time as you test them. You’ll ramp up the new system up while you gradually ramp down the old.
Option 1: Clone your N8N database, and bring up the new current version pointing to the clone. That might or might not work, so experiment by just trying that with an EC2 instance before getting wrapped up in the additional complexity of containers.
Option 2: Bring up a clean instance and then copy your flows from the old to the new system. You can use the command line interface for that (CLI commands | n8n Docs) or just copy/paste in a browser.
Also: Since you’re on AWS, you might consider using the ECS / ECR system instead of Kubernetes. Makes the whole environment much simpler and easier to manage. I’ve been running N8N using ECS for about a year. I have an EC2 instance where I rebuild my containers with the latest version of N8N & deploys them to ECS (I keep it stopped except when I’m upgrading). In my world I can just reboot with the new version, but it’s not hard to script a blue/green setup so you minimize downtime. Depending on your workload might also be able to take advantage of autoscaling and of spot fargate containers.
Using ECS also makes it fairly easy to put the whole thing behind a load balancer, which might make the transition from old to new easier. You can use rules on the LB to direct requests from the old workers/webhook instances to the new ones without changing anything for the outside world.
Lastly, for very heavy loads you might want to consider refactoring some of your workflows into Lambda functions, especially if your functionality is basically dialed in. WAY more efficient and scalable.
I use N8N heavily for my own business and I help other companies with these kinds of transitions for a living these days, so please feel free to direct message me if you need some additional help.