How to install n8n on Ku­ber­netes step by step

Ku­ber­netes helps you deploy, manage and scale con­tainer­ized apps like n8n as needed. In this guide, you’ll learn how to install n8n on Ku­ber­netes and set up a stable, reliable en­vi­ron­ment for day-to-day use.

Step 1: Check re­quire­ments and choose the right server

Before you install n8n on Ku­ber­netes, you’ll need a Linux server, ideally with a static public IP address, your own domain or subdomain, and root access. The simplest choice is a single Ubuntu server with light­weight Ku­ber­netes through K3s. This is the setup used in this guide. K3s is good for beginners and includes several core Ku­ber­netes com­po­nents.

Opt for a server that matches what you plan to do. Ku­ber­netes uses system resources of its own and n8n also requires memory and CPU. The examples below show some common usage scenarios and the right setup for each of them.

Learning and testing en­vi­ron­ments (personal use)

A modest server setup is usually enough to get started with. The main goal here is to build your first n8n workflow. It’s also a chance to get familiar with the interface and try out some simple au­toma­tions. Demand on the server is usually low, as only a few workflows run at the same time and there’s no con­tin­u­ous back­ground activity. A VPS with 2 vCores, 2 GB RAM, and 80 GB NVMe is generally enough. Keep in mind that Ku­ber­netes also needs some of those resources, so there is less headroom for n8n. That makes this kind of setup less suitable for pro­duc­tion use or workflows that need to run con­tin­u­ous­ly.

Personal use (with pro­duc­tion workloads) and small startups

If you plan to use n8n regularly, say for your own au­toma­tions between tools or APIs, you’ll need a more powerful setup. Here workflows run regularly or are triggered by webhooks. This kind of setup can also work well for small teams or smaller projects. 4 vCores, 4 GB RAM, and 120 GB NVMe offers a good balance between per­for­mance and cost. It gives you enough headroom for multiple workflows running at the same time. That makes it a solid starting point for pro­duc­tion use.

SMBs with multiple workflows and regular ex­e­cu­tions

For small and medium-sized busi­ness­es, n8n is often used to automate business processes. Typical examples include con­nect­ing CRM systems, email au­toma­tions or pro­cess­ing orders from an online store. In setups like these, workflows run regularly and sometimes in parallel, which puts more demand on the server. 6 vCores, 8 GB RAM, and 240 GB NVMe gives you a stable base for pro­duc­tion use. It delivers faster ex­e­cu­tions and helps avoid bot­tle­necks when several processes run at the same time. You also have enough room to expand the setup later.

Growing teams, agencies or heavily automated en­vi­ron­ments

When n8n is handling multiple workflows at the same time, a more powerful setup is usually needed. In agencies or larger teams, au­toma­tions often run across marketing, data pro­cess­ing, and day-to-day internal tasks at the same time. More complex workflows with multiple API requests or longer runtimes are also common in these en­vi­ron­ments. 8 vCores, 16 GB RAM, and 480 GB NVMe will keep the system stable and re­spon­sive. This option gives you enough headroom for growth and heavier load peaks. It also gives you a solid base to move to a more advanced Ku­ber­netes setup later.

Overview of typical uses and re­quire­ments by scenario

A more powerful setup with 12 vCores, 24 GB RAM, and 720 GB NVMe may be needed for larger en­vi­ron­ments. This is usually the case when many workflows run at the same time or when ad­di­tion­al services are running on the same server.

Step 2: Prepare the server and install base packages

Log in to your Ubuntu server with SSH and update the package lists and installed packages first. This ensures your system is up to date and every­thing is in sync before you begin the Ku­ber­netes setup.

sudo apt update && sudo apt upgrade -y 
sudo apt install -y curl wget nano openssl

Next, check that the server is reachable and has a public IP address:

hostname -I

Your hosting provider can also confirm your public IP address. Write it down. You’ll need it in the next step when you create the DNS record for your subdomain.

Step 3: Point the subdomain to your server

Create an A record for the subdomain you want to use with your domain provider. If you’ll use n8n.your-domain.com for your n8n instance, that exact subdomain must point to your server’s public IP address. External access and HTTPS will only work reliably once the DNS record is active.

A typical DNS entry looks like this:

Type: A 
Name: n8n 
Value: 203.0.113.10 
TTL: 3600

Step 4: Install K3s

For beginners, K3s is usually the easiest way to run Ku­ber­netes on a single server. K3s includes core com­po­nents like Traefik as the ingress con­troller and local storage to keep data available after restarts.

Use this command to install K3s:

curl -sfL https://get.k3s.io | sh -

Then check the service is running:

sudo systemctl status k3s

If every­thing starts as it should, check the cluster status:

sudo k3s kubectl get nodes

Close

To make kubectl easier to use, create an alias:

echo 'alias kubectl="sudo k3s kubectl"' >> ~/.bashrc 
source ~/.bashrc 
kubectl get nodes

If your server shows “Ready” as its status, Ku­ber­netes is up and running.

Step 5: Install Helm

Helm is a package manager for Ku­ber­netes, like apt on Ubuntu. Instead of creating and managing con­fig­u­ra­tion files manually, you install complete ap­pli­ca­tions known as “charts.” This makes setup simpler, easier to follow and less error-prone. The official n8n chart requires Helm 3.12 or later.

If you’re new to Ku­ber­netes, Helm makes things much easier. You don’t need to write or fully un­der­stand every YAML file. Instead, you only need to adjust a few key settings, and Helm handles the rest. It also keeps track of your in­stal­la­tion state, which makes in­stalling updates and adjusting the con­fig­u­ra­tion at a later point much easier.

Start by in­stalling Helm directly on your server. While Helm is often installed using pre­com­piled binaries, many Ubuntu setups use the official installer script because it’s much simpler:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 
chmod 700 get_helm.sh 
./get_helm.sh

The first command downloads the installer script. The next two make it ex­e­cutable and run it. The script then installs the correct version of Helm au­to­mat­i­cal­ly.

Then check that the in­stal­la­tion worked by dis­play­ing the installed version:

helm version

Close

If a version number appears, Helm is installed and ready to use with the n8n chart.

Step 6: Create a namespace for n8n

Now create a dedicated namespace for n8n to keep its resources separate from other Ku­ber­netes objects. This is standard practice in Ku­ber­netes.

kubectl create namespace n8n

Then check the namespace was created:

kubectl get namespaces

Close

Step 7: Install cert-manager for TLS cer­tifi­cates

For a publicly ac­ces­si­ble n8n instance, use HTTPS. n8n rec­om­mends handling TLS through a reverse proxy or another HTTP/HTTPS layer in front of the ap­pli­ca­tion. In this guide, Traefik handles incoming traffic, while cert-manager automates cer­tifi­cate issuance and renewal. cert-manager can also be installed with a Helm chart. Use the following command to do so:

helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \ 
--namespace cert-manager \ 
--create-namespace \ 
--set crds.enabled=true

Then check the pods. Pods are the smallest de­ploy­able unit in Ku­ber­netes. They run one or more con­tain­ers together on the same node and share resources like network and storage.

kubectl get pods -n cert-manager

Close

Wait until all pods show “Running” or “Completed” as their status.

Step 8: Create a Let’s Encrypt Clus­terIs­suer

For cert-manager to issue cer­tifi­cates au­to­mat­i­cal­ly, you need to create a Clus­terIs­suer for Let’s Encrypt. A Clus­terIs­suer defines which cer­tifi­cate provider to use and how your domain is validated. In this case, that’s Let’s Encrypt, a free provider of SSL cer­tifi­cates.

For most setups, HTTP-01 val­i­da­tion is the easiest way. It doesn’t require access to a DNS API. Instead, Let’s Encrypt verifies your domain by re­quest­ing a specific file over HTTP. If the request succeeds, the domain is con­sid­ered verified and the cer­tifi­cate is issued.

Start by creating a file named clusterissuer.yaml:

nano clusterissuer.yaml

In the file, add the following con­fig­u­ra­tion:

apiVersion: cert-manager.io/v1 
kind: ClusterIssuer 
metadata: 
    name: letsencrypt-prod 
spec: 
    acme: 
        email: your-email@example.com 
        server: https://acme-v02.api.letsencrypt.org/directory 
        privateKeySecretRef: 
            name: letsencrypt-prod 
        solvers: 
            - http01: 
                    ingress: 
                        ingressClassName: traefik

Replace the email address with your own. Let’s Encrypt will use it to send important notices, such as cer­tifi­cate expiry reminders.

Then apply the file to your cluster:

kubectl apply -f clusterissuer.yaml

This creates the Clus­terIs­suer and makes it available across the cluster. Then check it was suc­cess­ful:

kubectl get clusterissuer

Close

If Clus­terIs­suer appears, the setup was suc­cess­ful. The cer­tifi­cate itself will be issued au­to­mat­i­cal­ly later, once n8n is reachable under your domain and an ingress is in place.

Step 9: Create the n8n secret

The official Helm chart requires several variables, including N8N_ENCRYPTION_KEY, N8N_HOST, N8N_PORT, and N8N_PROTOCOL. Replace n8n.your-domain.com with your subdomain and then run this command:

kubectl create secret generic n8n-secrets -n n8n \ 
--from-literal=N8N_ENCRYPTION_KEY=$(openssl rand -hex 32) \ 
--from-literal=N8N_HOST=n8n.your-domain.com \ 
--from-literal=N8N_PORT=5678 \ 
--from-literal=N8N_PROTOCOL=https \ 
--from-literal=WEBHOOK_URL=https://n8n.your-domain.com / \ 
--from-literal=N8N_PROXY_HOPS=1

Step 10: Create the values file for n8n

This guide uses stand­alone mode. This means n8n runs in a single pod and does not require ad­di­tion­al services like an external database or Redis. Instead, it uses a built-in SQLite database. This setup is ideal for getting to grips with n8n, smaller projects and simple de­ploy­ments.

Create a con­fig­u­ra­tion file called n8n-values.yaml:

nano n8n-values.yaml

This file defines how n8n is set up, including variables, storage, and the domain.

queueMode: 
  enabled: false 
 
database: 
  type: sqlite 
  useExternal: false 
 
redis: 
  enabled: false 
 
persistence: 
  enabled: true 
  size: 10Gi 
 
secretRefs: 
  existingSecret: n8n-secrets 
 
main: 
  extraEnv: 
    - name: TZ 
      value: America/New_York 
 
ingress: 
  enabled: true 
  className: traefik 
  annotations: 
    cert-manager.io/cluster-issuer: letsencrypt-prod 
  hosts: 
    - host: n8n.your-domain.com 
      paths: 
        - path: / 
          pathType: Prefix 
  tls: 
    - secretName: n8n-tls 
      hosts: 
        - n8n.your-domain.com

Be sure to replace n8n.your-domain.com with your domain. Update the TZ value if needed to match your time zone. This file controls your setup and can be adjusted if you need to change or expand it.

Step 11: Install n8n with the official Helm chart

Now install n8n using the official Helm chart:

helm install n8n oci://ghcr.io/n8n-io/n8n-helm-chart/n8n \ 
--version 1.0.0 \ 
-n n8n \ 
-f n8n-values.yaml

Then check the resources were created:

kubectl get all -n n8n

Next, check the pods as they start up and look for errors:

kubectl get pods -n n8n -w

Once the main pod is ready, the in­stal­la­tion is complete.

Step 12: Check the ingress and cer­tifi­cate

Because you already con­fig­ured ingress for external access and TLS in the values file, cert-manager will now request a cer­tifi­cate for your subdomain. Start by checking the ingress:

kubectl get ingress -n n8n

Then check the cer­tifi­cate:

kubectl get certificate -n n8n 
kubectl describe certificate n8n-tls -n n8n

Step 13: Open n8n in your browser and complete setup

Once the ingress is active and the cer­tifi­cate is ready, open your n8n instance in a browser:

`https://n8n.your-domain.com``

The first time you open it, n8n will guide you through the setup. You’ll create your first user account in this step.

Close

Step 14: Check n8n is working

Once every­thing is set up, quickly check that n8n is working. Open the n8n editor, create a simple test workflow, and save it. Then check the main pod logs.

kubectl logs -n n8n -l app.kubernetes.io/component=main --tail=100

If the editor opens, login works, and no errors appear in the logs, the in­stal­la­tion is complete.

Step 15: What to know before going live

Stand­alone mode works well for basic setups. The official Helm chart and n8n both clearly separate stand­alone and queue mode. Once you have multiple users, more con­cur­rent ex­e­cu­tions, or high webhook traffic, queue mode is the better choice. It adds Post­greSQL and Redis and allows workers, which handle workflow execution, to scale in­de­pen­dent­ly.