n8n-Webhook an Postgres: ein Deployment-Beispiel auf Lizard

Ein n8n-Webhook kann JSON an Postgres schreiben und die gespeicherte Zeile in einem Workflow zurückgeben. Dieses Beispiel führt n8n auf Lizard aus, schützt den Webhook mit einem Header-Credential und nutzt eine Request-ID, um doppelte Zeilen zu vermeiden, wenn ein Sender erneut sendet.

Das öffentliche Repository enthält das gepinnte Image, den Workflow, die Tabellendefinition und das Prüfskript. Dieser Artikel behandelt eine einzelne n8n-Instanz und JSON-Anfragen. Für die umfassendere Hosting-Einrichtung beginnen Sie mit n8n Hosting auf Lizard.

Was das Beispiel ausführt

Der n8n-Dienst und seine dedizierte Managed Postgres laufen in derselben Region. Postgres speichert sowohl n8ns eigene Workflow- und Credential-Datensätze als auch die Beispieltabelle webhook_events. Die Anwendung nutzt eine Instanz; in diesem Beispiel gibt es keine Redis-Warteschlange oder separaten Worker.

Das Repository pinnt n8n 2.38.5 und den Digest des offiziellen Images. Ein fester Digest macht die Image-Wahl reproduzierbar. Prüfen Sie spätere n8n-Versionen und testen Sie Upgrades, bevor Sie den Pin ändern.

Der Workflow hat drei Knoten:

1. Webhook akzeptiert eine produktive POST-Anfrage mit einem X-Example-Key-Header.
2. Ereignis speichern führt eine parametrisierte Postgres-Abfrage aus.
3. Antworten gibt die gespeicherte Request-ID, den JSON-Body und den Erstellungszeitpunkt zurück.

Datenbank, Owner und öffentliche URL konfigurieren

Erstellen Sie einen Service aus dem Repository und eine separate Managed Postgres im selben Lizard-Projekt. Die Repository-Anweisungen listen die Befehle und Umgebungsvariablen auf.

Setzen Sie DB_TYPE=postgresdb und binden Sie Datenbank-Host, Port, Name, Benutzer und Passwort an die Variablen des Addons. Eine neben n8n laufende Datenbank reicht nicht: n8n muss diese Werte erhalten und erfolgreich verbinden. Siehe n8ns Postgres-Konfiguration.

Generieren und bewahren Sie einen separaten N8N_ENCRYPTION_KEY vor dem ersten Start auf. n8n nutzt ihn, um in seiner Datenbank gespeicherte Credentials zu schützen. Ein neuer zufälliger Key bei jedem Deployment würde verhindern, dass n8n die alten Credentials lesen kann. Bewahren Sie den Key mit Ihren Wiederherstellungsunterlagen auf, außerhalb des Repositorys.

Das Beispiel konfiguriert auch den Owner, bevor n8n erreichbar wird. Es nutzt N8N_INSTANCE_OWNER_MANAGED_BY_ENV und einen bcrypt-Passwort-Hash, gemäß n8ns Owner-Konfiguration. Das Login-Passwort und der Webhook-Key sind separate Geheimnisse.

Setzen Sie N8N_HOST auf den öffentlichen Hostnamen des Services, ohne Schema oder Pfad. Das Startskript baut die HTTPS-WEBHOOK_URL und die Editor-URL aus diesem Hostnamen. Nutzen Sie Port 5678. Prüfen Sie die Proxy-Hop-Einstellung, falls Sie einen weiteren Proxy vor Lizard schalten.

Workflow importieren und veröffentlichen

Erstellen Sie webhook_events mit der SQL-Datei im Repository. Importieren Sie die Postgres- und Header-Credentials in n8n, dann importieren Sie den Workflow. Das Credential-Vorbereitungsskript liest geheime Werte aus der Service-Umgebung und schreibt eine private temporäre Importdatei; der öffentliche Workflow enthält nur Credential-IDs und Namen.

Nutzen Sie den n8n-Editor, um den Workflow zu veröffentlichen, oder nutzen Sie n8n publish:workflow --id=lizardPostgresExample. Eine CLI-Veröffentlichung ändert die Datenbank; der laufende n8n-Prozess braucht einen Neustart, um diese Änderung zu registrieren. Dieses Verhalten ist im n8n CLI-Leitfaden dokumentiert.

Prüfen Sie /healthz/readiness vor dem Senden von Anfragen. Die produktive URL nutzt /webhook/lizard-postgres-example. Die /webhook-test/-URL gehört zu einer Editor-Testsitzung und ist kein Ersatz für einen veröffentlichten Workflow.

Anfrage senden und Wiederholung testen

Mit der öffentlichen URL und dem Webhook-Key in Umgebungsvariablen:

curl --fail-with-body "$N8N_URL/webhook/lizard-postgres-example" \
  -H 'Content-Type: application/json' \
  -H "X-Example-Key: $EXAMPLE_WEBHOOK_TOKEN" \
  --data '{"requestId":"example-001","message":"hello"}'

Die SQL-Abfrage bindet Request-ID und JSON-Body als Werte. Sie baut kein SQL, indem sie Benutzereingaben in den Abfragetext einbaut. Anführungszeichen und verschachteltes JSON bleiben Daten.

Der Primärschlüssel der Tabelle ist request_id. Bei einem Konflikt gibt die Abfrage die zuerst gespeicherte Zeile zurück. Das Senden derselben ID mit einer anderen Nachricht ändert nicht das originale Payload. Das ist die Wiederholungsrichtlinie dieses Beispiels; wählen Sie eine andere Richtlinie, wenn Ihre Anwendung Updates oder Konfliktfehler benötigt.

Nutzen Sie für jedes distinkte Ereignis eine neue Request-ID. Nutzen Sie keine Test-ID erneut, um ein neues Ereignis darzustellen, und erwarten Sie eine zweite Zeile.

Deployment-Prüfungen

Am 9. September 2026 führten wir n8n 2.38.5 mit Postgres 18.6 in eu-west-lim-a aus. Die gleichen sieben Prüfungen bestanden vor und nach dem Neustart des n8n-Services.

Die Datenbank enthielt nach beiden Läufen ein Ereignis. JSON-Body und Erstellungszeitpunkt stimmten über den Neustart hinweg überein. Der Test-Body enthielt Anführungszeichen und verschachteltes JSON. Der Owner meldete sich auch an und fand den importierten Workflow im Editor.

Lesen Sie den Deployment-Bericht und rohe Ergebnisse. Der Bericht nennt den getesteten Code-Commit. Führen Sie das Prüfskript des Repositorys gegen Ihr eigenes Deployment aus, bevor Sie es für Ihre Workflows nutzen.

Was diese Prüfungen nicht abdecken

Das Beispiel testet keine Last, Uptime, Cold-Start-Latenz oder eine vollständige Monatsrechnung. Es richtet keinen Queue-Modus, keine Datenbank-Backups, keine Datei-Uploads und keine Wiederherstellung nach Datenbankverlust ein.

Eine Service-Neustart-Prüfung stellt fest, dass dieses Deployment seine gespeicherten Workflows und Credentials nach einem Neustart lesen kann. Sie stellt keine Disaster Recovery her. Dafür machen Sie ein Datenbank-Backup, bewahren den Encryption-Key auf, stellen in eine separate Umgebung wieder her und führen den Workflow erneut aus.

Dieser JSON-Workflow benötigt kein persistentes lokales Dateisystem. Workflows, die lokale Dateien lesen oder schreiben, benötigen passenden Speicher und eigene Persistenz-Tests. Prüfen Sie Persistent Volumes und n8ns Speicheranforderungen, bevor Sie diese Arbeitslast hinzufügen.

FAQ

Braucht n8n Postgres? Nein. Selbstgehostetes n8n kann SQLite nutzen. Dieses Beispiel nutzt Postgres, um Workflow-, Credential- und Ausführungsdatensätze außerhalb des Applikationscontainers zu halten und einen datenbank-schreibenden Workflow zu demonstrieren.

Warum funktioniert ein Webhook im Editor, gibt aber anderswo 404 zurück? Prüfen Sie, ob der Workflow veröffentlicht ist und ob der Sender den produktiven /webhook/-Pfad nutzt. Eine CLI-Veröffentlichung erfordert auch, dass der laufende n8n-Prozess neu startet.

Was muss nach einem Redeploy gleich bleiben? Die Datenbankverbindung muss auf die intendierte Datenbank zeigen, und der Encryption-Key muss dessen Credentials noch entschlüsseln können. Halten Sie die öffentliche Webhook-URL und den Authentifizierungsvertrag für Aufrufer stabil.

Ist das ein komplettes produktives n8n-Setup? Es ist ein geprüftes Einzelinstanz-Beispiel. Fügen Sie Backups, Monitoring, Speicher und einen Kapazitätsplan für Ihre Arbeitslast hinzu, bevor Sie darauf für produktive Automatisierung vertrauen.