پیش از انتخاب میزبانی n8n سرورنت، مسئولیت نگهداری، دوره بکاپ، روش بازیابی و دسترسی شما باید در سفارش مشخص باشد. نصب n8n روی سرور مجازی ساعتی اختیار سیستم‌عامل می‌دهد، اما نگهداری برنامه و ذخیره نسخه بیرونی هم به عهده مدیر آن سرور است.
نصب روی VPS و آزمایش HTTPS و webhook
- یک VPS با منابع متناسب با حجم اجرا، دامنه آزمایشی و Docker Compose آماده کنید. نسخه n8n را پیش از ارتقا ثابت و در محیط جدا آزمایش کنید.
- از نمونه رسمی Docker Compose استفاده کنید؛ داده /home/node/.n8n را روی volume پایدار نگه دارید. پورت 5678 فقط روی localhost باشد و reverse proxy گواهی معتبر HTTPS ارائه دهد.
- در مسیر دارای یک پراکسی، متغیرهای زیر و هدرهای X-Forwarded-For، X-Forwarded-Host و X-Forwarded-Proto را تنظیم کنید. شمار proxy hop باید با مسیر واقعی برابر باشد.
- یک workflow با Webhook از نوع POST و پاسخ ثابت {"ok":true} بسازید. ابتدا Test URL را هنگام گوش‌دادن و سپس Production URL را پس از انتشار/فعال‌سازی آزمایش کنید؛ پیام، پرداخت و نوشتن مشتری به این نمونه متصل نکنید.
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
N8N_WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1در n8n پیش از 2.30 به‌جای N8N_WEBHOOK_URL از WEBHOOK_URL استفاده می‌شود. دامنه example را جایگزین کنید؛ HTTPS، پاسخ نمونه و بازیابی بکاپ باید روی نصب خودتان تأیید شوند.
چه چیزهایی باید نگهداری شوند؟
- تعریف ورک‌فلوها و وضعیت فعال بودن آن‌ها.
- اعتبارنامه‌های رمزنگاری‌شده و کلید رمزنگاری متناظر، در محل امن و جدا از مخزن عمومی.
- نسخه n8n، تنظیمات محیط، دامنه وب‌هوک و فهرست افزونه‌های استفاده‌شده.
- دیتابیس و داده باینری موردنیاز، با روش سازگار با نوع دیتابیس؛ خروجی JSON ورک‌فلو به‌تنهایی بکاپ کامل تاریخچه اجرا نیست.
یک نسخه قابل بررسی تهیه کنید
برای دسترسی مدیریتی به محیط self-hosted، CLI رسمی n8n خروجی ورک‌فلو و اعتبارنامه را پشتیبانی می‌کند. دستورها را در محیط نصب‌شده n8n اجرا کنید؛ در Docker باید نام و مسیر واقعی کانتینر و پوشه مقصد را استفاده کنید. این مثال استقرار خودکار سرورنت یا یک دستور ساخت سرویس نیست.
n8n export:workflow --all --output=workflows.json
n8n export:credentials --all --output=credentials.jsonفایل اعتبارنامه را عمومی نکنید و برای بکاپ عادی از خروجی رمزگشایی‌شده استفاده نکنید. بازیابی اعتبارنامه‌های رمزنگاری‌شده به کلید درست وابسته است. فایل‌ها و کلید را در فضای خصوصی خارج از همان ماشین نگه دارید. برای بکاپ دیتابیس در حال کار، روش سازگار و منسجم همان دیتابیس را به‌کار بگیرید؛ کپی دلخواه یک فایل در حال نوشتن قابل اتکا نیست.
انتقال را با یک ورک‌فلو بی‌خطر آزمایش کنید
- نسخه سازگار n8n، داده و کلید لازم را در مقصد آماده کنید؛ مقصد را پیش از انتقال زنده به‌طور عمومی فعال نکنید.
- ابتدا یک ورک‌فلو آزمایشی با Manual Trigger و خروجی ثابت بسازید یا وارد کنید؛ هیچ پیام، پرداخت یا تغییر مشتری به آن متصل نباشد.
- دسترسی به سرویس‌های متصل را با حساب آزمایشی و حداقل سطح دسترسی بررسی کنید. اگر تنظیم OAuth تغییر دامنه می‌خواهد، redirect URI مقصد را هم بازبینی کنید.
- وب‌هوک‌ها و زمان‌بندی‌های واقعی را فقط پس از توقف اجرای هم‌زمان در مبدأ و تعیین زمان انتقال فعال کنید؛ اجرای دو نسخه می‌تواند کار را دوباره انجام دهد.
- پس از پذیرش مقصد، نسخه مبدأ و آخرین بکاپ را تا پایان مهلت بازگشت توافق‌شده حفظ کنید.
معیار پذیرش و خطاهای رایج
وجود فایل بکاپ کافی نیست: تعداد ورک‌فلوها، بازشدن اعتبارنامه‌ها، اجرای نمونه و مسیر وب‌هوک مقصد را بررسی کنید. خطای رمزگشایی می‌تواند از کلید نامنطبق باشد؛ بدون نسخه امن کلید، رمز را تصادفی عوض نکنید. نبود تاریخچه اجرا پس از import ورک‌فلو الزاماً خرابی import نیست؛ این داده جدا از تعریف ورک‌فلو است.
برای سرویس مدیریت‌شده، روش اجرای این مراحل را با دسترسی‌های قراردادی همان سرویس تطبیق دهید. انتقال بدون قطعی، مدت نگهداری بکاپ و بازیابی یک‌کلیکی فقط زمانی قابل اتکا هستند که در سفارش و آزمون پذیرش همان سرویس مشخص شده باشند. این راهنما انتقال یک سرویس واقعی مشتری را اجرا نکرده است.
آزمون نمونه بازیابی
در ۲۵ اکتبر ۲۰۲۶، روی n8n 2.30.0 با دو محیط SQLite جداگانه و داده ساختگی، اجرای ورک‌فلو، export و import ورک‌فلو و اعتبارنامه رمز‌شده، اجرای مجدد در مقصد و رمزگشایی با کلید اصلی بررسی شد. کلید اشتباه پذیرفته نشد. این آزمون، مهاجرت مشتری، بکاپ کامل دیتابیس، Docker، HTTPS یا مسیر وب‌هوک سرویس شما را تأیید نمی‌کند.
مراجع: CLI رسمی n8n و کلید رمزنگاری.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!