वे वर्कफ़्लो जो अगले रीस्टार्ट तक टिके रहें।

संपादक की सुरक्षा करें

एडिटर को HTTPS और समर्थित प्रमाणीकरण के पीछे रखें। प्रशासनिक पहुँच को सीमित करें और अनावश्यक होने पर सार्वजनिक पंजीकरण से बचें। Webhook रूटों के लिए उनके अपने एक्सपोज़र और प्रमाणीकरण निर्णय आवश्यक हैं।

क्रेडेंशियल कुंजी रखें

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

निष्पादन पथ को सुविचारित रूप से स्केल करें

व्यस्त सेटअप के लिए, समर्थित डेटाबेस, कतार और वर्कर मॉडल की समीक्षा करें। Redis और अलग वर्कर अपनी स्वयं की पहुँच और दृढ़ता आवश्यकताएँ जोड़ते हैं। समवर्ती कार्यों को सीमित करें ताकि एक उछाल VPS या किसी बाहरी API बजट को समाप्त न कर सके।

केवल उपयोगी निष्पादन डेटा रखें

वर्कफ़्लो टोकन, व्यक्तिगत रिकॉर्ड और दस्तावेज़ संभाल सकते हैं। निष्पादन-इतिहास की छँटाई सेट करें, संवेदनशील मानों को रिडैक्ट करें और पुनःप्रयास सावधानी से परिभाषित करें। डुप्लिकेट वेबहुक से अनजाने में दूसरा भुगतान या संदेश नहीं होना चाहिए।

एन्क्रिप्शन कुंजी को डेटाबेस का भाग मानें

सहेजे गए क्रेडेंशियल n8n की एन्क्रिप्शन कुंजी पर निर्भर करते हैं। वह स्टेट डायरेक्टरी सुरक्षित रखें जिसमें स्वतः जनित कुंजी हो, या निजी सीक्रेट स्टोर से N8N_ENCRYPTION_KEY सेट करें। सभी क्यू वर्कर को मुख्य प्रक्रिया जैसी ही कुंजी चाहिए। एक डिस्पोज़ेबल क्रेडेंशियल से पुनर्स्थापन का परीक्षण करें; केवल पुनर्स्थापित डेटाबेस स्वस्थ दिख सकता है जबकि उसके क्रेडेंशियल अपठनीय रहें।

• कुंजी को सार्वजनिक निर्देशिका और रिपॉज़िटरी से बाहर रखें
• डेटाबेस का लगातार बैकअप लें
• इच्छित प्रोडक्शन परिनियोजन के लिए समर्थित PostgreSQL का उपयोग करें

आधिकारिक दस्तावेज़: n8n एन्क्रिप्शन-कुंजी कॉन्फ़िगरेशन

वेबहुक्स को उनका सार्वजनिक पता दें

Caddy जैसा रिवर्स प्रॉक्सी HTTPS को टर्मिनेट कर सकता है जबकि n8n आंतरिक रूप से सुनता है। वर्तमान दस्तावेज़ बाहरी वेबहुक ओरिजिन के लिए N8N_WEBHOOK_URL का उपयोग करते हैं और संस्करण 2.35.0 से पुराने WEBHOOK_URL नाम को प्रतिस्थापित करते हैं। विश्वसनीय प्रॉक्सी-हॉप गणना को वास्तविक पथ पर सेट करें; एकल प्रॉक्सी N8N_PROXY_HOPS=1 का उपयोग करता है। फ़ॉरवर्ड किया गया होस्ट, प्रोटोकॉल और क्लाइंट जानकारी संरक्षित रखें। सर्वर के बाहर से वेबहुक का परीक्षण करें और उसका प्रोडक्शन URL सत्यापित करें।

• वर्कफ़्लो टाइमज़ोन सुविचारित रूप से सेट करें
• संवेदनशील इनपुट वाला निष्पादन इतिहास प्रून करें
• क्यू वर्कर और Redis का उपयोग केवल आवश्यक निजी एक्सेस नियंत्रणों के साथ करें

# Example: one HTTPS reverse proxy
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1

आधिकारिक दस्तावेज़: रिवर्स प्रॉक्सी के पीछे n8n

वर्कलोड और अनुमत एकीकरण परिभाषित करें

ट्रिगर, बाहरी खाते, अपेक्षित निष्पादन मात्रा और प्रत्येक वर्कफ़्लो द्वारा बनाए जा सकने वाले अधिकतम खर्च या दुष्प्रभाव की सूची बनाएँ। वास्तविक उपयोग के लिए n8 लाइसेंस की जाँच करें, विशेष रूप से यदि इसे दूसरों के लिए सेवा के रूप में प्रदान कर रहे हैं। एक छोटे निर्धारित वर्कफ़्लो और एक सार्वजनिक वेबहुक प्रोसेसर की संसाधन आवश्यकताएँ भिन्न होती हैं। एक समर्थित रिलीज़, निजी स्थायी स्थिति, एक TLS नाम और परिनियोजन के अनुरूप डेटाबेस से शुरू करें; एडिटर के साथ डेटाबेस पोर्ट उजागर करने से बचें।

• प्रत्येक एकीकरण के लिए अलग प्रतिबंधित क्रेडेंशियल का उपयोग करें।
• इच्छित वर्कफ़्लो टाइमज़ोन और निष्पादन-इतिहास प्रतिधारण सेट करें।
• निर्यात किए गए वर्कफ़्लो को अंतर्निहित वास्तविक सीक्रेट से मुक्त रखें।

आधिकारिक दस्तावेज़: n8n Docker परिनियोजन

स्थापित रिलीज़ के लिए सार्वजनिक वेबहुक ओरिजिन सेट करें

Caddy जैसा रिवर्स प्रॉक्सी आंतरिक रूप से n8n तक पहुँचता है जबकि बाहरी सेवाएँ इसके HTTPS वेबहुक ओरिजिन को कॉल करती हैं। स्थापित रिलीज़ के लिए प्रलेखित वेबहुक URL वेरिएबल का उपयोग करें; वर्तमान दस्तावेज़ N8N_WEBHOOK_URL नाम देते हैं, जबकि पुरानी रिलीज़ WEBHOOK_URL का उपयोग करती थीं। मनमाने फ़ॉरवर्ड किए गए हेडर पर भरोसा करने के बजाय वास्तविक प्रॉक्सी-हॉप गणना सेट करें। एडिटर एक्सेस नीति को वेबहुक प्रमाणीकरण से अलग रखें, और सत्यापित करें कि प्रोडक्शन कॉलबैक में आंतरिक होस्ट या पोर्ट नहीं है।

# Example values for a supported current release, behind one proxy:
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1

आधिकारिक दस्तावेज़: n8n वेबहुक रिवर्स-प्रॉक्सी सेटिंग्स

लेखन पहुँच देने से पहले एक हानिरहित वर्कफ़्लो का परीक्षण करें

केवल-पढ़ने के अनुरोध या एक अस्थायी परीक्षण रिकॉर्ड से शुरू करें। VPS के बाहर से प्रोडक्शन वेबहुक का परीक्षण करें, प्रमाणीकरण अस्वीकृति और एक जानबूझकर पुनः प्रयास। बार-बार किया गया अनुरोध गलती से दूसरी परिणामकारी कार्रवाई नहीं बनानी चाहिए। लीक हुए इनपुट के लिए निष्पादन लॉग जाँचें, फिर एक प्रतिधारण नीति लागू करें। यदि वेबहुक केवल संपादक के परीक्षण मोड में काम करता है, तो जाँचें कि वर्कफ़्लो प्रकाशित/सक्रिय है या नहीं और क्या प्रोडक्शन और परीक्षण मार्ग सही प्रक्रिया तक पहुँचते हैं।

• रीस्टोर का परीक्षण करने के लिए एक डिस्पोज़ेबल इंटीग्रेशन क्रेडेंशियल का उपयोग करें।
• N8N_ENCRYPTION_KEY या उत्पन्न कुंजी स्थिति की एक स्वतंत्र एन्क्रिप्टेड प्रति रखें।
• नमूना पासवर्ड या API टोकन को बनाए रखे गए डिबगिंग आउटपुट में न भेजें।

आधिकारिक दस्तावेज़: n8n एन्क्रिप्शन कुंजी

निष्पादन अवरोध देखने के बाद ही स्केल करें

कतार मोड Redis, वर्कर और साझा डेटाबेस जोड़ता है; मुख्य प्रक्रिया ट्रिगर प्राप्त करती है जबकि वर्कर निष्पादन करते हैं। प्रत्येक वर्कर को समान क्रेडेंशियल एन्क्रिप्शन कुंजी का उपयोग करना चाहिए। फ़ाइलों वाले वर्कफ़्लो को कतार मोड में ले जाने से पहले वर्तमान बाइनरी-डेटा स्टोरेज आवश्यकताओं का पालन करें। समवर्तीता और अपस्ट्रीम API बजट सीमित करें, और कतार आयु और विफलताओं की निगरानी करें। डेटाबेस, स्थिति और कुंजी एक साथ बैकअप लें; कंटेनर पुनः आरंभ करना अपठनीय सहेजे गए क्रेडेंशियल के लिए रिकवरी योजना नहीं है।

आधिकारिक दस्तावेज़: n8n कतार मोड · निष्पादन प्रूनिंग सेटिंग्स