In diesem realen Ubuntu-24.04.4-LTS-VPS-Setup wurde n8n mit Docker installiert, das Volume n8n_data und ein fester Encryption Key vorbereitet, die Anwendung nur an 127.0.0.1:5678 gebunden, n8n.ekasunucu.com über Nginx und Let’s Encrypt veröffentlicht und der komplette Erststart vom Owner-Konto bis zum Workflow-Editor mit echten WebP-Screenshots geprüft.
Ubuntu 24.04.4 LTS
↓ Docker
n8n :5678 → 127.0.0.1
↓
n8n_data + Encryption Key
↓
Nginx + WebSocket
↓
Let’s Encrypt HTTPS
↓
n8n.ekasunucu.comDiese Anleitung dokumentiert eine reale n8n-Installation unter Ubuntu 24.04.4 LTS mit Docker, einem nur lokal gebundenen Anwendungsport und n8n.ekasunucu.com hinter Nginx und Let’s Encrypt.
Im finalen Aufbau verbinden sich Benutzer nicht direkt mit Port 5678. HTTPS erreicht Nginx auf 443 und wird an den n8n-Container auf 127.0.0.1:5678 weitergeleitet. Persistente Daten liegen im Named Volume n8n_data.
Internet :443
↓
Nginx + Let’s Encrypt
↓
127.0.0.1:5678
↓
n8n Docker-Container
↓
n8n_data VolumeDer Testserver lief mit Ubuntu 24.04.4 LTS und aktivem Docker Engine. Betriebssystem, Kernel, RAM, Datenträger und Docker sollten vor der Installation geprüft werden.
n8n.ekasunucu.com wurde vor dem Zertifikatsabruf über Cloudflare- und Google-DNS aufgelöst. Vor Let’s Encrypt muss DNS auf den gewünschten Server zeigen.
cat /etc/os-release | grep -E 'PRETTY_NAME|VERSION_ID|VERSION_CODENAME'
uname -r
free -h
df -h /docker --version
docker compose version
systemctl is-active dockerdig +short A n8n.ekasunucu.com @1.1.1.1
dig +short A n8n.ekasunucu.com @8.8.8.8Wir verwenden das Named Volume n8n_data statt nur das Container-Dateisystem, damit Benutzer-, Workflow- und Credential-Daten eine Container-Neuerstellung überstehen können.
Einen festen N8N_ENCRYPTION_KEY erzeugen und sicher sichern. Host, Protokoll, Editor-URL, Webhook-URL, Proxy-Hops und Zeitzone werden explizit definiert.
docker volume inspect n8n_data >/dev/null 2>&1 || docker volume create n8n_dataopenssl rand -hex 32cat > /root/n8n.env <<'EOF'
N8N_ENCRYPTION_KEY=BURAYA_UZUN_RASTGELE_ANAHTAR
N8N_HOST=n8n.ekasunucu.com
N8N_PORT=5678
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.ekasunucu.com
N8N_WEBHOOK_URL=https://n8n.ekasunucu.com/
N8N_PROXY_HOPS=1
N8N_SECURE_COOKIE=true
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
GENERIC_TIMEZONE=Europe/Istanbul
TZ=Europe/Istanbul
NODE_ENV=production
EOF
chmod 600 /root/n8n.envWir haben das offizielle n8n-Image von docker.n8n.io geladen und den Container mit Restart-Policy gestartet. Host-Port 5678 ist an 127.0.0.1 statt 0.0.0.0 gebunden.
Das Volume n8n_data wird nach /home/node/.n8n gemountet. Öffentlicher Zugriff erfolgt damit über Nginx statt über einen direkt veröffentlichten Docker-Port.
docker pull docker.n8n.io/n8nio/n8n:latestdocker rm -f n8n 2>/dev/null || true
docker run -d \
--name n8n \
--restart=always \
--env-file /root/n8n.env \
-p 127.0.0.1:5678:5678 \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n:latestNach dem Start lieferte /healthz HTTP 200 mit {"status":"ok"}. Im realen Test lief n8n 2.33.7.
Datenbankmigrationen beim ersten Start sind normal. Der Log zeigte außerdem, dass ein interner Python Task Runner ohne Python 3 nicht startete und n8n für Produktion den externen Modus empfahl. Der JS Task Runner wurde registriert und der normale Editor blieb funktionsfähig.
Weitere Deprecation-Hinweise kündigten zukünftige Default-Änderungen an. Deshalb nach Updates immer docker logs prüfen.
curl -sS -i http://127.0.0.1:5678/healthzdocker exec n8n n8n --versiondocker logs --tail 160 n8nDa n8n nur auf 127.0.0.1:5678 lauscht, dient Nginx als öffentlicher Reverse Proxy. Host-, X-Forwarded- und WebSocket-Upgrade-Header werden an n8n weitergegeben.
Nach erfolgreichem nginx -t holte Certbot das Zertifikat für n8n.ekasunucu.com und deployte es. Die finalen HTTPS-Tests lieferten HTTP 200.
cat > /etc/nginx/conf.d/eka-websocket-map.conf <<'EOF'
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
EOFcat > /etc/nginx/sites-available/n8n.ekasunucu.com <<'EOF'
server {
listen 80;
listen [::]:80;
server_name n8n.ekasunucu.com;
client_max_body_size 100m;
location / {
proxy_pass http://127.0.0.1:5678;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_buffering off;
proxy_read_timeout 3600;
proxy_send_timeout 3600;
}
}
EOF
ln -sfn /etc/nginx/sites-available/n8n.ekasunucu.com /etc/nginx/sites-enabled/n8n.ekasunucu.com
nginx -t && systemctl reload nginxcertbot --nginx -d n8n.ekasunucu.comcurl -I https://n8n.ekasunucu.comIm finalen Setup lauscht n8n auf 127.0.0.1:5678, während nach außen nur Nginx auf 80 und 443 veröffentlicht ist.
certbot renew --dry-run prüft die Verlängerung ohne das Live-Zertifikat zu ersetzen. systemctl --failed zeigte keine fehlgeschlagenen systemd-Dienste.
ss -lntp | grep -E ':5678|:80|:443'docker ps --filter name='^/n8n$'certbot renew --dry-runsystemctl --failedBeim Öffnen der HTTPS-Domain erscheint die Einrichtung des Owner-Kontos. In Produktion ein starkes, eindeutiges Kennwort verwenden.
Danach kann n8n Fragen zur Personalisierung und Nutzung anzeigen. Nach Abschluss gelangt man zur Hauptoberfläche.
Nach der Einrichtung öffnet n8n den Workflow-Bereich. Ein erfolgreich geladener leerer Workflow bestätigt grundlegende Session-, Frontend- und Backend-Funktion.
Danach können Trigger, HTTP Request, Datenbank-, Mail-, Telegram- oder KI-Nodes hinzugefügt werden.
Die funktionierende Self-Hosted Community Edition bot optional eine kostenlose Registrierung an. Im realen Test kam der Key per E-Mail und die Aktivierung wurde im Panel abgeschlossen.
Die verfügbaren Registered-Funktionen können sich ändern. Docker-, Nginx- und SSL-Grundbetrieb sind davon unabhängig.




Nach der Aktivierung öffneten sich Workflows-Startseite und Editor normal. Die Instanz ist nun per HTTPS erreichbar, Daten sind persistent und Port 5678 bleibt lokal gebunden.
Als Nächstes können Webhooks, APIs, E-Mail-Prozesse oder lokale KI-Dienste wie Ollama angebunden werden.
Vor n8n-Updates das Volume n8n_data sichern oder einen VPS-Snapshot erstellen. Container mit derselben Environment-Datei und demselben Volume neu erstellen.
Nach Updates /healthz, docker logs, HTTPS und Webhook-Verhalten erneut testen. n8n bietet außerdem einen Security-Audit-Befehl für häufige Instanzrisiken.
docker exec n8n n8n auditdocker logs --tail 200 n8ncurl -sS http://127.0.0.1:5678/healthzcertbot renew --dry-runJa. Im realen Test lief n8n 2.33.7 unter Ubuntu 24.04.4 LTS mit dem offiziellen Docker-Image.
Der Standardport ist 5678. In dieser Anleitung ist er hostseitig nur an 127.0.0.1:5678 gebunden.
Nein. n8n bleibt lokal und öffentlicher Zugriff erfolgt über Nginx und HTTPS.
Es hält n8n-Anwendungsdaten bei einer Container-Neuerstellung persistent.
n8n verwendet ihn zur Credential-Verschlüsselung. Verlust oder Änderung kann vorhandene Credentials unbrauchbar machen.
Dieses Beispiel nutzt N8N_WEBHOOK_URL=https://n8n.ekasunucu.com/. Unser realer Startlog markierte WEBHOOK_URL als veraltet.
Upgrade- und Connection-Header sind für langlebige und Echtzeit-Verbindungen wichtig.
Nach dem Nginx-vHost holte Certbot --nginx ein Let’s-Encrypt-Zertifikat und deployte es.
Mit certbot renew --dry-run lässt sich die Verlängerung simulieren.
Ja. Self-Hosted Community Edition funktioniert. Im Test wurde zusätzlich optional Registered Community Edition aktiviert.
Der interne Python Runner startete ohne Python 3 nicht und n8n empfahl für Produktion den externen Modus. Editor und JS-Workflows liefen weiter.
Ja. Neue oder aktualisierte Instanzen können beim Start Migrationen ausführen.
n8n_data sichern oder VPS-Snapshot erstellen und Environment-Datei sowie Encryption Key aufbewahren.
Mit n8n audit lassen sich typische Credential-, Datenbank-, Dateisystem-, Node- und Instanzrisiken prüfen.
Webhook-, API-, KI- und Geschäftsautomatisierungen auf einem eigenen EKA-Sunucu-Linux-VPS betreiben.
Aktualisiert: 10.08.2026