دیپلوی Next.js روی زیرساخت ابری ایران

اپلیکیشن روی لپ‌تاپ شما اجرا می‌شود، ورود کار می‌کند و اطلاعات از API می‌آید؛ حالا باید همین رفتار را روی یک آدرس عمومی تحویل بدهید. در دیپلوی Next.js، بالا آمدن صفحه اصلی کافی نیست. ممکن است صفحه محصول هنگام Build ساخته شود، داشبورد به پردازش روی سرور نیاز داشته باشد و تصویرها از سرویس دیگری بیایند. روی زیرساخت ایران، دسترسی محیط ساخت و اجرا به این وابستگی‌ها را هم بررسی کنید. ابتدا مشخص کنید چه چیزی می‌سازید، چه چیزی را زنده اجرا می‌کنید و داده کجا باقی می‌ماند.

پاسخ سریع: برای دیپلوی Next.js چه میزبانی لازم دارید؟

برای خروجی کاملاً استاتیک، میزبانی فایل کافی است. اگر از SSR، یعنی ساخت پاسخ روی سرور هنگام درخواست، یا قابلیت‌هایی مثل Server Actions استفاده می‌کنید، به محیط اجرای سازگار نیاز دارید. Next.js روی Node.js یا داخل Docker اجرا می‌شود؛ استفاده از Vercel شرط اجرای آن نیست. مستندات استقرار Next.js

پاستا ورودی‌هایی مانند Repository گیت و Dockerfile را می‌پذیرد و وضعیت Build و استقرار را نمایش می‌دهد. ابتدا نسخه production را محلی آزمایش و نیازهای محیطی را مشخص کنید؛ سپس پروژه را وارد پاستا کنید. سازگاری وابستگی‌ها و رفتار اپلیکیشن را در محیط مقصد هم بسنجید.

هاست Next.js را بر اساس رفتار پروژه انتخاب کنید

عبارت «هاست next js» به‌تنهایی نیاز پروژه را مشخص نمی‌کند:

وضعیت پروژه	مسیر مناسب	نکته تصمیم
صفحات قابل تولید هنگام ساخت	خروجی استاتیک	قابلیت‌های نیازمند سرور باید حذف یا جدا شوند
صفحات شخصی، SSR و منطق سمت سرور	اجرای Node.js روی PaaS	تنظیم Build، اجرا و متغیرها ضروری است
وابستگی سیستمی یا محیط اجرای سفارشی	Dockerfile	نگهداری Image و وابستگی‌های آن با شماست
نیاز به کنترل مستقیم سیستم‌عامل	سرور مجازی	نگهداری سیستم، فرایند اجرا و ورودی وب را هم بر عهده می‌گیرید

 

وجود Server Component لزوماً به معنی SSR در هر درخواست نیست؛ بعضی از این کامپوننت‌ها هنگام Build اجرا می‌شوند. خروجی استاتیک از Server Actions و ISR پشتیبانی نمی‌کند. ISR بازسازی صفحه پس از استقرار است. راهنمای خروجی استاتیک

برای پروژه‌ای که عملاً فرانت‌اند استاتیک است، راهنمای «دیپلوی اپلیکیشن React روی ابر ایران؛ راهنمای عملی» را دنبال کنید.

پیش از انتقال، نسخه production را اجرا کنید

تنظیمات ساخت را قابل تکرار کنید

این نمونه برای پروژه‌ای با npm، فایل package-lock.json معتبر و اجرای معمول Node.js است. برای custom server یا خروجی standalone، دستور اجرای همان ساختار را نگه دارید.

در بخش scripts فایل package.json، این دو مقدار را بررسی کنید؛ سایر تنظیمات را حذف نکنید:

{
  "scripts": {

    "build": "next build",

    "start": "next start"
  }
}

دستور npm ci پوشه node_modules موجود را حذف و وابستگی‌ها را دوباره نصب می‌کند. تغییر دستی داخل این پوشه از بین می‌رود؛ فایل‌های سورس و lockfile را بازنویسی نمی‌کند. مستندات npm ci

در ریشه پروژه، دستورها را به‌ترتیب و پس از موفقیت مرحله قبل اجرا کنید:

npm ci
npm run build
npm run start

دستور اول وابستگی‌ها را نصب می‌کند؛ تکرارش نصب را از نو انجام می‌دهد. دستور دوم خروجی production را می‌سازد و با تکرار، آن را بازتولید می‌کند. سومی سرور را اجرا می‌کند؛ پیش از تکرار، فرایند قبلی را متوقف کنید تا پورت اشغال نباشد.

پس از Build موفق، مسیرهای اپلیکیشن را در حالت production آزمایش کنید. اگر فقط محیط توسعه جواب می‌دهد، لاگ Build و مسیر شکست‌خورده را بررسی کنید. next start به Build موفق قبلی نیاز دارد. مرجع CLI نکست

متغیر عمومی را از Secret جدا کنید

متغیری مثل NEXT_PUBLIC_API_URL برای مرورگر است و مقدارش هنگام Build داخل خروجی قرار می‌گیرد. تغییر آن در محیط اجرا، خروجی ساخته‌شده را تغییر نمی‌دهد. رمز دیتابیس و کلید خصوصی نباید این پیشوند را داشته باشند. راهنمای متغیرهای محیطی

نام متغیرها را فهرست کنید و کنار هر کدام بنویسید در Build لازم است یا Runtime، یعنی زمان اجرای برنامه. مقدار محرمانه را از مسیر Secret وارد کنید؛ در Repository، دستور ترمینال یا Prompt ابزار کدنویسی نگذارید.

اگر Build برای دریافت داده به سرویس بیرونی وصل می‌شود، تنظیم متغیر فقط در Runtime کافی نیست.

پروژه را در پاستا از سورس به سرویس برسانید

ورودی و تشخیص پروژه را بررسی کنید

پس از ورود به کنسول پاستا، Repository گیت‌هاب یا گیت‌لب را متصل کنید یا پوشه و ZIP پروژه را بدهید. اگر Dockerfile دارید، همان را به‌عنوان مسیر ساخت بررسی کنید.

پاستا می‌تواند نوع پروژه، Dockerfile یا Compose را تشخیص دهد. نتیجه را پیش از Build با ساختار پروژه تطبیق دهید و در صورت نیاز اصلاح کنید. در monorepo، محل اپلیکیشن و وابستگی‌های مشترک را بررسی کنید.

تنظیمات و هزینه را پیش از ساخت مرور کنید

فرمان ساخت و اجرا، نسخه Node.js، متغیرها و پورت سرویس باید با آزمون محلی هم‌خوان باشند. پورت پیش‌فرض next start برابر 3000 است؛ پورت سرویس را با پورت برنامه تطبیق دهید. تنظیمات next start

پاستا هزینه‌ها و موجودی کیف پول را با تومان نمایش می‌دهد. مبلغ و منابع پلن فعال را همان‌جا بررسی کنید. سرویس ماهانه پیش از ساخت شارژ می‌شود؛ ایجاد منبع PAYG به حداقل موجودی تنظیم‌شده نیاز دارد. هزینه دیتابیس و ذخیره‌سازی احتمالی را هم در نظر بگیرید.

Build و سپس رفتار سرویس را آزمایش کنید

ساخت را شروع کنید و وضعیت و لاگ آن را دنبال کنید. موفقیت Build به معنی سلامت اپلیکیشن نیست.

پس از آماده‌شدن، اپلیکیشن می‌تواند آدرس HTTPS روی دامنه پاستا دریافت کند. صفحه عمومی، ورود، مسیر وابسته به دیتابیس و دریافت تصویر را روی آن امتحان کنید. Health Check، یعنی بررسی خودکار پاسخ‌گویی سرویس، را به مسیری متصل کنید که پاسخ مورد انتظار و بدون اطلاعات حساس بدهد.

پاستا مسیر ساخت، اجرا و مشاهده وضعیت را فراهم می‌کند؛ بررسی منطق برنامه و صحت داده با شماست.

دامنه را پس از آزمون آدرس اولیه متصل کنید

پاستا اتصال دامنه شخصی و HTTPS/TLS را پشتیبانی می‌کند. پس از آزمون سرویس روی آدرس اولیه، رکوردهای دامنه را مطابق مقادیر ارائه‌شده تنظیم کنید. رکورد نامرتبط را حذف نکنید.

گواهی HTTPS، ورود و آدرس بازگشت سرویس احراز هویت را بررسی کنید. راهنمای «اتصال دامنه اختصاصی و فعال‌سازی SSL رایگان» در این مرحله کاربرد دارد.

اجرای SSR در ایران چه محدودیت‌هایی دارد؟

برای ارزیابی SSR ایران، محل سرور را کنار محل دیتابیس و API ببینید. اگر هر درخواست منتظر سرویس خارجی بماند، استقرار داخلی به‌تنهایی مشکل آن وابستگی را حل نمی‌کند. دسترسی را از محیط مقصد آزمایش کنید؛ اتصال لپ‌تاپ شما نماینده اتصال سرور نیست.

Build هم وابستگی شبکه‌ای دارد. برای نمونه، next/font/google فونت را هنگام ساخت دریافت می‌کند. اگر همین مرحله شکست خورد، می‌توانید با رعایت مجوز فونت از فایل محلی و next/font/local استفاده کنید. مستندات فونت Next.js

در اجرای چند نمونه، کش محلی Next.js خودبه‌خود مشترک نیست. دیسک پایدار به‌تنهایی هماهنگی ابطال کش را حل نمی‌کند. Streaming نیز به پشتیبانی تمام مسیر پاسخ نیاز دارد. ملاحظات میزبانی مستقل

پاستا محدودیت دسترسی یک API خارجی یا معماری کش را به‌تنهایی اصلاح نمی‌کند. اگر کنترل مستقیم سیستم‌عامل الزام پروژه است، مسیر PaaS این مقاله مناسب نیست. برای بررسی مهاجرت، راهنمای «جایگزین Vercel و Netlify برای پروژه‌های فرانت‌اند ایرانی» را با تمرکز بر قابلیت‌های مصرف‌شده پروژه دنبال کنید.

وقتی استقرار جواب نمی‌دهد، از کجا شروع کنید؟

نصب وابستگی‌ها متوقف می‌شود

• آنچه کاربر می‌بیند: ساخت پیش از کامپایل متوقف می‌شود.

• علت‌های محتمل و تأییدشده: نبود lockfile یا ناسازگاری آن با package.json از دلایل مستند شکست npm ci است.

• روش تشخیص: اولین خطای نصب و فایل‌های همان نسخه سورس را بررسی کنید.

• اقدام بعدی: lockfile را در محیط توسعه اصلاح کنید؛ پس از مرور تغییرات، ساخت را تکرار کنید.

• آیا داده کاربر در خطر است؟ این خطا به‌خودی‌خود نشانه حذف داده نیست؛ اسکریپت‌های سفارشی پروژه را جداگانه بررسی کنید.

 

Build موفق است، ولی سرویس پاسخ نمی‌دهد

• آنچه کاربر می‌بیند: آدرس اپلیکیشن باز نمی‌شود یا Health Check موفق نیست.

• علت‌های محتمل و تأییدشده: پورت ناهماهنگ، فرمان اجرای نامناسب یا مسیر اشتباه Health Check.

• روش تشخیص: لاگ شروع برنامه، پورت شنونده و مسیر بررسی سلامت را تطبیق دهید.

• اقدام بعدی: تنظیم متفاوت را اصلاح و پاسخ سرویس را دوباره آزمایش کنید.

• آیا داده کاربر در خطر است؟ پاسخ‌ندادن به‌تنهایی نشانه ازدست‌رفتن داده نیست؛ برای رفع آن دیسک یا دیتابیس را حذف نکنید.

 

مرورگر هنوز به API قبلی درخواست می‌فرستد

• آنچه کاربر می‌بیند: با وجود تغییر تنظیمات، مقصد درخواست مرورگر عوض نشده است.

• علت‌های محتمل و تأییدشده: مقدار NEXT_PUBLIC_ ممکن است در Build قبلی تثبیت شده باشد.

• روش تشخیص: مقصد درخواست را در بخش Network مرورگر با مقدار زمان ساخت مقایسه کنید.

• اقدام بعدی: مقدار عمومی صحیح را پیش از Build تنظیم و خروجی تازه را مستقر کنید.

• آیا داده کاربر در خطر است؟ اگر درخواست حاوی داده حساس به مقصد اشتباه می‌رود، قابلیت مربوط را تا اصلاح مقصد متوقف کنید.

 

پیش از تحویل، این موارد را کنترل کنید

• نسخه production، صفحه ورود و مسیر وابسته به دیتابیس را آزموده‌اید.

• مقدارهای NEXT_PUBLIC_ به محیط مقصد اشاره می‌کنند.

• Secret در سورس، خروجی مرورگر یا لاگ دیده نمی‌شود.

• پورت اجرا و مسیر Health Check تطبیق دارند.

• فایل‌های کاربران در ذخیره‌سازی پایدار نگهداری می‌شوند.

• HTTPS و آدرس بازگشت احراز هویت روی دامنه نهایی درست‌اند.

• هزینه منابع انتخابی و شیوه پرداخت را بررسی کرده‌اید.

• پیش از تغییر ساختار دیتابیس، بکاپ قابل بازیابی دارید.

با یک نسخه آزمایشی production شروع کنید

اگر اپلیکیشن به اجرای سمت سرور نیاز دارد و می‌خواهید ساخت، اجرا و وضعیت آن را مدیریت کنید، مسیر PaaS را آزمایش کنید. معیار پذیرش، کارکرد مسیرهای برنامه روی محیط مقصد است.

پروژه Next.js خود را برای شروع استقرار در پاستا آماده کنید و پیش از انتقال دامنه اصلی، آزمون‌های بالا را روی آدرس اولیه انجام دهید.