جایگزین Vercel برای Next.js زمانی انتخاب خوبی است که نیاز واقعی پروژه را پوشش دهد، نه فقط اینکه برنامه روی آن Build شود. دسترسی کاربران ایران، هزینه، دیتابیس، کش، Server Actions، فایل‌های آپلودی و مسیر انتشار باید بررسی شوند. برای بعضی پروژه‌ها ماندن روی Vercel منطقی است؛ برای بعضی دیگر، میزبانی مدیریت‌شده یا کانتینری در ایران انتخاب متناسب‌تری خواهد بود.
این راهنما چک‌لیست تصمیم و مهاجرت است. برای آموزش اجرای اولیه، راهنمای استقرار Next.js در ایران را مطالعه کنید. برای بررسی امکانات و قیمت فعلی مقصد، هاست Next.js و سرور نکست جی اس پاستا نقطه شروع است؛ این مقاله قیمت ثابت یا سازگاری خودکار همه قابلیتهای اختصاصی Vercel را وعده نمی‌دهد.
اول دلیل مهاجرت را قابل اندازه‌گیری کنید
«می‌خواهیم مستقل شویم» هدف کلی است. آن را به معیار تبدیل کنید: کاهش هزینه در بار مشخص، پاسخ سریع‌تر برای کاربران هدف، اجرای Worker مستقل یا پرداخت تومانی. برای هر معیار، وضعیت فعلی و حد قابل قبول را ثبت کنید. اگر هیچ مشکلی قابل اندازه‌گیری نیست، هزینه انتقال و ریسک خطا ممکن است از سود آن بیشتر شود.
محل کاربر و محل وابستگی‌ها را هم جدا ببینید. برنامه‌ای در ایران که برای هر صفحه چند تماس خارجی می‌زند، الزاماً سریع‌تر از قبل نیست. مسیر کاربر تا برنامه، برنامه تا دیتابیس و برنامه تا API مدل، سه مسیر متفاوتاند. هرکدام باید با بار واقعی سنجیده شود.
سه گزینه اصلی را با معیار یکسان مقایسه کنید
| گزینه | مزیت قابل بررسی | مسئولیت یا محدودیت |
|---|---|---|
| پلتفرم تخصصی Next.js مانند Vercel | یکپارچگی انتشار و امکانات اکوسیستم | بررسی قیمت، دسترسی و وابستگی اختصاصی |
| PaaS کانتینری مانند پاستا | اجرای برنامه و سرویس‌های جدا با کنترل منابع | تطبیق کش، شبکه، سلامت و چرخه انتشار |
| VPS خودمدیریت‌شده | کنترل مستقیم سیستم | امنیت، به‌روزرسانی، بکاپ و عملیات بر عهده تیم |
هزینه یک VPS خام را با بسته کامل مدیریت‌شده مقایسه نکنید. زمان عملیات، پایش، بازیابی و نگهداری نیز بخشی از هزینه است. از طرف دیگر، اگر تیم همین زیرساخت و تخصص را دارد، کنترل مستقیم ممکن است ارزشمند باشد. مقایسه هزینه PaaS و VPS برای این بخش مفید است.
فهرست قابلیتهای واقعی پروژه را استخراج کنید
App Router یا Pages Router، SSR، صفحات ثابت، API Route، Server Actions، تصویر بهینه‌شده، Middleware یا Proxy و قابلیتهای Cache را فهرست کنید. نسخه Next.js مهم است؛ راهنمای نسخه قدیمی را بدون تطبیق به پروژه جدید اعمال نکنید. مستندات رسمی Self-Hosting مرجع رفتار اجرای مستقل است.
سپس خدمات خارج از خود Next.js را جدا کنید: ذخیره فایل، دیتابیس، تحلیل رفتار، Cron، صف، ایمیل و قابلیت اختصاصی ارائهدهنده. انتقال کد فرانت‌اند این خدمات را خودکار منتقل نمی‌کند. برای هر وابستگی بنویسید «همان سرویس میماند»، «مقصد جدید دارد» یا «نیازمند بازنویسی است».
Build موفق چه چیزهایی را ثابت نمی‌کند؟
ممکن است صفحه اصلی درست باز شود ولی ورود کاربر، آپلود یا مسیر پویا شکست بخورد. Build همچنین پایداری ارتباط دیتابیس و رفتار تحت بار را ثابت نمی‌کند. آزمون پذیرش باید حداقل یک مسیر عمومی، یک مسیر احراز هویت‌شده و یک عملیات نوشتن مجاز داشته باشد. برای فروشگاه یا پرداخت، سناریوی تکرار درخواست و شکست مقصد نیز لازم است.
فرمان production را آزمایش کنید، نه فقط حالت توسعه. متغیرهای عمومی با پیشوند NEXT_PUBLIC_ ممکن است در زمان Build وارد فایل مرورگر شوند؛ قرار دادن راز در آن‌ها اشتباه است. تغییر مقدار در زمان اجرا نیز الزاماً فایل Buildشده را عوض نمی‌کند. آدرس‌های محیط آزمایشی را پیش از انتشار نهایی بازبینی کنید.