You want to run n8n on Kubernetes. But you don’t want it to break every time something goes wrong.

Most of the setups have the same problem: a pod restarts, and your workflows disappear. You try to copy the setup to another server, and it does not work.

Helm solves this. It is basically an app installer for Kubernetes, so instead of writing a lot of configuration files by hand, Helm handles everything for you. You just run one command to install and one to update if anything breaks. 

This guide shows you how you can deploy self-hosted n8n on Kubernetes with Helm securely and keep your data safe when pod restarts. Each step is explained clearly, so there are no assumptions and no skipped steps. 

Are you ready? Let’s start. 

TL;DR

Quick Steps to Deploy n8n on Kubernetes with Helm

  • Buy a Linux VPS (2 CPU, 4GB RAM minimum)
  • Install kubectl, K3s, and Helm
  • Install cert-manager for SSL
  • Add the n8n Helm chart repository
  • Create your values.yaml with domain and encryption key
  • Deploy n8n via Helm and verify the pod is running
  • Point your domain to the VPS and confirm HTTPS is active

What is Kubernetes with Helm?

Kubernetes is a tool that runs your apps in containers and keeps them alive. If your app crashes, Kubernetes restarts it automatically, and if you need more power, it can easily scale up. It’s just like a manager that watches over your machine 24/7. 

Helm is a package manager for Kubernetes, like the App Store, but for its server apps. You don’t need to write lots of complicated config files to deploy something because Helm gives you a ready-made package called a chart. You run one command, and everything is set. 

Together, they work like this:

  • Kubernetes is the platform that runs your app. 
  • Helm is the tool that installs and manages apps on that platform. 

If you don’t have Helm, then deploying something on Kubernetes means writing dozens of configured files by hand. But with Helm, it’s just one command. 

Why use Helm to deploy n8n?

Deploying n8n on Kubernetes without Helm means writing and managing dozens of config files by hand. One mistake and your workflow breaks. Helm packages everything into one clean setup. 

Here’s why that matters specifically for n8n production deployment: 

  • One config file instead of many: You don’t need to run dozens of Kubernetes YAML files; everything lives in one config file. YAML file. Change one thing by deploying one command. It’s that simple. 
  • Your secrets stay safe: Helm keeps encryption keys, API credentials, and passwords out of your code. They are managed properly, so they never accidentally get committed to Git or exposed. 
  • Your workflows survive pod restarts: Helm sets up storage correctly from the start. When a pod crashes and Kubernetes restarts it, your workflows and data are still there. 
  • Scaling is just a config change: You can start with one instance and later add workers and Redis for heavy workloads. You just need to edit values. YAML and run one command. 
  • Easy Upgrades: n8n releases updates frequently, so Helm lets you upgrade with one command and undo it with another if something breaks. It requires no manual cleanup. 

That is why Helm is the right way to deploy n8n on Kubernetes. You have less manual work, and fewer things can go wrong. 

Why Should You Run n8n on Kubernetes?

If you are running n8n for real work, it needs to stay up. One crashed process and one bad deployment, and your automations stop running. 

You can miss triggers, and you will be spending more time fixing instead of building Kubernetes, which takes that problem away. 

  • N8n stays up automatically: N8n needs to run all the time; Kubernetes restarts it automatically if it ever crashes with no manual intervention. 
  • Reduced point of failure: Running n8n on a single server is risky because if that server goes down, everything will go down, but Kubernetes spreads the load, so there is reduced point of failure. 
  • Heavy workflows do not block everything else: Some workflows are heavy, so Kubernetes lets you run separate workers so that workflows don’t block the rest. 
  • Traffic spikes are handled automatically: Webhooks can be hit with sudden traffic, so Kubernetes handles the spike and scales back down when it’s normal. 
  • 10 workflows to 1000 takes no downtime: As your automation grows, Kubernetes scales with you, but you do not require rebuilding anything or moving any servers. 

Bottom Line: Kubernetes gives n8n the foundation it needs to run reliably at any size. It stays up and scales when needed and recovers on its own. This is the kind of setup you can actually depend on. 

Why do you need a VPS for this?

Before you can run n8n on Kubernetes, you need somewhere to host it. Your laptop won’t work because it’s not always on and is not publicly accessible at all times. 

This is where a VPS comes in for obvious and good reasons, like: 

  • N8n needs to be always on: A VPS is always on, and your n8n workflows can keep running even when your computer is off. 
  • Webhooks require a public IP address: Webhooks need a public IP to receive triggers from outside services, so a VPS gives you that. 
  • Dedicated Resources: Kubernetes needs dedicated resources to run properly, like 2 CPU cores and4 GB RAM, so a VPS gives you full control over its memory and CPU.
  • Internet connectivity: Running n8n locally means your automation will stop the moment your internet drops, but a VPS sits in a data center with a stable connection. 
  • Real domain and SSL certificate: You need a real domain and SSL certificate for n8n to work securely, so a VPS makes it simple to set up. 

A VPS is the simplest and most affordable way to give your n8n Kubernetes workflow cluster a permanent home. It keeps your n8n reachable and running with security. 

Step-by-Step Deployment of n8n

Now let us see simplified and easy steps that you can use to deploy your n8n on Kubernetes; just pay focus on every single step so your workflow doesn’t break in the end. 

  • Step 1: Buy Linux VPS. You need a server that is always on and publicly accessible: 
  • Step 1b: Connect via SSH using PuTTY>> plug in your server’s IP and port 22 >> Click Open.” 
buy linux rdp server from qloudrdp and install SSH using PuTTY

If you need any recommendations for hosting providers ,Based on my research and popularity along with overall features comparison I can recommend QloudRDP, DigitalOcean, and Hetzner as top 3 providers among others out there. 

Note: If you are running heavy workflows or planning to scale later, go with 4 CPU cores and 8 GB RAM from the start. 

  • Step 2: Update your server>> Always update before installing anything >> Now, when the server is ready, >> move to Tool Setup. >> You’ll land on this welcome screen after connecting. >> It confirms you’re logged in and shows pending updates (346, including 43 security updates).
command window with script to install kubernetes, helm and n8n

Note: If the update asks about restarting services, press Enter to accept the defaults. Once the update is done, restart your server with reboot and reconnect via SSH. 

  • Step 3: Install Kubectl (a command-line tool that lets you control your Kubernetes cluster) >> Confirm it is installed. 
  • Step 4: Install K3S (Lightweight Kubernetes) >> Install Kubernetes on your server and install SSL support >> Check that your cluster is running. 
command window showing install your kubernetes

Note: Install these two tools you will need – Kubectl to talk to Kubernetes and Helm to deploy apps. 

  • Step 5: Install Helm (a tool that installs n8n on your cluster; one command installs everything) >> Use Helm version 3 or later. >> When tools are ready >> Move to Kubernetes Configurations. 

Add the Helm Chart Repository. 
Before you install n8n, Helm needs to know where to find the chart. Add the repository first: 
Option 1: Community Charts (Simple and good for starting). 
Option 2: 8gears Charts (recommended for production) 
command window showing helm is installed

Note: If it shows NotReady, wait for 30 seconds and run the command again.

  • Step 6: Install cert-manager (cert-manager automatically handles SSL certificates for your domain). Do confirm it is running; without this, HTTPS will not work, and n8n will not run securely. >> Kubernetes is configured >> Move to deployment. 
  • Step 7: Create your values. yaml (Important step) >> It will tell Helm exactly how to set up n8n >> Your domain >> storage with secrets >> Create file >> Fill in your domain and encryption key. 
Three things to get right: 
Replace every yourdomain.com with your actual domain. 
Set a long random encryption key. 
Never change the encryption key after n8n is running.
  • Step 8: Deploy n8n >> Create a dedicated namespace (recommended). >> Install n8n >> Check that the pod is starting >> The status will show ContainerCreating first >> Running after a minute or two >> n8n is deployed. 
command window showing n8n is deployed
  • Step 9: Go Live >> Connect your domain and turn on HTTPS >> Point your domain to your VPS. 
  • Step 10: Confirm your SSL certificate is active >> Open your domain in a browser >> You should see the n8n login screen with a padlock in the address bar >> n8n is live. 
  • Step 11: Verify and Test >> Check everything is running >> Test >> Open n8n in your browser >> Log in and create your admin account >> Create a simple workflow >> Trigger it manually and confirm it executes.

If your workflow is still there, it means your setup is working correctly, and your data is safe, but if it is not, then your persistent volume (storage) is not mounted properly, and you need to check your PVC status. Fix the storage configurations and don’t skip this step. 

Common Errors and Fixes

Let us look at some of the common deployment errors and how you can fix them: 

ErrorCauseFix
Pod keeps restarting. Not enough memory Increase memory limits in values .yaml.
Webhooks are not receiving triggers. The wrong webhook URL is configured. Make sure webhook_url matches your actual domain. 
Can’t access n8n in the browser.Ingress is not set up correctly. Check the ingress class and DNS records pointing to your VPS. 
Credentials stop working. The encryption key was changed. Never change encryption_key after the first setup. 

After all the setup work, the last thing you would want is to find a problem after you have gone live. 

These errors are most common and easy to miss, but most of them come down to 3 things: wrong URLs, missing storage, or a change in the encryption key. 

Spot them early, and your n8n setup will be running without any issues. 

Checklist You Should Consider Before Going Live

After we have given you some common errors and their fixes, we come down to informing you about the checklist you should have before you consider going live: 

  • Storage is working: Restart the pod on purpose and check if your workflows are still there. If they disappear, your data is not being saved properly. 
  • The webhook URL is correct: Open a workflow with a webhook trigger and send a test request. If nothing comes through, your URL in the config does not match your actual domain. 
  • The encryption key is saved safely: Once your n8n is running, this key cannot be changed, so if you lose it or change it, all your saved credentials will stop working. 
  • HTTPS is active: Open your n8n URL in a browser and check for a padlock. No SSL means your login and credentials are not secure. 

Once you pass all these four major checks, you are ready to go live. Everything after this, like adding triggers, connecting apps, and adding workflows, will be built on this foundation. 

Get it right once, and you will not have to touch it again. 

Conclusion

Deploying n8n on Kubernetes with Helm takes a bit of setup upfront, but it is completely worth it, and following this n8n Kubernetes tutorial will give you an automation tool that stays up and recovers on its own. 

You get an automation tool that stays up and recovers on its own. It will also grow with you as your workflows get more complex. The key things to get right are the storage, secrets, and URLs. Everything else follows from those. 

Use Helm to keep your config file in one place, use Kubernetes to keep n8n running, and use a VPS to give it a stable home. 

Once it is live and the checklist is done, you have a setup you can trust. Add your workflows, connect your tools, and let n8n do the work. 

Updates are very simple, and scaling happens without downtime. 

Further Readings

FAQs

Which Linux OS is best for running n8n? 

Ubuntu 22.04 LTS is the best choice. It is stable and widely supported, giving long-term updates, and all the tools you need come with it pre-packaged. Dedian works too, but Ubuntu is simpler for beginners. 

What is the minimum VPS size needed for n8n on Kubernetes?

The minimum is 2 CPU cores and 4 GB RAM. If you have a heavy workflow or production tasks, then go with 4 CPU cores and 8 GB RAM. Do not go lower than 2 cores because Kubernetes itself needs resources and will struggle on smaller setups. 

Can I run multiple n8n instances on Kubernetes? 

Yes, you can run multiple n8n instances in different namespaces, each with its own database and configurations. You can even run one instance with multiple worker pods for parallel execution. 

Categorized in:

Guide,

Last Update: June 19, 2026