n8n वेबहुक से Postgres: Lizard पर डिप्लॉयमेंट का एक उदाहरण

n8n वेबहुक एक ही वर्कफ़्लो में JSON को Postgres में लिख सकता है और सेव की गई row वापस कर सकता है। यह उदाहरण Lizard पर n8n चलाता है, हेडर क्रेडेंशियल से वेबहुक को सुरक्षित करता है, और रिक्वेस्ट ID का इस्तेमाल करता है ताकि सेंडर के रीट्राई करने पर डुप्लिकेट row न बनें।

पब्लिक रिपॉज़िटरी में पिन की गई इमेज, वर्कफ़्लो, टेबल डेफ़िनिशन और चेक स्क्रिप्ट शामिल हैं। यह लेख एक n8n इंस्टेंस और JSON रिक्वेस्ट्स को कवर करता है। होस्टिंग के पूरे सेटअप के लिए Lizard पर n8n होस्टिंग से शुरू करें।

उदाहरण में क्या चलता है

n8n सर्विस और उसका डेडिकेटेड Managed Postgres एक ही रीजन में चलते हैं। Postgres में n8n के अपने वर्कफ़्लो और क्रेडेंशियल रिकॉर्ड भी हैं और उदाहरण की webhook_events टेबल भी। एप्लिकेशन एक ही इंस्टेंस पर चलता है; इस उदाहरण में न Redis क्यू है, न अलग वर्कर।

रिपॉज़िटरी n8n 2.38.5 और आधिकारिक इमेज का डाइजेस्ट पिन करती है। फ़िक्स्ड डाइजेस्ट से इमेज का चुनाव रिप्रोड्यूसिबल रहता है। पिन बदलने से पहले n8n की नई रिलीज़ देखें और अपग्रेड टेस्ट करें।

वर्कफ़्लो में तीन नोड हैं:

1. Webhook X-Example-Key हेडर वाली प्रोडक्शन POST रिक्वेस्ट स्वीकार करता है।
2. Store event पैरामीटराइज़्ड Postgres क्वेरी चलाता है।
3. Respond सेव की गई रिक्वेस्ट ID, JSON बॉडी और बनने का समय वापस करता है।

डेटाबेस, ओनर और पब्लिक URL कॉन्फ़िगर करें

उसी Lizard प्रोजेक्ट में रिपॉज़िटरी से एक सर्विस और एक अलग Managed Postgres बनाएँ। रिपॉज़िटरी के निर्देशों में कमांड और एनवायरनमेंट वेरिएबल दिए गए हैं।

DB_TYPE=postgresdb सेट करें और डेटाबेस होस्ट, पोर्ट, नाम, यूज़र और पासवर्ड को ऐडऑन के वेरिएबल से बाइंड करें। n8n के बगल में डेटाबेस का चलना काफ़ी नहीं है: n8n को ये वैल्यू मिलनी चाहिए और उसे सफलतापूर्वक कनेक्ट होना चाहिए। n8n का Postgres कॉन्फ़िगरेशन देखें।

पहली बार स्टार्ट करने से पहले एक अलग N8N_ENCRYPTION_KEY जनरेट करें और उसे संभालकर रखें। n8n इसका इस्तेमाल अपने डेटाबेस में स्टोर किए गए क्रेडेंशियल्स को सुरक्षित रखने के लिए करता है। अगर हर डिप्लॉयमेंट पर नई रैंडम की बनेगी, तो n8n पुराने क्रेडेंशियल्स नहीं पढ़ पाएगा। इस की को रिपॉज़िटरी के बाहर, अपने रिकवरी रिकॉर्ड्स के साथ रखें।

उदाहरण n8n के पहुंच में आने से पहले ही ओनर को भी कॉन्फ़िगर कर देता है। यह n8n के ओनर कॉन्फ़िगरेशन के अनुसार N8N_INSTANCE_OWNER_MANAGED_BY_ENV और bcrypt पासवर्ड हैश का इस्तेमाल करता है। लॉगिन पासवर्ड और वेबहुक की अलग-अलग सीक्रेट हैं।

N8N_HOST को सर्विस के पब्लिक होस्टनेम पर सेट करें, बिना स्कीम या पाथ के। स्टार्ट स्क्रिप्ट उसी होस्टनेम से HTTPS WEBHOOK_URL और एडिटर URL बनाती है। पोर्ट 5678 इस्तेमाल करें। अगर आप Lizard के आगे कोई और प्रॉक्सी जोड़ते हैं, तो प्रॉक्सी-हॉप सेटिंग जांचें।

वर्कफ़्लो इम्पोर्ट और पब्लिश करें

रिपॉज़िटरी की SQL फ़ाइल से webhook_events बनाएँ। Postgres और हेडर क्रेडेंशियल्स को n8n में इम्पोर्ट करें, फिर वर्कफ़्लो इम्पोर्ट करें। क्रेडेंशियल तैयार करने वाली स्क्रिप्ट सर्विस एनवायरनमेंट से सीक्रेट वैल्यू पढ़ती है और एक प्राइवेट, अस्थायी इम्पोर्ट फ़ाइल लिखती है; पब्लिक वर्कफ़्लो में सिर्फ़ क्रेडेंशियल ID और नाम होते हैं।

वर्कफ़्लो पब्लिश करने के लिए n8n एडिटर का इस्तेमाल करें, या n8n publish:workflow --id=lizardPostgresExample चलाएँ। CLI से पब्लिश करने पर डेटाबेस बदलता है; चल रहे n8n प्रोसेस को यह बदलाव पहचानने के लिए रीस्टार्ट करना पड़ता है। यह व्यवहार n8n CLI गाइड में दर्ज है।

रिक्वेस्ट भेजने से पहले /healthz/readiness जांचें। प्रोडक्शन URL /webhook/lizard-postgres-example इस्तेमाल करता है। /webhook-test/ URL एडिटर के टेस्ट सेशन का है और पब्लिश किए गए वर्कफ़्लो की जगह नहीं ले सकता।

रिक्वेस्ट भेजें और रीट्राई टेस्ट करें

पब्लिक URL और वेबहुक की को एनवायरनमेंट वेरिएबल में रखकर:

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"}'

SQL क्वेरी रिक्वेस्ट ID और JSON बॉडी को वैल्यू के रूप में बाइंड करती है। यह यूज़र इनपुट को क्वेरी टेक्स्ट में जोड़कर SQL नहीं बनाती। कोट्स और नेस्टेड JSON डेटा ही बने रहते हैं।

टेबल की प्राइमरी की request_id है। conflict होने पर क्वेरी पहली सेव की गई row लौटाती है। उसी ID के साथ अलग मैसेज भेजने से मूल पेलोड नहीं बदलता। यह इस उदाहरण की रीट्राई नीति है; अगर आपके एप्लिकेशन को अपडेट या conflict एरर चाहिए, तो दूसरी नीति चुनें।

हर अलग इवेंट के लिए नई रिक्वेस्ट ID इस्तेमाल करें। किसी टेस्ट ID को नए इवेंट के लिए दोबारा इस्तेमाल करके दूसरी row की उम्मीद न करें।

डिप्लॉयमेंट जांच

9 सितंबर 2026 को हमने eu-west-lim-a में Postgres 18.6 के साथ n8n 2.38.5 चलाया। n8n सर्विस को रीस्टार्ट करने से पहले और बाद में वही सात जांच पास हुईं।

दोनों रन के बाद डेटाबेस में एक ही इवेंट था। रीस्टार्ट के पहले और बाद JSON बॉडी और बनने का समय एक जैसे थे। टेस्ट बॉडी में कोट्स और नेस्टेड JSON शामिल थे। ओनर ने भी साइन इन किया और एडिटर में इम्पोर्ट किया गया वर्कफ़्लो देखा।

डिप्लॉयमेंट रिकॉर्ड और रॉ नतीजे पढ़ें। रिकॉर्ड में टेस्ट किए गए कोड कमिट का नाम दर्ज है। अपने वर्कफ़्लो के लिए इस्तेमाल करने से पहले रिपॉज़िटरी की चेक स्क्रिप्ट अपने डिप्लॉयमेंट पर चलाएँ।

ये जांच क्या कवर नहीं करतीं

उदाहरण लोड, अपटाइम, कोल्ड-स्टार्ट लेटेंसी या पूरे मासिक बिल को टेस्ट नहीं करता। यह क्यू मोड, डेटाबेस बैकअप, फ़ाइल अपलोड या डेटाबेस खो जाने के बाद रिकवरी सेट नहीं करता।

सर्विस रीस्टार्ट जांच से यह पता चलता है कि यह डिप्लॉयमेंट रीस्टार्ट के बाद अपने सेव किए गए वर्कफ़्लो और क्रेडेंशियल्स पढ़ सकता है। इससे डिज़ास्टर रिकवरी साबित नहीं होती। उसके लिए डेटाबेस बैकअप लें, एन्क्रिप्शन की संभालकर रखें, किसी अलग एनवायरनमेंट में रिस्टोर करें और वर्कफ़्लो फिर से चलाएँ।

इस JSON वर्कफ़्लो को पर्सिस्टेंट लोकल फ़ाइलसिस्टम की ज़रूरत नहीं है। जो वर्कफ़्लो लोकल फ़ाइलें पढ़ते या लिखते हैं, उन्हें उपयुक्त स्टोरेज और अपने अलग पर्सिस्टेंस टेस्ट चाहिए। ऐसा वर्कलोड जोड़ने से पहले Persistent Volumes और n8n की स्टोरेज ज़रूरतें देखें।

आम सवाल

क्या n8n को Postgres की ज़रूरत है? नहीं। सेल्फ़-होस्टेड n8n SQLite इस्तेमाल कर सकता है। यह उदाहरण Postgres इसलिए इस्तेमाल करता है ताकि वर्कफ़्लो, क्रेडेंशियल और एक्ज़ीक्यूशन रिकॉर्ड एप्लिकेशन कंटेनर के बाहर रहें और डेटाबेस में लिखने वाला वर्कफ़्लो दिखाया जा सके।

वेबहुक एडिटर में काम करता है, लेकिन बाकी जगह 404 क्यों लौटाता है? जांचें कि वर्कफ़्लो पब्लिश हुआ है और सेंडर प्रोडक्शन /webhook/ पाथ इस्तेमाल कर रहा है। CLI से पब्लिश करने के बाद चल रहे n8n प्रोसेस को रीस्टार्ट करना भी ज़रूरी है।

रीडिप्लॉय के बाद क्या नहीं बदलना चाहिए? डेटाबेस कनेक्शन सही डेटाबेस की ओर होना चाहिए, और एन्क्रिप्शन की से उसके क्रेडेंशियल्स अब भी डिक्रिप्ट होने चाहिए। कॉल करने वालों के लिए पब्लिक वेबहुक URL और ऑथेंटिकेशन का तरीका स्थिर रखें।

क्या यह n8n का पूरा प्रोडक्शन सेटअप है? यह एक इंस्टेंस वाला, जांचा हुआ उदाहरण है। प्रोडक्शन ऑटोमेशन के लिए इस पर निर्भर होने से पहले अपने वर्कलोड के हिसाब से बैकअप, मॉनिटरिंग, स्टोरेज और क्षमता की योजना जोड़ें।