پیکربندی سرور Next.js و پروژهی اختصاصی
سروری که برای پروژهی خودتان ساخته میشود. Next.js، Node.js، یا هر زبان دیگر.
پروژهی اختصاصی دارید، با Next.js یا هر زبان دیگری. ما سرور مجازی یا اختصاصی شما را برایش پیکربندی می‌کنیم تا پروژه را روی آن بالا بیاورید: امن، سریع، و آماده‌ی هر نسخهی تازه.
- ۱۵ میلیون تومان یک بار
- روی سرور خودتان، بی هزینهی ماهانه به ما
هاست نمی‌خواهید؛ سرور می‌خواهید.
هاست اشتراکی بیشتر برای سایتهای PHP ساخته شده؛ هر درخواست می‌آید، جوابش داده میشود و تمام. ولی پروژهای مثل Next.js یا Node.js باید همیشه روشن بماند، نسخهی خودش را داشته باشد، و گاهی دیتابیس و کش خودش را.
مثلا فرض کنید یک فروشگاه با Next.js دارید. روی هاست اشتراکی یا اصلا اجرا نمیشود، یا با محدودیت‌هایی که دست‌تان را می‌بندد. روی سرور خودتان همهچیز همان‌طور است که پروژه لازم دارد.
به هر زبانی. سرور را از روی پروژه میسازیم، نه پروژه را از روی سرور.
- Next.js
- Node.js
- React
- Nuxt
- Laravel
- Django
- FastAPI
- Go
- .NET
- Java
- Ruby on Rails
- و هر زبان دیگر
روی سرور شما چه ساخته میشود؟ ۹ کار، به زبان ساده.
- هر بخش در محفظه‌ی خودشپروژه، دیتابیس و کش هر کدام در یک محفظه‌ی Docker جدا؛ اگر یکی گیر کرد، بقیه کار می‌کنند.
- Nginx جلوی پروژهدرخواست‌ها را می‌گیرد، فایل‌های ثابت را خودش می‌دهد و فقط بقیه را به پروژه می‌رساند.
- گواهی SSL خودکارصدور و تمدید خودکار؛ هیچ‌وقت منقضی نمیشود.
- دیوار آتش و درگاه‌های بستهفقط درگاه‌هایی باز است که لازم است؛ ورود به سرور فقط با کلید.
- دیتابیس و کشPostgreSQL، MySQL یا Redis، هر کدام که پروژه لازم دارد، با حافظه‌ی خودش.
- روشن ماندناگر پروژه به هر دلیلی بسته شد، خودش دوباره روشن میشود.
- راه انتشاریک راه ساده و ثابت برای بالا آوردن نسخهی تازه، بی اینکه سایت پایین بیاید.
- پشتیبان‌گیریاز دیتابیس و فایل‌های مهم، با نگه داشتن چند نسخه.
- مستند و دسترسی کاملهمه‌ی رمزها، ساختار و تنظیم‌ها را مکتوب تحویل میگیرید؛ سرور مال شماست.
همین سایت، همین‌طور کار می‌کند.
team.sefid.dev با Next.js ساخته شده و روی سروری کار می‌کند که خودمان، به همین روش، پیکربندی کرده‌ایم: هر بخش در محفظه‌ی Docker خودش، Nginx جلویش، و گواهی‌هایی که خودشان تمدید می‌شوند. سرور شما را هم همین‌طور میسازیم.
از درخواست تا پرتاب.
- شروع یک پروژهمی‌نویسید پروژه با چه زبانی است و چه چیزهایی لازم دارد.
- گفتگومی‌پرسیم پروژه چطور ساخته و اجرا میشود؛ اگر سرور ندارید، میگوییم کدام کافی است.
- دسترسیبعد از تایید پروژه، دسترسی سرور را در پنل خودتان وارد می‌کنید.
- پیکربندیسرور ساخته و تست میشود؛ اگر بخواهید، نسخهی اول پروژه را هم رویش بالا می‌آوریم.
- تحویلمستند، رمزها و راه انتشار نسخهی تازه، دست شما.
سوال‌هایی که می‌پرسند.
- هزینهی پیکربندی سرور برای پروژهی اختصاصی چقدر است؟
- ۱۵ میلیون تومان، یک بار. هزینهی ماهانهی خود سرور را مستقیم به دیتاسنتری میدهید که از آن خریدهاید؛ به ما هزینهی ماهانهای نمیدهید.
- پروژهی من با Next.js نیست؛ باز هم میشود؟
- بله. Node.js، Laravel، Django، Go، .NET یا هر زبان دیگری؛ سرور را از روی همان پروژه میسازیم.
- هاست Node.js یا هاست Next.js نخرم؟
- هاست اشتراکی بیشتر برای سایتهای PHP ساخته شده. پروژهای مثل Next.js یا Node.js باید همیشه روشن بماند، نسخهی خودش را داشته باشد و گاهی دیتابیس و کش خودش را؛ اینها روی سرور مجازی یا اختصاصی خودتان درست درمیآیند.
- سرور را شما میفروشید؟
- نه. سرور را خودتان، به نام خودتان، از هر دیتاسنتری که بخواهید میخرید. اگر نمیدانید کدام، پیش از خرید میگوییم چه سروری برای پروژهی شما کافی است.
- بعدا خودم میتوانم نسخهی تازه را بالا بیاورم؟
- بله. راه انتشار را طوری میسازیم که شما یا برنامهنویستان هر بار با یک کار ساده نسخهی تازه را بالا بیاورید، و همهچیز را مکتوب تحویل میدهیم.
- دسترسی سرور را کی و چطور میگیرید؟
- فقط بعد از اینکه پروژه تایید شد، و فقط از داخل پنل خودتان. رمزنگاریشده نگه داشته میشود و حتی به خود شما هم دوباره نشان داده نمیشود (قوانین).
پروژه را بنویسید؛ سکویش را میسازیم.
- ۱۵ میلیون تومان یک بار، و بعد هیچ پرداخت ماهانهای به ما.
- سرور، دامنه و همه‌ی رمزها به نام و در دست خودتان.
- دسترسی سرور فقط بعد از تایید پروژه، در پنل خودتان و رمزنگاریشده.
- گفتگوی اول برای فهمیدن کار رایگان است.
بیشتر
اجرای Next.js و پروژهی Node روی سرور خودتان؛ چرا هاست کافی نیست و سرور چه می‌خواهد
وقتی یک پروژه با Next.js، Node، پایتون یا هر زبان دیگری ساخته شد، سوال بعدی این است که کجا و چطور اجرا شود. خیلی‌ها اول سراغ هاست می‌روند و به‌زودی می‌بینند پروژه یا اصلا بالا نمی‌آید، یا بعد از چند دقیقه می‌خوابد، یا کند است. دلیلش ساده است؛ هاست اشتراکی برای سایتهای PHP ساخته شده، نه برای برنامه‌هایی که باید دائم روشن باشند. در این نوشته ساده میگوییم این پروژه‌ها چه چیزهایی از سرور می‌خواهند، چرا هاست کافی نیست، پلتفرم‌های آماده چه مزیت و هزینه‌ای دارند، و یک سرور درست‌پیکربندی‌شده برای چنین پروژهای شامل چه چیزهایی است.
فرق PHP با Node و بقیه
در PHP، که وردپرس با آن ساخته شده، هر درخواست یک اجرای کوتاه است؛ وب‌سرور درخواست را می‌گیرد، کد PHP از اول اجرا میشود، صفحه را می‌سازد و تمام میشود. برای همین هاست اشتراکی می‌تواند هزاران سایت PHP را روی یک سرور نگه دارد؛ هیچ‌کدام وقتی بازدیدکننده ندارند، چیزی مصرف نمی‌کنند.
برنامه‌های Node، از جمله Next.js، و بیشتر برنامه‌های پایتون، Go، جاوا و دات‌نت، این‌طور کار نمی‌کنند. برنامه یک بار روشن میشود و دائم روشن می‌ماند؛ روی یک درگاه گوش می‌دهد، چیزهایی را در حافظه نگه می‌دارد، و هر درخواست را در همان برنامه‌ی روشن جواب می‌دهد. این روش سریع است، چون لازم نیست برای هر درخواست همهچیز از اول بار شود. ولی یعنی برنامه همیشه حافظه می‌گیرد، و یک چیزی باید مراقب باشد که اگر برنامه افتاد، دوباره روشنش کند.
یک مثال روزمره: PHP مثل تاکسی تلفنی است؛ هر بار زنگ می‌زنید، یک ماشین می‌آید و می‌برد و می‌رود. Node مثل راننده‌ی شخصی است که دم در منتظر نشسته؛ هر وقت بخواهید، همان لحظه راه می‌افتد، ولی باید جایی برای نشستن و ماندن داشته باشد.
چرا هاست اشتراکی جواب نمی‌دهد؟
هاست اشتراکی جایی برای ماندن یک برنامه‌ی دائمی ندارد. بعضی پنل‌ها افزونه‌ای دارند که برنامه‌ی Node یا پایتون را اجرا می‌کند، ولی در همان محدودیت‌های حساب؛ حافظه‌ی کم، تعداد پردازش محدود، و گاهی خاموش کردن برنامه بعد از مدتی بی‌کاری. برنامه‌ای که خاموش شده، برای اولین درخواست بعدی باید دوباره روشن شود، و این چند ثانیه طول می‌کشد.
مشکل دوم، ساختن پروژه است. پروژهی Next.js پیش از اجرا باید «ساخته» شود؛ کد به فایل‌های نهایی تبدیل میشود، صفحه‌های ثابت از پیش ساخته می‌شوند، و فایل‌ها کوچک و بسته‌بندی می‌شوند. این کار حافظه و پردازنده‌ی زیادی می‌خواهد، گاهی چند گیگابایت حافظه، که روی هاست اشتراکی یا نیست یا وسط کار تمام میشود.
مشکل سوم، ابزارها. پروژه‌های امروزی معمولا کنار خود برنامه، چیزهای دیگری هم لازم دارند؛ یک دیتابیس مثل PostgreSQL، یک ردیس برای کش و صف، یک برنامه‌ی جدا برای کارهای پس‌زمینه، و گاهی Docker. هیچ‌کدام روی هاست اشتراکی ممکن نیست.
پلتفرم‌های آماده
راه دیگر، پلتفرم‌هایی است که کد را از مخزن می‌گیرند، خودشان می‌سازند و اجرا می‌کنند. برای شروع، خیلی راحت‌اند؛ چند کلیک و پروژه روی اینترنت است. بعضی‌هایشان حتی برای پروژه‌های کوچک رایگان‌اند.
ولی چند هزینه دارند که کم‌کم پیدا می‌شوند. قیمتشان معمولا بر اساس مصرف است؛ تعداد درخواست، زمان اجرا، ترافیک و تعداد اعضای تیم. با بزرگ شدن پروژه، صورت‌حساب ماهانه می‌تواند خیلی سریع از قیمت یک سرور خوب بیشتر شود. بعضی امکاناتشان مخصوص خودشان است، و هر چه بیشتر از آن‌ها استفاده کنید، رفتن به جای دیگر سخت‌تر میشود. پرداخت با ارز است. و سرورهایشان معمولا بیرون از ایران‌اند؛ برای مخاطب داخلی، یعنی فاصله‌ی بیشتر و وابستگی به اینترنت بین‌الملل.
سرور خودتان چه چیزهایی لازم دارد؟
روی یک سرور مجازی یا اختصاصی، همهچیز دست شماست؛ ولی همهچیز را هم باید درست چید. یک پروژهی Next.js یا Node روی سرور خودش، اینها را لازم دارد.
اول، محیط اجرا؛ نسخهی درست Node یا Bun یا پایتون، همان نسخه‌ای که پروژه با آن ساخته و آزمایش شده. دوم، یک «نگهبان پردازش» که برنامه را موقع روشن شدن سرور اجرا کند، اگر افتاد دوباره روشنش کند، و گزارش‌هایش را نگه دارد. سوم، یک وب‌سرور جلوی برنامه، که به آن «پراکسی معکوس» می‌گویند؛ درخواست‌ها را از اینترنت می‌گیرد، HTTPS را انجام می‌دهد، فایل‌های ثابت را خودش می‌فرستد و فقط بقیه را به برنامه می‌دهد. چهارم، گواهی HTTPS با تمدید خودکار. و پنجم، دیوار آتش که فقط درگاه‌های وب را باز می‌گذارد و درگاه خود برنامه را از اینترنت می‌بندد.
پراکسی معکوس، چرا لازم است؟
برنامه‌ی Node خودش می‌تواند مستقیم روی اینترنت جواب بدهد، ولی این کار درستی نیست. وب‌سرورهایی که جلوی برنامه می‌نشینند، برای این کار ساخته شده‌اند؛ هزاران اتصال هم‌زمان را با حافظه‌ی کم نگه می‌دارند، HTTPS و HTTP/2 و HTTP/3 را انجام می‌دهند، فایل‌های فشرده می‌فرستند، و جلوی درخواست‌های بدشکل یا خیلی بزرگ را پیش از رسیدن به برنامه می‌گیرند.
یک فایده‌ی دیگر هم دارند؛ اگر برنامه برای چند ثانیه در حال به‌روزرسانی باشد، پراکسی می‌تواند درخواست‌ها را نگه دارد یا یک صفحه‌ی موقت نشان دهد، به‌جای خطای اتصال. و اگر پروژه چند برنامه دارد، مثلا سایت و پنل و API، یک پراکسی همه را پشت یک دامنه یا چند زیردامنه می‌چیند.
کش در Next.js
Next.js چند لایه کش دارد. صفحه‌هایی که از پیش ساخته شده‌اند، به شکل فایل آماده‌اند. صفحه‌هایی که هر چند وقت یک بار از نو ساخته می‌شوند، نسخهی آخرشان روی دیسک یا در حافظه نگه داشته میشود. و جواب‌هایی که برنامه از منبع‌های دیگر می‌گیرد، می‌تواند کش شود. روی پلتفرم‌های آماده، این کش‌ها را خود پلتفرم مدیریت می‌کند؛ روی سرور خودتان، باید مطمئن شوید جایشان درست است و با هر به‌روزرسانی، کش کهنه پاک یا درست جایگزین میشود.
کنار کش خود Next.js، پراکسی هم می‌تواند فایل‌های ثابت، مثل جاوااسکریپت و CSS و عکس‌ها، را با سرآیندهای درست بفرستد تا مرورگر و CDN یک سال نگهشان دارند. Next.js اسم این فایل‌ها را با هر ساخت عوض می‌کند، پس نگه داشتن طولانی‌شان خطری ندارد؛ نسخهی تازه اسم تازه دارد.
عکس‌ها
Next.js یک ابزار بهینه‌سازی عکس دارد که عکس را به اندازه‌ی درست و به فرمت سبک‌تر، مثل WebP یا AVIF، تبدیل می‌کند و نسخهی تبدیل‌شده را نگه می‌دارد. این ابزار روی سرور، پردازنده و حافظه می‌گیرد، مخصوصا وقتی برای اولین بار هر عکس را تبدیل می‌کند. روی سرور خودتان، باید کتابخانه‌ی پردازش عکس نصب باشد و جای نگه داشتن عکس‌های تبدیل‌شده روی دیسکی باشد که با هر به‌روزرسانی پاک نشود. فرق WebP و AVIF و اینکه چقدر سبک‌ترند، در درس WebP آمده است.
ساختن پروژه کجا؟
همان‌طور که گفتیم، ساختن پروژه حافظه‌ی زیادی می‌خواهد؛ خیلی بیشتر از اجرایش. اگر روی همان سروری که سایت را اجرا می‌کند ساخته شود، در زمان ساخت، سایت کند میشود و اگر حافظه تمام شود، ممکن است برنامه‌ی در حال اجرا هم بیفتد.
دو راه درست هست. یکی ساختن پروژه در جای دیگر، مثلا روی کامپیوتر برنامه‌نویس یا یک سرویس ساخت خودکار، و فرستادن نتیجه‌ی ساخته‌شده به سرور. دیگری ساختن روی سرور، ولی با حافظه‌ی کافی و با محدود کردن منابع ساخت، تا برنامه‌ی در حال اجرا آسیب نبیند. Next.js یک حالت خروجی «مستقل» هم دارد که فقط فایل‌هایی را که برای اجرا لازم است کنار هم می‌گذارد؛ نتیجه خیلی کوچک‌تر است و فرستادنش به سرور سریع.
Docker
Docker یعنی بسته‌بندی برنامه با همه‌ی چیزهایی که لازم دارد، در یک «ظرف»، که روی هر سروری عینا یک‌جور اجرا میشود. مزیتش این است که «روی کامپیوتر من کار می‌کرد» دیگر بهانه نیست؛ همان ظرف روی سرور هم کار می‌کند. چند برنامه‌ی یک پروژه، مثل خود سایت، دیتابیس و ردیس، هر کدام در ظرف خودشان، کنار هم اجرا می‌شوند.
Docker برای پروژه‌هایی با چند بخش، یا تیم‌هایی که چند محیط دارند، عالی است. برای یک پروژهی ساده‌ی Next.js، اجرا مستقیم روی سیستم‌عامل با یک نگهبان پردازش، ساده‌تر و کمی سبک‌تر است. در پیکربندی، بسته به پروژه، یکی از این دو را انتخاب می‌کنیم.
به‌روزرسانی بی قطعی
یکی از سخت‌ترین چیزها روی سرور خودتان، به‌روزرسانی است. اگر برنامه را خاموش کنید، نسخهی تازه را بگذارید و روشن کنید، چند ثانیه تا چند ده ثانیه سایت در دسترس نیست. برای سایتی که هر روز چند بار به‌روز میشود، این قابل قبول نیست.
راه درست این است که نسخهی تازه کنار نسخهی قبلی روشن شود، روی درگاه دیگری؛ وقتی کاملا آماده شد و به درخواست آزمایشی درست جواب داد، پراکسی درخواست‌های تازه را به آن بفرستد، و نسخهی قبلی بعد از تمام کردن درخواست‌هایی که دستش است، خاموش شود. کاربر هیچ قطعی‌ای نمی‌بیند. و اگر نسخهی تازه مشکل داشت، برگشتن به نسخهی قبلی چند ثانیه است.
دیتابیس و ردیس
بیشتر پروژه‌های اختصاصی یک دیتابیس دارند؛ معمولا PostgreSQL یا MySQL. روی سرور خودتان، دیتابیس باید فقط روی خود سرور یا شبکه‌ی خصوصی گوش بدهد، با کاربر و رمز جدا برای برنامه، حافظه‌ی کافی، و پشتیبان روزانه در جایی جدا. تغییر ساختار دیتابیس با هر نسخهی تازه هم باید با دقت انجام شود؛ تغییری که نسخهی قبلی برنامه را خراب کند، به‌روزرسانی بی قطعی را هم خراب می‌کند.
ردیس برای خیلی از پروژه‌ها لازم است؛ برای کش، نشست کاربرها، صف کارها و شمارنده‌ها. همه‌ی جزئیاتش را در درس ردیس گفته‌ایم. روی سرور، ردیس باید سقف حافظه داشته باشد، فقط روی خود سرور گوش بدهد و رمز داشته باشد.
کارهای پس‌زمینه
پروژه‌ها معمولا کارهایی دارند که نباید کاربر منتظرشان بماند؛ فرستادن ایمیل و پیامک، ساختن گزارش، پردازش فایل آپلودی، یا گرفتن داده از یک سرویس دیگر. این کارها در یک صف می‌روند و یک برنامه‌ی جدا، یکی‌یکی انجامشان می‌دهد. این برنامه هم یک نگهبان پردازش لازم دارد، و اگر کاری شکست خورد، باید دوباره امتحان شود. کارهای زمان‌بندی‌شده، مثل پاک کردن داده‌ی قدیمی هر شب، هم کنار همین تنظیم می‌شوند.
متغیرهای محیطی و رمزها
هر پروژه چند رمز و کلید دارد؛ رمز دیتابیس، کلید درگاه پرداخت، کلید سرویس پیامک. اینها نباید در کد یا مخزن باشند. روی سرور، در فایل‌هایی جدا با دسترسی محدود، یا در ابزار مدیریت رمز، نگه داشته می‌شوند و فقط موقع اجرا به برنامه داده می‌شوند. اگر روزی یک رمز لو رفت، فقط آن رمز عوض میشود، بی دست زدن به کد.
گزارش‌ها و نظارت
برنامه‌ی دائمی گزارش می‌نویسد؛ هر درخواست، هر خطا. این گزارش‌ها باید نگه داشته شوند تا وقتی مشکلی پیش آمد، بشود دید چه شده، و باید مرتب فشرده و پاک شوند تا دیسک پر نشود. کنارش، یک نظارت ساده لازم است که اگر سایت از دسترس خارج شد، حافظه یا دیسک رو به پر شدن رفت، یا خطاها ناگهان زیاد شدند، همان لحظه خبر بدهد؛ پیش از آنکه کاربرها خبر بدهند.
اگر پروژه کاملا ثابت است
همه‌ی پروژه‌های Next.js برنامه‌ی دائمی لازم ندارند. اگر سایت هیچ بخشی ندارد که برای هر کاربر جدا ساخته شود، مثلا یک سایت معرفی یا مستندات، Next.js می‌تواند کل سایت را به فایل‌های ثابت HTML و CSS و جاوااسکریپت تبدیل کند. این فایل‌ها را فقط یک وب‌سرور می‌فرستد، بی هیچ برنامه‌ی Node روشن؛ سریع‌ترین، ارزان‌ترین و امن‌ترین حالت ممکن.
پیش از هر تصمیمی، این را بپرسید؛ پروژه واقعا به سرور Node نیاز دارد یا نه. اگر فقط چند بخش کوچک پویا دارد، مثل یک فرم تماس، گاهی بهتر است بقیه ثابت شود و فقط همان بخش یک سرویس کوچک جدا داشته باشد.
اتصال‌های بلند
بعضی پروژه‌ها اتصال‌های بلند دارند؛ گفت‌وگوی زنده، اعلان‌های لحظه‌ای، یا جواب‌هایی که تکه‌تکه فرستاده می‌شوند، مثل جواب‌های هوش مصنوعی که کلمه به کلمه نشان داده می‌شوند. این اتصال‌ها، برخلاف درخواست‌های معمولی، چند ثانیه تا چند ساعت باز می‌مانند.
پراکسی معکوس به‌طور پیش‌فرض اتصال‌هایی را که مدتی ساکت‌اند می‌بندد، و جواب‌ها را پیش از فرستادن جمع می‌کند. برای اتصال‌های بلند، این دو رفتار باید برای همان مسیرها عوض شوند؛ وگرنه گفت‌وگوی زنده هر دقیقه قطع میشود و جواب تکه‌تکه، یک‌جا در آخر می‌رسد. روی پلتفرم‌های آماده، این اتصال‌ها گاهی محدودیت زمانی سفت دارند؛ روی سرور خودتان، هر طور که پروژه لازم دارد تنظیم می‌شوند.
فایل‌هایی که کاربرها می‌فرستند
اگر کاربرها فایل آپلود می‌کنند، مثل عکس پروفایل یا مدرک، این فایل‌ها نباید کنار کد برنامه نگه داشته شوند. با هر به‌روزرسانی، پوشه‌ی برنامه عوض میشود، و فایل‌هایی که آنجا بودند می‌توانند گم شوند. جای درست، یک پوشه‌ی جدا بیرون از برنامه یا یک انبار فایل است، که در پشتیبان روزانه هم هست.
فایل آپلودی یکی از رایج‌ترین راه‌های حمله هم هست. فایلی که اسمش عکس است ولی در واقع یک برنامه است، اگر جایی نگه داشته شود که وب‌سرور اجرایش کند، کل سرور را در اختیار حمله‌کننده می‌گذارد. پس پوشه‌ی آپلود نباید هیچ چیزی را اجرا کند، نوع فایل باید از روی محتوا سنجیده شود نه از روی اسم، و بهترین کار برای عکس‌ها، ساختن دوباره‌ی عکس روی سرور است، تا هر چیز پنهانی داخل فایل از بین برود.
امنیت جلوی برنامه
پراکسی معکوس جای خوبی برای چند لایه‌ی امنیت است، پیش از آنکه درخواست به برنامه برسد. محدود کردن تعداد درخواست از هر آدرس برای مسیرهای حساس، مثل ورود و فرم‌ها، تا کسی نتواند هزاران رمز را امتحان کند. سرآیندهای امنیتی، مثل HSTS که مرورگر را مجبور به HTTPS می‌کند، و سرآیندهایی که جلوی بار شدن سایت در قاب سایتهای دیگر را می‌گیرند. و بستن مسیرهایی که نباید از بیرون دیده شوند، مثل پنل‌های مدیریت داخلی، یا باز گذاشتنشان فقط برای آدرس‌های مشخص.
نسخهی تست
هر پروژهی جدی یک نسخهی تست لازم دارد؛ کپی پروژه روی یک زیردامنه‌ی جدا، با دیتابیس جدا، که هر نسخهی تازه اول آنجا امتحان شود. روی سرور خودتان، نسخهی تست می‌تواند روی همان سرور باشد، با منابع محدود تا روی سایت اصلی اثر نگذارد، و بسته روی موتورهای جستجو و بیرونی‌ها.
ساخت و فرستادن خودکار
بهترین حالت این است که هر بار برنامه‌نویس کد تازه‌ای را در مخزن ثبت کرد، یک فرایند خودکار پروژه را بسازد، آزمایش‌ها را اجرا کند، و اگر همه سبز بود، نسخهی تازه را با روش بی قطعی روی سرور بفرستد؛ اول روی نسخهی تست، و بعد از تایید، روی سایت اصلی. این‌طور هیچ‌کس لازم نیست برای به‌روزرسانی وارد سرور شود، و هر نسخه‌ای که روی سایت است، همان است که آزمایش‌ها را گذرانده. در پیکربندی، اگر تیم شما چنین فرایندی دارد، به سرور وصلش می‌کنیم؛ اگر ندارد، یک راه ساده‌ی یک‌دستوری برای فرستادن نسخهی تازه تحویل میدهیم.
چند پروژه روی یک سرور
اگر چند پروژهی کوچک دارید، مثلا یک سایت، یک پنل و یک API، لازم نیست برای هر کدام یک سرور بخرید. روی یک سرور، هر پروژه برنامه‌ی خودش را روی درگاه خودش اجرا می‌کند، و پراکسی معکوس هر دامنه یا زیردامنه را به برنامه‌ی درست می‌فرستد. مهم این است که هر پروژه کاربر سیستم‌عامل خودش، دیتابیس و رمزهای خودش را داشته باشد، تا اگر یکی مشکل امنیتی پیدا کرد، به بقیه نرسد، و هر کدام سقف حافظه‌ی خودش را داشته باشد، تا یکی با نشت حافظه بقیه را نخواباند.
نشت حافظه
برنامه‌های دائمی یک مشکل دارند که برنامه‌های PHP ندارند؛ نشت حافظه. اگر کد جایی چیزی را در حافظه نگه دارد و هیچ‌وقت رها نکند، حافظه‌ی برنامه روز به روز بیشتر میشود، تا جایی که سرور کم بیاورد و سیستم‌عامل برنامه را به زور ببندد. درمان واقعی، پیدا کردن و درست کردن آن تکه کد است. ولی تا آن موقع، نگهبان پردازش می‌تواند یک سقف حافظه برای برنامه بگذارد و اگر از آن گذشت، برنامه را با آرامش دوباره روشن کند، و نظارت، رشد حافظه را نشان دهد تا برنامه‌نویس بداند دنبال چه بگردد.
پایتون، Go، PHP و بقیه
همه‌ی اینها برای زبان‌های دیگر هم صدق می‌کند، با کمی تفاوت. پروژهی پایتون، مثل جنگو یا یک API با FastAPI، یک سرور برنامه‌ی پایتون جلوی خودش لازم دارد که چند کارگر را مدیریت کند، و پشتش همان پراکسی و HTTPS و نگهبان پردازش. برنامه‌ی Go یک فایل اجرایی است و ساده‌تر از همه اجرا میشود. پروژه‌های PHP غیر وردپرسی، مثل لاراول، همان PHP و وب‌سرور را می‌خواهند، به اضافه‌ی صف و کارهای زمان‌بندی‌شده. پروژه‌های جاوا و دات‌نت هم حافظه‌ی بیشتری می‌گیرند ولی همان چیدمان را دارند.
پس «هاست پایتون»، «هاست جنگو» یا «هاست node js» در اصل یک سوال‌اند؛ سروری که بتواند یک برنامه‌ی دائمی را درست و امن اجرا کند.
سرور ایران یا خارج؟
برای پروژهای که کاربرانش در ایران‌اند و با درگاه پرداخت و پیامک داخلی کار می‌کند، سرور داخلی معمولا بهتر است؛ فاصله کمتر، و ارتباط با سرویس‌های داخلی راحت‌تر. ولی یک نکته دارد؛ نصب بسته‌ها، که برنامه‌های Node و پایتون از مخزن‌های بین‌المللی می‌گیرند، روی سرور داخلی ممکن است کند یا گاهی غیرممکن باشد. راه درست، ساختن پروژه در جایی است که به مخزن‌ها دسترسی خوب دارد، و فرستادن نتیجه‌ی آماده، یا یک ظرف Docker کامل، به سرور. این‌طور سرور برای اجرا به هیچ مخزن خارجی وابسته نیست. جزئیات انتخاب جای سرور در صفحه‌ی هاست ایران آمده است.
اندازه‌ی سرور
یک پروژهی Next.js معمولی، با چند صد کاربر هم‌زمان، روی یک سرور مجازی با ۲ هسته و ۴ گیگابایت حافظه خوب اجرا میشود، به شرطی که ساخت پروژه روی همان سرور انجام نشود یا حافظه‌ی ساخت محدود باشد. اگر دیتابیس و ردیس هم روی همان سرورند، ۸ گیگابایت جای راحت‌تری است. اندازه‌ی واقعی را مصرف واقعی تعیین می‌کند؛ با یک سرور متوسط شروع کنید و وقتی عددها گفتند، بزرگش کنید.
بعد از تحویل، کار با سرور
بعد از پیکربندی، تیم شما لازم نیست سرور را بشناسد تا با آن کار کند. نسخهی تازه با یک دستور یا با فرایند خودکار فرستاده میشود، گزارش‌ها در یک جا دیده می‌شوند، و پشتیبان خودکار است. گزارش PDF پایان کار، همه‌ی چیزهایی را که روی سرور هست می‌گوید؛ کدام برنامه کجاست، چطور روشن و خاموش میشود، رمزها کجا نگه داشته شده‌اند، و اگر لازم شد، چطور یک نسخهی قبلی برگردانده میشود. هر برنامه‌نویسی که بعدا به تیم اضافه شود، با همین گزارش راه می‌افتد.
پیکربندی سرور پروژهی اختصاصی
پیکربندی سرور Next.js و پروژهی اختصاصی ما، سرور مجازی یا اختصاصی شما را برای همان پروژه آماده می‌کند، به هر زبانی که نوشته شده باشد. سیستم‌عامل امن با ورود فقط با کلید و به‌روزرسانی امنیتی خودکار؛ محیط اجرای درست؛ نگهبان پردازش برای برنامه و کارهای پس‌زمینه؛ پراکسی معکوس با HTTPS و تمدید خودکار گواهی، HTTP/2 و فشرده‌سازی؛ کش فایل‌های ثابت؛ دیتابیس و ردیس با حافظه و دسترسی درست؛ نگه داشتن رمزها بیرون از کد؛ به‌روزرسانی بی قطعی با برگشت سریع؛ گزارش‌ها و نظارت؛ و پشتیبان روزانه در جای جدا. اگر پروژه Docker دارد، با Docker؛ اگر نه، مستقیم روی سیستم‌عامل.
سرور را خودتان، به نام خودتان، میخرید؛ ما پروژه را رویش بالا می‌آوریم و راه به‌روزرسانی را تحویل میدهیم، تا تیم شما هر وقت خواست نسخهی تازه را بفرستد. هزینهی این کار ثابت ۱۵ میلیون تومان است، و در پایان گزارش PDF همه‌ی کارهای انجام‌شده روی سرور را تحویل میگیرید.
جمع‌بندی
پروژهای که با Next.js، Node، پایتون یا هر زبان دیگری ساخته شده، برنامه‌ای دائمی است و جایی برای ماندن می‌خواهد؛ هاست اشتراکی برای این ساخته نشده. پلتفرم‌های آماده برای شروع راحت‌اند ولی با بزرگ شدن گران و وابسته‌کننده می‌شوند. یک سرور خودتان، که یک بار درست پیکربندی شده، پروژه را با هزینهی ماهانهی ثابت، نزدیک کاربرانتان و بی وابستگی به یک پلتفرم اجرا می‌کند. اگر پروژهای آماده دارید که باید روی سرور برود، شروع یک پروژه را از این‌جا ثبت کنید.