Selbst gehostete n8n-Automatisierung für Links: Von Docker zu Webhooks

Selbst gehostete n8n-Automatisierung für Links bedeutet drei Dinge, die auf Servern laufen, die du kontrollierst: eine n8n-Instanz in Docker, einen öffentlichen HTTPS-Endpunkt, der Elido-Webhook-Ereignisse empfängt, und ausgehende Aufrufe zurück an die Elido-API mit einem begrenzten Token. Link- und Domain-Ereignisse kommen signiert an, und Ereignisse pro Klick sind auf der Roadmap. Deine Workflows entscheiden, was als Nächstes passiert, und die Ausführungslogs verlassen deine Infrastruktur nie.

Das ist die gesamte Architektur. Der Rest dieses Beitrags ist der Teil, den die Schnelleinstiege auslassen: wie Webhooks durch einen Reverse Proxy kommen, wie man die Signatur prüft, damit keine fremde Person deine Workflows auslösen kann, was der Queue-Mode ändert, und wann n8n Cloud ehrlich die bessere Wahl ist. Ich betreibe dieses Setup auf einer einzelnen kleinen VM, und die beweglichen Teile passen auf einen Bildschirm.

Willst du auch die Links selbst auf eigener Hardware, ist das eine separate und viel größere Aufgabe. Das Playbook zum Self-Hosting von Elido auf k3s behandelt das. Hier bleibt Elido gemanagt, und nur die Automatisierungsebene zieht ins Haus um.

Warum n8n für Link-Automatisierung selbst hosten

Der übliche Grund sind Daten. Ein n8n-self-hosted-URL-Shortener-Workflow sieht jedes Payload, das er verarbeitet: die Ziel-URL, Tags, manchmal einen Kampagnennamen, der mehr verrät, als dir lieb ist, und Land, Gerät und Referrer, wenn du Klick-Analytics hineinziehst. Auf n8n Cloud liegen diese Ausführungen auf fremden Servern, unter fremden Aufbewahrungsstandards. Selbst gehostet liegen sie in deinem Postgres, in der Region, die du gewählt hast.

Unter Artikel 28 der DSGVO braucht jeder Auftragsverarbeiter, der personenbezogene Daten berührt, einen Vertrag und einen Platz in deinen Aufzeichnungen. Weniger Auftragsverarbeiter, weniger Papierarbeit. Müssen deine Marketingdaten ohnehin in der EU bleiben, erklärt der Leitfaden zur EU-Data-Residency, warum die Automatisierungsebene genauso zählt wie der Shortener.

Der zweite Grund ist die Kostenform. n8n Cloud berechnet nach Ausführungen, und ein vielbeschäftigter Webhook-Trigger oder ein häufiger Analytics-Poll verbraucht schnell Ausführungen. Selbst gehostet ist eine Ausführung eine Zeile in einer Tabelle und ein paar Millisekunden CPU.

Der dritte ist Reichweite. Eine selbst gehostete Instanz sitzt im selben Netzwerk wie deine CRM-Datenbank oder internes Ticketing-Tool, sodass ein Link-Ereignis in einem System landen kann, das nie fürs Internet gedacht war.

Der Docker-Compose-Stack

Ein minimaler n8n-Docker-Link-Automatisierungs-Stack braucht vier Dienste. n8ns eigener Docker-Compose-Leitfaden ist die Referenz; das ist die Version, von der ich für Link-Arbeit ausgehen würde, mit bereits eingeschaltetem Queue-Mode, damit du nicht später migrieren musst.

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: n8n
    volumes: [pgdata:/var/lib/postgresql/data]

  redis:
    image: redis:7

  n8n:
    image: docker.n8n.io/n8nio/n8n
    env_file: .env.n8n
    ports: ["127.0.0.1:5678:5678"]
    depends_on: [postgres, redis]

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n
    command: worker
    env_file: .env.n8n
    depends_on: [n8n]

volumes:
  pgdata:

Und die gemeinsame Umgebungsdatei:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=change-me
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
N8N_ENCRYPTION_KEY=generate-a-long-random-string
N8N_WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

Zwei Zeilen zählen mehr, als sie aussehen. Der Encryption Key muss auf dem Hauptprozess und jedem Worker identisch sein, sonst können Worker das Elido-Credential nicht entschlüsseln, und jede Ausführung scheitert mit einem verwirrenden Auth-Fehler. Und Port 5678 ist nur an localhost gebunden, denn der Reverse Proxy ist das Einzige, was dem Internet zugewandt sein sollte.

Die Elido-API von selbst gehostetem n8n aus aufrufen

Ausgehende Aufrufe brauchen nichts über das hinaus, was n8n mitliefert. Erstelle ein Header-Auth-Credential mit dem Namen Authorization und dem Wert Bearer gefolgt von einem API-Schlüssel aus dem Elido-Dashboard, dann nutze es vom eingebauten HTTP-Request-Node aus. n8n verschlüsselt es at rest mit dem Schlüssel aus der Umgebungsdatei, ein weiterer Grund, warum dieser Schlüssel überall übereinstimmen muss.

Jede Link-Route ist an einen Workspace gebunden. Um eine URL zu kürzen, POST an https://api.elido.app/v1/workspaces/{workspace_id}/links mit einem JSON-Body:

{
  "domain_id": 12,
  "destination_url": "{{ $json.url }}",
  "title": "Spring launch",
  "tags": ["n8n", "spring"]
}

Lass slug weg, und Elido generiert eines. Die domain_id ist die Short-Domain, auf der der Link liegt; ein GET an /v1/workspaces/{workspace_id}/domains listet deine auf, und ich würde die ID im Workflow fest hinterlegen, statt sie bei jedem Lauf nachzuschlagen. Ein GET auf derselben Links-Route listet Links auf, und PATCH /v1/workspaces/{workspace_id}/links/{link_id} ändert nachträglich ein Ziel oder Tags.

Setze einen Idempotency-Key-Header auf dem POST, gebaut aus etwas Stabilem im auslösenden Item, etwa einer Zeilen-ID. Wiederholt n8n den Node nach einem Timeout, spielt die API die erste Antwort erneut ab, statt einen zweiten Link zu erstellen. Der Schnelleinstieg API und SDKs deckt den Rest der Oberfläche ab, und die Seite API und SDKs steht bereit, falls du einen Schritt später in Code verschieben möchtest.

Es gibt außerdem einen paketierten Community-Node, n8n-nodes-elido, der diese Aufrufe in eine freundlichere Form verpacken soll. Er ist auf npm (Version 0.2.0) veröffentlicht, bleibt aber optional. Da es sich nicht um einen verifizierten Node handelt, lässt er sich nur in selbst gehostetem n8n installieren, was ohnehin der in diesem Beitrag vorausgesetzten Einrichtung entspricht. Behalten Sie die HTTP-Request-Version als Basis. Wenn Sie Community-Pakete im Queue-Mode installieren, denken Sie daran, dass die GUI nur in den Hauptcontainer installiert; Worker sehen sie nie. Ab n8n 2.21 löst die Installation über Umgebungsvariablen das, indem sie jeden Container beim Start abgleicht, wobei sie beim ersten Mal alles deinstalliert, was nicht auf ihrer Liste steht.

Elido-Webhooks durch deinen Reverse Proxy führen

Ereignisse fließen in die andere Richtung. Elido sendet link.created, link.updated und domain.verified (unter anderem) an einen Endpunkt, den du unter Settings, Webhooks registrierst, und bei selbst gehostetem n8n ist dieser Endpunkt die Produktions-URL eines Webhook-Nodes. Ein click.created-Ereignis pro Klick ist auf der Roadmap, aber noch nicht ausgeliefert, Klickdaten kommen also bis dahin aus einem geplanten Pull der Analytics-API. Die vollständige Ereignisliste und Payload-Formen stehen in der Referenz Webhooks für Link-Ereignisse.

Hinter einem Proxy baut n8n seine Webhook-URL aus seinem eigenen Protokoll, Host und Port, was bedeutet, dass es jedem, der fragt, bereitwillig http://localhost:5678/webhook/... mitteilt. Die Konfigurationsseite zum Reverse Proxy ist kurz und lohnt sich vollständig zu lesen: Setze N8N_WEBHOOK_URL auf deine öffentliche Adresse, setze N8N_PROXY_HOPS=1, und lass den letzten Proxy X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weiterleiten. Ältere Anleitungen nennen WEBHOOK_URL; aktuelle Releases lesen sie noch, protokollieren aber eine Deprecation-Warnung.

Nginx, Traefik, was auch immer du bereits betreibst, ist in Ordnung. Wichtig ist TLS auf der öffentlichen Seite und dass der Pfad /webhook/* n8n unangetastet erreicht.

Ein Timing-Detail hat mich einmal erwischt. Elido wartet zehn Sekunden auf eine Antwort, bevor eine Zustellung als fehlgeschlagen zählt. Ein Workflow, der in eine langsame Spreadsheet-API schreibt und danach antwortet, kann das sprengen, wird erneut versucht, und schreibt dieselbe Zeile zweimal. Stelle den Webhook-Node so ein, dass er sofort antwortet und die Arbeit danach erledigt.

Baust du das für eine Kundin und willst die Webhook-Seite fertig eingerichtet bekommen, zeigt die Webhook-Feature-Seite, was du abonnieren kannst, bevor du überhaupt etwas baust.

Die Signatur verifizieren, bevor irgendetwas läuft

Eine öffentliche Webhook-URL ist eine öffentliche URL. Jeder, der sie findet, kann ein gefälschtes Ereignis posten und deinen Workflow auslösen, der erste Node nach dem Trigger sollte also eine Signaturprüfung sein.

Jede Elido-Zustellung trägt X-Webhook-Signature (Wert v1= plus ein Hex-Digest), X-Webhook-Timestamp in Unix-Sekunden, X-Webhook-Event und X-Webhook-Delivery. Das Digest ist HMAC-SHA256 über den Zeitstempel, einen Punkt und den rohen Request-Body, mit dem einmal angezeigten whsec_-Secret als Schlüssel, das beim Erstellen des Endpunkts vergeben wurde.

Schalte zuerst Raw Body im Webhook-Node ein. Das ist der Schritt, den Leute überspringen. Hashst du stattdessen JSON.stringify($json.body) statt der exakten Bytes, die Elido gesendet hat, unterscheiden sich Feldreihenfolge oder Whitespace, und jede Signatur schlägt fehl - du verbringst dann einen Abend in der Überzeugung, das Secret sei falsch. Dann ein Code-Node:

const crypto = require("crypto");
const item = $input.first();
const h = item.json.headers;
const raw = (await this.helpers.getBinaryDataBuffer(0, "data")).toString(
  "utf8",
);

const ts = Number(h["x-webhook-timestamp"]);
if (Math.abs(Date.now() / 1000 - ts) > 300) throw new Error("stale delivery");

const expected =
  "v1=" +
  crypto
    .createHmac("sha256", $env.ELIDO_WEBHOOK_SECRET)
    .update(`${ts}.${raw}`)
    .digest("hex");
const got = h["x-webhook-signature"] || "";
if (
  got.length !== expected.length ||
  !crypto.timingSafeEqual(Buffer.from(got), Buffer.from(expected))
) {
  throw new Error("bad signature");
}
return [{ json: JSON.parse(raw) }];

Das crypto-Modul ist im Code-Node standardmäßig verfügbar, es braucht also keine zusätzliche Konfiguration dafür. Das Fünf-Minuten-Fenster blockiert das Wiederholen einer abgefangenen Anfrage. Rotierst du das Secret, sendet Elido während der Übergangsfrist zusätzlich X-Elido-Signature-Previous, sodass du eines der beiden Secrets akzeptieren kannst, während du die Variable aktualisierst. Der Leitfaden zur Verifizierung von Webhook-Signaturen enthält eine Version dieses Nodes, die beide Header prüft, sowie dieselbe Prüfung in Node, Python und Go.

Queue-Mode und Retries

Mit der Signaturprüfung an Ort und Stelle bleibt die Frage, was unter Last oder bei einem Ausfall passiert. Zwei Retry-Systeme sind hier im Spiel, und sie decken unterschiedliche Fehler ab.

Im n8n-Queue-Mode empfängt der Hauptprozess den Webhook, erstellt eine Ausführung und übergibt ihre ID an Redis; Worker holen sie ab. Ein Schub an Ereignissen staut sich in der Queue, statt die HTTP-Antwort zu blockieren. Für mehr eingehendes Volumen kannst du dedizierte Webhook-Prozessoren hinter einem Load Balancer hinzufügen, auch wenn für die meisten Link-Workloads ein Hauptprozess und zwei Worker reichlich sind.

Elidos Seite behandelt es, wenn n8n nicht erreichbar ist. Jede Nicht-2xx-Antwort oder ein Timeout wird nach 1, 5 und 15 Minuten erneut versucht; nach drei Versuchen wird die Zustellung als fehlgeschlagen markiert, und du kannst sie vom Dashboard aus wieder scharf schalten. Das deckt einen Container-Neustart oder ein schnelles Deployment ab. Es deckt keinen Wochenendausfall ab, weshalb ich Webhooks mit einem nächtlichen Abgleich koppeln würde, der Links über die API auflistet, wie der Beitrag Webhooks vs. Polling argumentiert.

Nutze X-Webhook-Delivery als Idempotenzschlüssel. Retries verwenden ihn wieder.

Selbst gehostetes n8n vs. n8n Cloud: ehrliche Abwägungen

Ich bevorzuge für diese Aufgabe Self-Hosting, habe aber schon Teams gesehen, die es bereut haben. Hier der Vergleich ohne Verkaufsargumente von beiden Seiten.

Die letzte Zeile schneidet in beide Richtungen. Eine kleine VM ist billig, aber die Stunde einer Ingenieurin an einem gescheiterten Upgrade ist es nicht, und n8n liefert häufig aus. Wenn niemand im Team die Kiste besitzt, ist Cloud mit dem HTTP-Request-Node und Elidos REST-API die vernünftigere Wahl, und die Make- und IFTTT-Rezepte oder der Zapier-Leitfaden zeigen, wie dieser gemanagte Weg auf anderen Plattformen aussieht.

Was ich dir nicht sagen kann: ob deine Datenschutzbeauftragte eine selbst gehostete Kiste als einfacher akzeptiert als eine Anbieter-DPA. Aus meiner Erfahrung tun sie das meistens, aber das hängt davon ab, wie gut die Kiste betrieben wird. Wie die Shortener-Seite des Vertrags funktioniert, dazu ist der DSGVO-Leitfaden für URL-Shortener der richtige Ausgangspunkt. Und bist du bereit, den ersten Workflow zu verdrahten, hol dir ein API-Token für einen Workspace und richte einen Webhook-Node darauf aus.

Verwandtes im Blog

• Elido selbst hosten auf k3s: das Playbook - wenn die Links auch im eigenen Haus liegen müssen.
• Webhooks für Link-Ereignisse - jeder Ereignistyp und jede Payload-Form.
• Webhooks vs. Polling für Click-Tracking - warum der nächtliche Abgleich zählt.
• Short-Link-Automatisierung mit Make und IFTTT - der gemanagte Low-Code-Weg.
• n8n-URL-Shortener - das HTTP-Request-Node-Setup und drei Workflows im Detail.
• Webhook-Signaturen verifizieren - roher Body, Replay-Fenster und Secret-Rotation in vier Laufzeitumgebungen.