اپلیکیشن روی لپ‌تاپ شما اجرا می‌شود، ورود کار میکند و اطلاعات از 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 رایگان» در این مرحله کاربرد دارد.