Ku­ber­netes wird genutzt, um An­wen­dun­gen wie n8n in Con­tai­nern be­reit­zu­stel­len, zu verwalten und bei Bedarf zu skalieren. In dieser Anleitung erfahren Sie, wie Sie n8n mit Ku­ber­netes in­stal­lie­ren und so eine saubere, nach­voll­zieh­ba­re Basis für den späteren Betrieb schaffen.

Schritt 1: Vor­aus­set­zun­gen prüfen und den passenden Server wählen

Bevor Sie n8n mit Ku­ber­netes in­stal­lie­ren, benötigen Sie zunächst einen Linux-Server, idea­ler­wei­se mit einer festen öf­fent­li­chen IP-Adresse, einer eigenen Domain oder Subdomain und Root-Zugriff. Für diese Anleitung ist ein einzelner Server mit Ubuntu als Grundlage am ein­fachs­ten, auf dem an­schlie­ßend ein leicht­ge­wich­ti­ges Ku­ber­netes wie K3s ein­ge­rich­tet wird. K3s eignet sich gut für den Einstieg und bringt bereits mehrere typische Ku­ber­netes-Bausteine mit.

Wichtig ist außerdem, die Ser­ver­grö­ße rea­lis­tisch zu wählen. Hierbei sollten Sie darauf achten, dass Ku­ber­netes selbst zu­sätz­li­che Sys­tem­kom­po­nen­ten mitbringt und n8n ebenfalls Speicher sowie CPU benötigt. Im Folgenden haben wir einige typische Ein­satz­ge­bie­te und die passenden Server zu­sam­men­ge­stellt.

Tipp

Wenn Sie n8n noch nicht kennen oder Al­ter­na­ti­ven ver­glei­chen möchten, lohnt sich ein Vergleich von n8n vs. Zapier oder n8n vs. Make. Während Zapier und Make stärker auf einfache Cloud-Au­to­ma­ti­sie­run­gen ausgelegt sind, bietet n8n durch Self-Hosting deutlich mehr Kontrolle und Fle­xi­bi­li­tät.

Lern- und Test­um­ge­bung für den privaten Gebrauch

Wenn Sie n8n und Ku­ber­netes zunächst ken­nen­ler­nen möchten, reicht eine kleine Ser­ver­kon­fi­gu­ra­ti­on völlig aus. In diesem Szenario geht es vor allem darum, erste n8n-Workflows zu erstellen, die Ober­flä­che zu verstehen und grund­le­gen­de Au­to­ma­ti­sie­run­gen aus­zu­pro­bie­ren. Die Aus­las­tung ist dabei in der Regel gering, da nur wenige Workflows gleich­zei­tig laufen und keine dau­er­haf­te Nutzung im Hin­ter­grund statt­fin­det. Eine Aus­stat­tung Ihres VPS mit 2 vCores, 2 GB RAM und 80 GB NVMe genügt hier meist. Beachten Sie jedoch, dass Ku­ber­netes selbst bereits Res­sour­cen benötigt, sodass die Leistung begrenzt ist. Für pro­duk­ti­ve oder dauerhaft laufende Workflows ist diese Variante daher nur ein­ge­schränkt geeignet.

Pri­vat­an­wen­de­rin­nen und -anwneder mit pro­duk­ti­ver Nutzung oder kleine Startups

Wenn Sie n8n aktiv im Alltag einsetzen möchten, bei­spiels­wei­se für Au­to­ma­ti­sie­run­gen zwischen Tools, APIs oder eigenen Projekten, sollten Sie etwas mehr Leistung einplanen. In diesem An­wen­dungs­fall laufen Workflows re­gel­mä­ßig oder werden durch Webhooks ausgelöst. Auch erste Team-Nutzungen oder kleinere Projekte sind hier denkbar. Eine Kon­fi­gu­ra­ti­on mit 4 vCores, 4 GB RAM und 120 GB NVMe bietet eine gute Balance aus Leistung und Kosten. Sie haben damit aus­rei­chend Reserven für mehrere gleich­zei­ti­ge Workflow-Aus­füh­run­gen. Diese Variante eignet sich somit gut als Einstieg in eine pro­duk­ti­ve Nutzung.

KMU mit mehreren Workflows und re­gel­mä­ßi­gen Aus­füh­run­gen

Für kleine und mittlere Un­ter­neh­men wird n8n häufig zur Au­to­ma­ti­sie­rung von Ge­schäfts­pro­zes­sen ein­ge­setzt. Typische Beispiele sind die In­te­gra­ti­on von CRM-Systemen, E-Mail-Au­to­ma­ti­sie­run­gen oder die Ver­ar­bei­tung von Be­stel­lun­gen aus einem On­line­shop. In solchen Szenarien laufen Workflows re­gel­mä­ßig und teilweise parallel, wodurch die Sys­tem­last deutlich steigt. Eine Aus­stat­tung mit 6 vCores, 8 GB RAM und 240 GB NVMe bietet hier eine stabile Grundlage für den pro­duk­ti­ven Betrieb. Sie pro­fi­tie­ren von schnel­le­ren Aus­füh­run­gen und vermeiden Engpässe bei mehreren gleich­zei­ti­gen Prozessen. Zudem haben Sie genug Spielraum, um die In­stal­la­ti­on später zu erweitern.

Wachsende Teams, Agenturen oder stark au­to­ma­ti­sier­te Um­ge­bun­gen

Wenn n8n intensiv genutzt wird und viele Workflows gleich­zei­tig laufen, steigen die An­for­de­run­gen deutlich. In Agenturen oder größeren Teams werden oft zahl­rei­che Au­to­ma­ti­sie­run­gen parallel aus­ge­führt, da Marketing, Da­ten­ver­ar­bei­tung und interne Prozesse ab­ge­bil­det werden. Auch kom­ple­xe­re Workflows mit mehreren API-Aufrufen oder längeren Lauf­zei­ten sind hier üblich. Eine leis­tungs­stär­ke­re Kon­fi­gu­ra­ti­on mit 8 vCores, 16 GB RAM und 480 GB NVMe sorgt dafür, dass das System stabil und per­for­mant bleibt. Diese Variante bietet genügend Reserven für Wachstum und höhere Last­spit­zen. Gleich­zei­tig schafft sie eine gute Basis, um später auf ska­lier­ba­re­re Ku­ber­netes-Setups zu erweitern.

Über­sichts­ta­bel­le: Server und Ein­satz­sze­na­ri­en

An­wen­dungs­ge­biet Typischer Einsatz Emp­foh­le­ne Aus­stat­tung
Lern- und Test­um­ge­bun­gen Erste Schritte mit Ku­ber­netes, einzelne n8n-Workflows, kein Dau­er­be­trieb mit hoher Last 2 vCores CPU, 2 GB RAM, 80 GB NVMe
Pri­vat­an­wen­den­de mit pro­duk­ti­ver Nutzung oder kleine Startups Eigene Au­to­ma­ti­sie­run­gen, Webhooks, kleinere API-An­bin­dun­gen, erste Team-Nutzung 4 vCores CPU, 4 GB RAM, 120 GB NVMe
KMU mit mehreren Workflows und re­gel­mä­ßi­gen Aus­füh­run­gen Interne Au­to­ma­ti­sie­run­gen, CRM-/Shop-/Mail-An­bin­dun­gen, mehrere User 6 vCores CPU, 8 GB RAM, 240 GB NVMe
Wachsende Teams, Agenturen oder stark au­to­ma­ti­sier­te Um­ge­bun­gen Viele aktive Workflows, häufige Webhooks, Reserven für spätere Ska­lie­rung 8 vCores CPU, 16 GB RAM, 480 GB NVMe

Für besonders um­fang­rei­che Szenarien mit vielen gleich­zei­ti­gen Aus­füh­run­gen oder zu­sätz­li­chen Diensten auf demselben Server kann auch eine größere Aus­stat­tung mit 12 vCores, 24 GB RAM und 720 GB NVMe ebenfalls sinnvoll sein.

Self-hosted n8n
Mehr Pro­duk­ti­vi­tät dank n8n Au­to­ma­ti­sie­rung – Ihr bester VPS
  • Maximale Effizienz ohne Mehr­auf­wand
  • Self-hosted Au­to­ma­ti­on: Keine Task-Limits, volle Kos­ten­kon­trol­le
  • Über 500 In­te­gra­tio­nen & Tools dank Open Source

Schritt 2: Server vor­be­rei­ten und Basis-Pakete in­stal­lie­ren

Melden Sie sich per SSH auf Ihrem Ubuntu-Server an und ak­tua­li­sie­ren Sie zunächst die Pa­ket­quel­len sowie die in­stal­lier­ten Pakete. Das ist wichtig, damit Sie mit einer sauberen und aktuellen Grundlage starten.

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

An­schlie­ßend können Sie prüfen, ob der Server korrekt er­reich­bar ist und bereits eine öf­fent­li­che IP besitzt:

hostname -I
bash

Sie können die öf­fent­li­che IP zu­sätz­lich bei Ihrem Hosting-Anbieter über­prü­fen. Notieren Sie sich die Adresse, denn Sie benötigen sie gleich für den DNS-Eintrag Ihrer Subdomain.

Schritt 3: Subdomain auf den Server zeigen lassen

Legen Sie bei Ihrem Domain-Anbieter einen A-Record für Ihre ge­wünsch­te Subdomain an. Wenn Ihre n8n-Instanz später unter n8n.ihre-domain.de er­reich­bar sein soll, muss genau diese Subdomain auf die öf­fent­li­che IP Ihres Servers verweisen. Erst wenn dieser DNS-Record aktiv ist, können HTTPS und der externe Zugriff zu­ver­läs­sig funk­tio­nie­ren.

Ein typischer DNS-Eintrag sieht so aus:

Typ: A
Name: n8n
Wert: 203.0.113.10
TTL: 3600
txt

Schritt 4: K3s in­stal­lie­ren

Für Ein­stei­ge­rin­nen und Ein­stei­ger ist K3s meist der an­ge­nehms­te Weg, um Ku­ber­netes auf einem einzelnen Server be­reit­zu­stel­len. K3s bringt stan­dard­mä­ßig mehrere wichtige Kom­po­nen­ten als Addons mit, darunter Traefik als Ingress-Con­trol­ler und local-storage für lokale Per­sis­tenz.

In­stal­lie­ren Sie K3s zunächst mit folgendem Befehl:

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

Prüfen Sie danach mit folgendem Befehl, ob der Dienst läuft:

sudo systemctl status k3s
bash
Hinweis

Ku­ber­netes-Cluster nutzen un­ter­schied­li­che Ingress-Con­trol­ler, um externen Traffic an Services wei­ter­zu­lei­ten. In K3s ist stan­dard­mä­ßig Traefik aktiviert. Andere Con­trol­ler wie NGINX oder HAProxy werden ebenfalls häufig genutzt, un­ter­schei­den sich aber im Verhalten und Routing sowie in den er­for­der­li­chen Ein­stel­lun­gen.

Wenn alles korrekt gestartet ist, können Sie den Cluster-Status abrufen:

sudo k3s kubectl get nodes
bash
Bild: Cluster-Status
Die Anzeige des Cluster-Status bestätigt die er­folg­rei­che In­stal­la­ti­on von K3S.

Damit Sie kubectl leichter verwenden können, legen Sie am besten noch einen Alias an:

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

Wenn hier Ihr Server mit dem Status „Ready“ erscheint, ist Ku­ber­netes ein­satz­be­reit.

Hinweis

Wenn Sie keine Ku­ber­netes-Umgebung betreiben möchten, gibt es auch ein­fa­che­re In­stal­la­ti­ons­we­ge wie eine n8n Docker In­stal­la­ti­on oder Setups über andere Platt­for­men: So können Sie n8n mit CapRover oder n8n mit CasaOS nutzen. Diese eignen sich besonders für kleinere Projekte oder Ein­stei­ge­rin­nen und Ein­stei­ger. Auch eine n8n Plesk In­stal­la­ti­on ist denkbar.

Schritt 5: Helm in­stal­lie­ren

Der of­fi­zi­el­le n8n-Helm-Chart setzt Helm 3.12 oder neuer voraus. Helm ist ein so­ge­nann­ter Pa­ket­ma­na­ger für Ku­ber­netes und übernimmt eine ähnliche Rolle wie apt unter Ubuntu. Statt einzelne Kon­fi­gu­ra­ti­ons­da­tei­en manuell zu erstellen und zu verwalten, können Sie mit Helm komplette An­wen­dun­gen als so­ge­nann­te „Charts“ in­stal­lie­ren. Dadurch wird die In­stal­la­ti­on deutlich einfacher, über­sicht­li­cher und weniger feh­ler­an­fäl­lig.

Gerade für Ein­stei­ge­rin­nen und Ein­stei­ger ist Helm besonders hilfreich, da Sie nicht jede einzelne YAML-Datei verstehen oder selbst schreiben müssen. Statt­des­sen passen Sie nur einige zentrale Ein­stel­lun­gen an und Helm übernimmt den Rest au­to­ma­tisch. Auch Updates oder Än­de­run­gen lassen sich später einfacher durch­füh­ren, weil Helm den Zustand Ihrer In­stal­la­ti­on verwaltet.

In­stal­lie­ren Sie Helm nun direkt auf Ihrem Server. Die of­fi­zi­el­le Helm-Do­ku­men­ta­ti­on be­schreibt die In­stal­la­ti­on über vor­kom­pi­lier­te Bi­när­da­tei­en; unter Ubuntu ist jedoch auch die In­stal­la­ti­on über das be­reit­ge­stell­te Script üblich. Diese ist besonders un­kom­pli­ziert:

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
bash

Mit dem ersten Befehl laden Sie das In­stal­la­ti­ons­skript herunter. An­schlie­ßend machen Sie die Datei aus­führ­bar und führen sie aus. Das Script in­stal­liert Helm au­to­ma­tisch in der passenden Version auf Ihrem System.

Prüfen Sie danach, ob die In­stal­la­ti­on er­folg­reich war, indem Sie sich die in­stal­lier­te Version anzeigen lassen:

helm version
bash
Bild: Versionsanzeige von Helm
Nach er­folg­rei­cher Helm-In­stal­la­ti­on können Sie die Ver­si­ons­num­mer anzeigen lassen.

Wenn hier eine Ver­si­ons­num­mer aus­ge­ge­ben wird, ist Helm korrekt in­stal­liert und Sie den n8n-Chart verwenden.

Hinweis

Viele Nut­ze­rin­nen und Nutzer wechseln im Laufe der Zeit von ein­fa­che­ren Tools zu n8n. Eine typische Ent­wick­lung ist dabei die Zapier Migration zu n8n, um mehr Kontrolle über Daten, Workflows und Hosting zu erhalten.

Schritt 6: Namespace für n8n anlegen

Damit die n8n-Res­sour­cen sauber von anderen Ku­ber­netes-Objekten getrennt sind, erstellen Sie nun einen eigenen Namespace. Das ist in Ku­ber­netes eine bewährte Praxis.

kubectl create namespace n8n
bash

Kon­trol­lie­ren Sie danach, ob der Namespace vorhanden ist:

kubectl get namespaces
bash
Bild: Namespaces-Anzeige
Wenn Sie die Name­spaces auflisten lassen, sollten Sie in der Liste nun den „n8n“-Namespace sehen.

Schritt 7: cert-manager für TLS-Zer­ti­fi­ka­te in­stal­lie­ren

Für eine öf­fent­lich er­reich­ba­re In­stal­la­ti­on sollten Sie n8n direkt mit HTTPS be­reit­stel­len. n8n selbst empfiehlt bei TLS den Einsatz eines Reverse Proxys be­zie­hungs­wei­se eines vor­ge­schal­te­ten HTTP/HTTPS-Layers. In Ku­ber­netes übernimmt diese Rolle in dieser Anleitung Traefik, während cert-manager die Aus­stel­lung und Er­neue­rung der Zer­ti­fi­ka­te au­to­ma­ti­siert. cert-manager kann ebenfalls über einen Helm-Chart in­stal­liert werden. Nutzen Sie hierzu folgenden Befehl:

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

Prüfen Sie danach die Pods. Pods sind die kleinste aus­führ­ba­re Einheit in Ku­ber­netes und enthalten einen oder mehrere Container, die gemeinsam auf einem Knoten laufen. Sie stellen sicher, dass die ent­hal­te­nen Container zusammen aus­ge­führt werden und sich Res­sour­cen wie Netzwerk und Speicher teilen.

kubectl get pods -n cert-manager
bash
Bild: Cert-Manager Install mit Helm
Alle Ihrer Pods sollten als Status „Running“ anzeigen.

Warten Sie, bis alle Pods den Status „Running“ oder „Completed“ erreicht haben.

Schritt 8: Let’s-Encrypt-Clus­te­rIs­suer anlegen

Damit cert-manager später au­to­ma­tisch Zer­ti­fi­ka­te für Ihre Domain erstellen kann, legen Sie jetzt einen so­ge­nann­ten Clus­te­rIs­suer für Let’s Encrypt an. Ein Clus­te­rIs­suer ist eine zentrale Kon­fi­gu­ra­ti­on in Ku­ber­netes, die festlegt, von welchem Anbieter Zer­ti­fi­ka­te bezogen werden und wie die Über­prü­fung Ihrer Domain erfolgt. In diesem Fall wird Let’s Encrypt genutzt, ein kos­ten­lo­ser Anbieter für SSL-Zer­ti­fi­ka­te.

Für Ein­stei­ge­rin­nen und Ein­stei­ger ist die Va­li­die­rung per HTTP-01 meist am ein­fachs­ten, weil dabei keine Ver­bin­dung zu einer DNS-API er­for­der­lich ist. Statt­des­sen prüft Let’s Encrypt, ob Ihre Domain er­reich­bar ist, indem eine spezielle Datei über Ihre Website abgerufen wird. Wenn diese Anfrage er­folg­reich ist, gilt die Domain als ve­ri­fi­ziert und das Zer­ti­fi­kat wird aus­ge­stellt.

Erstellen Sie nun eine Datei namens clusterissuer.yaml:

nano clusterissuer.yaml
bash

In dieser de­fi­nie­ren Sie dann folgende Ein­stel­lun­gen:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
    name: letsencrypt-prod
spec:
    acme:
        email: ihre-mailadresse@beispiel.de
        server: https://acme-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
            name: letsencrypt-prod
        solvers:
            - http01:
                    ingress:
                        ingressClassName: traefik
yaml

Ersetzen Sie die E-Mail-Adresse durch Ihre eigene. Diese wird von Let’s Encrypt verwendet, um Sie über wichtige In­for­ma­tio­nen wie ab­lau­fen­de Zer­ti­fi­ka­te zu in­for­mie­ren.

Wenden Sie die Datei an­schlie­ßend auf Ihren Ku­ber­netes-Cluster an:

kubectl apply -f clusterissuer.yaml
bash

Damit wird der Clus­te­rIs­suer erstellt und steht allen An­wen­dun­gen im Cluster zur Verfügung. Prüfen Sie an­schlie­ßend, ob die Ressource korrekt angelegt wurde:

kubectl get clusterissuer
bash
Bild: Anzeige des Clusterissuers
Bei der Anzeige des Clus­te­ris­suers sollte der Wert bei „READY“ „True“ sein.

Wenn der Clus­te­rIs­suer angezeigt wird, ist die Kon­fi­gu­ra­ti­on er­folg­reich. Die ei­gent­li­che Aus­stel­lung eines Zer­ti­fi­kats erfolgt später au­to­ma­tisch, sobald n8n über eine Domain er­reich­bar ist und ein ent­spre­chen­der Ingress ein­ge­rich­tet wurde.

Schritt 9: n8n-Secret mit den wich­tigs­ten Um­ge­bungs­va­ria­blen anlegen

Der of­fi­zi­el­le Helm-Chart erwartet zentrale Secret-Werte, darunter N8N_ENCRYPTION_KEY, N8N_HOST, N8N_PORT und N8N_PROTOCOL. Diese Werte sind immer er­for­der­lich. Ersetzen Sie n8n.ihre-domain.de durch Ihre echte Subdomain und führen Sie dann folgenden Befehl aus:

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

Schritt 10: values-Datei für die n8n-In­stal­la­ti­on anlegen

Wir in­stal­lie­ren n8n im so­ge­nann­ten Stan­da­lo­ne-Modus. Das bedeutet, dass n8n in einer einfachen Kon­fi­gu­ra­ti­on betrieben wird: Es läuft in einem einzelnen Pod und benötigt keine zu­sätz­li­chen Dienste wie eine externe Datenbank oder Redis. Statt­des­sen wird eine in­te­grier­te SQLite-Datenbank verwendet. Diese Variante ist ideal für erste Projekte, kleinere In­stal­la­tio­nen oder zum Lernen, da sie deutlich weniger komplex ist.

Damit Helm weiß, wie n8n ein­ge­rich­tet werden soll, erstellen Sie nun eine Kon­fi­gu­ra­ti­ons­da­tei namens n8n-values.yaml.

nano n8n-values.yaml
bash

In dieser Datei legen Sie die wich­tigs­ten Ein­stel­lun­gen für Ihre In­stal­la­ti­on fest, zum Beispiel Um­ge­bungs­va­ria­blen, Spei­cher­platz oder die 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: Europe/Berlin
ingress:
    enabled: true
    className: traefik
    annotations:
        cert-manager.io/cluster-issuer: letsencrypt-prod
    hosts:
        - host: n8n.ihre-domain.de
            paths:
                - path: /
                    pathType: Prefix
    tls:
        - secretName: n8n-tls
            hosts:
                - n8n.ihre-domain.de
yaml

Ersetzen Sie unbedingt n8n.ihre-domain.de durch Ihre eigene Domain. Diese Datei dient als zentrale Steuerung für Ihre In­stal­la­ti­on und kann später jederzeit angepasst werden, wenn Sie n8n erweitern oder skalieren möchten.

Hinweis

Der Chart bietet deutlich mehr Optionen, darunter auch Queue Mode, Worker, HPA und de­di­zier­te Webhook-Pro­zes­so­ren. Für eine erste In­stal­la­ti­on ist diese re­du­zier­te Kon­fi­gu­ra­ti­on aber meist der sinn­volls­te Einstieg. Die of­fi­zi­el­len n8n-Un­ter­la­gen un­ter­schei­den klar zwischen Stan­da­lo­ne für kleine Um­ge­bun­gen und Queue Mode für ska­lier­ba­re Setups mit Post­greS­QL und Redis.

Schritt 11: n8n mit dem of­fi­zi­el­len Helm-Chart in­stal­lie­ren

Nun folgt der ei­gent­li­che n8n-Ku­ber­netes-Install mithilfe des Helm-Charts. Führen Sie dazu den In­stal­la­ti­ons­be­fehl aus:

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

Danach prüfen Sie, ob die Res­sour­cen erstellt wurden:

kubectl get all -n n8n
bash

Und an­schlie­ßend kon­trol­lie­ren Sie die Pods genauer, um si­cher­zu­stel­len, dass n8n korrekt gestartet wurde und keine Fehler auf­ge­tre­ten sind

kubectl get pods -n n8n -w
bash

Sobald der Haupt-Pod läuft und bereit ist, ist n8n im Cluster in­stal­liert.

Hinweis

Neben dem in dieser Anleitung ver­wen­de­ten OCI-Chart von ghcr.io/n8n-io exis­tie­ren weitere Helm-Chart-Quellen, mit denen n8n auf Ku­ber­netes in­stal­liert werden kann. Dazu gehört ein von der Community ge­pfleg­ter Chart, der über das GitHub-Community-Charts-Projekt be­reit­ge­stellt wird und re­gel­mä­ßig ak­tua­li­siert wird, sowie der weit ver­brei­te­te 8gears Chart, der als Open-Source-Projekt auf GitHub und auf Ar­ti­fact­Hub gelistet ist.

Schritt 12: Ingress und Zer­ti­fi­kat prüfen

Weil Sie in der values-Datei bereits Ingress und TLS kon­fi­gu­riert haben, sollte cert-manager nun ein Zer­ti­fi­kat für Ihre Subdomain anfordern. Prüfen Sie zuerst den Ingress:

kubectl get ingress -n n8n
bash

Danach prüfen Sie das Zer­ti­fi­kat:

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

Schritt 13: n8n im Browser öffnen und Erst­ein­rich­tung ab­schlie­ßen

Sobald der Ingress aktiv ist und das Zer­ti­fi­kat er­folg­reich erstellt wurde, rufen Sie Ihre Instanz im Browser auf:

https://n8n.ihre-domain.de

Beim ersten Aufruf führt n8n Sie durch die initiale Ein­rich­tung. In der Regel legen Sie dabei zunächst den ersten User für die Instanz an.

Bild: n8n im Browser
Nachdem der n8n Ku­ber­netes Install auf dem Server ab­ge­schlos­sen ist, können Sie n8n über Ihre Domain erreichen und sehen den Login-Screen.

Schritt 14: In­stal­la­ti­on testen

Nach der Erst­ein­rich­tung sollten Sie kurz kon­trol­lie­ren, ob die In­stal­la­ti­on wirklich sauber läuft. Öffnen Sie dazu den n8n-Editor, erstellen Sie einen einfachen Test-Workflow und speichern Sie ihn. Zu­sätz­lich lohnt sich ein Blick in die Logs des Haupt-Pods.

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

Wenn der Editor er­reich­bar ist, die Anmeldung funk­tio­niert und in den Logs keine of­fen­sicht­li­chen Fehler auf­tau­chen, ist die Grund­in­stal­la­ti­on er­folg­reich ab­ge­schlos­sen.

Schritt 15: Was Sie für den pro­duk­ti­ven Betrieb wissen sollten

Für kleinere In­stal­la­tio­nen ist der Stan­da­lo­ne-Modus ein guter Start. Der of­fi­zi­el­le Chart und die n8n-Do­ku­men­ta­ti­on un­ter­schei­den jedoch klar zwischen Stan­da­lo­ne und Queue Mode. Sobald mehrere Nut­ze­rin­nen und Nutzer, mehr gleich­zei­ti­ge Aus­füh­run­gen oder hohe Webhook-Last ins Spiel kommen, ist der Queue Mode die robustere Option. Dann kommen Post­greS­QL und Redis hinzu. Auch Worker können dann un­ab­hän­gig skaliert werden.

Zum Hauptmenü