چگونه پروژه‌های Claude Code و Codex را روی سرور دیپلوی کنیم؟

ممکن است پروژه روی سیستم شما بدون مشکل کار کند، اما روی سرور به نسخه‌ی دیگری از محیط اجرا، متغیرهای محیطی یا فرمان شروع مناسب نیاز داشته باشد.

پیش از دیپلوی چه چیزهایی آماده کنیم؟

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

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

اتصال به سرور و آماده‌سازی محیط

برای مدیریت سرور لینوکسی معمولاً از SSH استفاده می‌شود. شکل کلی اتصال چنین است:

ssh username@server-ip

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

در سیستم‌های مبتنی بر Debian یا Ubuntu، ابتدا فهرست بسته‌ها را به‌روزرسانی و ابزارهایی مانند Git را نصب کنید:

sudo apt update
sudo apt install git

سپس محیط اجرای پروژه، مانند Node.js یا Python، را با نسخه‌ی مورد نیاز نصب کنید. به‌روزرسانی بسته‌های سرور را با توجه به سرویس‌های موجود انجام دهید؛ تغییر محیط نباید بدون بررسی روی برنامه‌های دیگر اثر بگذارد.

انتقال کد و نصب وابستگی‌ها

اگر پروژه در مخزن Git قرار دارد، آن را روی سرور دریافت کنید و وارد پوشه‌ی پروژه شوید:

git clone 
cd project

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

سپس وابستگی‌ها را با ابزار مدیریت بسته‌ی پروژه نصب کنید. برای پروژه‌ی npm دارای package-lock.json معتبر و هماهنگ، می‌توانید از دستور زیر استفاده کنید:

npm ci

این کار نصب وابستگی‌ها را با فایل قفل هماهنگ می‌کند. اگر پروژه از ابزار دیگری استفاده می‌کند، دستور متناظر همان ابزار را انتخاب کنید. همچنین وابستگی‌های مورد نیاز Build باید هنگام ساخت در دسترس باشند.

متغیرهای محیطی و اطلاعات حساس

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

DATABASE_URL=...
API_KEY=...
NODE_ENV=production
PORT=۳۰۰۰

صرف ساختن یک فایل تنظیمات کافی نیست؛ برنامه یا ابزار اجرای آن باید مقادیر را بارگذاری کند. همچنین بررسی کنید کدام متغیر هنگام Build لازم است و کدام فقط هنگام اجرای برنامه استفاده می‌شود.

اطلاعات محرمانه را وارد مخزن عمومی نکنید. اگر کلیدی منتشر شده باشد، حذف آن از آخرین نسخه کافی نیست؛ کلید افشاشده باید لغو یا جایگزین شود. دسترسی فایل‌های تنظیمات را نیز متناسب با کاربر اجرای برنامه محدود کنید.

ساخت خروجی و اجرای اولیه

پس از نصب وابستگی‌ها و تنظیم محیط، خروجی مناسب Production را بسازید. در بسیاری از پروژه‌های JavaScript، اسکریپت ساخت چنین اجرا می‌شود:

npm run build

اگر ساخت شکست خورد، پیام خطا را بررسی کنید. تفاوت نسخه‌ی محیط اجرا، نبودن متغیر محیطی، نصب‌نشدن بسته یا خطای کد از علت‌های احتمالی هستند.

پس از ساخت موفق، اسکریپت شروع پروژه را اجرا کنید:

npm run start

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

اجرای دائمی با مدیر فرایند

اجرای برنامه داخل نشست SSH برای نگهداری سرویس کافی نیست. بسته‌شدن نشست یا توقف فرایند ممکن است برنامه را از دسترس خارج کند. مدیر فرایند کمک می‌کند وضعیت اجرا و لاگ‌ها قابل بررسی باشند و راه‌اندازی مجدد مدیریت شود.

برای پروژه‌های Node.js می‌توان از PM۲ استفاده کرد. پس از نصب و آماده‌سازی آن، نمونه‌ی فرمان‌ها چنین است:

pm۲ start npm --name my-app -- start
pm۲ status
pm۲ logs my-app

برای بازگشت برنامه پس از راه‌اندازی مجدد سرور، تنظیم شروع خودکار نیز لازم است. این مرحله معمولاً با pm۲ startup و اجرای دستور پیشنهادی آن، سپس pm۲ save انجام می‌شود. تنظیم را با کاربر مناسب انجام دهید و رفتار سرویس پس از راه‌اندازی مجدد را بررسی کنید.

اتصال دامنه، پراکسی و HTTPS

برای دسترسی با دامنه، رکوردهای DNS را به مقصد مناسب اشاره دهید. سپس پراکسی معکوسی مانند Nginx می‌تواند درخواست‌های ورودی را به پورت داخلی برنامه منتقل کند. مسیر کلی شامل مرورگر کاربر، دامنه، پراکسی و برنامه است.

تنظیمات فایروال باید ترافیک مورد نیاز را اجازه دهند. لازم نیست پورت داخلی برنامه مستقیماً برای همه‌ی کاربران باز باشد؛ دسترسی عمومی می‌تواند از طریق پراکسی انجام شود. تنظیمات Nginx را پیش از اعمال بررسی کنید.

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

خطاهای رایج را از کجا بررسی کنیم؟

اگر برنامه شروع نمی‌شود، لاگ اجرا، فرمان شروع و نسخه‌ی محیط را بررسی کنید. اگر فقط روی سیستم محلی کار می‌کند، تفاوت متغیرهای محیطی، وابستگی‌ها و مجوزهای فایل را بسنجید.

برای خطای پایگاه داده، رشته‌ی اتصال، اعتبار اطلاعات کاربری و دسترسی شبکه اهمیت دارند. اگر دامنه باز نمی‌شود، DNS، فایروال، پراکسی و پورت مقصد را بررسی کنید. توقف برنامه پس از خروج از SSH نیز می‌تواند به روش مدیریت فرایند مربوط باشد.

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

دیپلوی ساده‌تر با پاستاکلود

استقرار دستی برای شناخت زیرساخت مفید است، اما با افزایش پروژه‌ها و دفعات انتشار، هماهنگی تنظیمات زمان بیشتری می‌گیرد. پلتفرم به‌عنوان سرویس یا PaaS می‌تواند بخشی از این فعالیت‌ها را در یک محیط متمرکز ارائه کند.

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

البته نسخه‌ی محیط اجرا، فرمان‌های Build و شروع و اطلاعات اتصال همچنان باید با پروژه هماهنگ باشند. پیش از انتشار عملیاتی، تنظیمات پیشنهادی و عملکرد برنامه را بررسی کنید. ابزار مدیریت زیرساخت، مسئولیت بررسی منطق محصول و داده‌ها را حذف نمی‌کند.

انتشار بعدی و آمادگی برای بازیابی

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

از اطلاعات مهم پشتیبان بگیرید و روش بازیابی را بشناسید. بازگشت کد به نسخه‌ی قبلی لزوماً تغییرات پایگاه داده را برنمی‌گرداند. اگر انتشار شامل مهاجرت داده باشد، برنامه‌ی بازگشت باید این تغییرات را هم پوشش دهد. پس از هر انتشار، خطاها و عملکرد مسیرهای اصلی را بررسی کنید.

جمع‌بندی

پروژه‌های ساخته‌شده با Claude Code و Codex برای آنلاین‌شدن به محیط اجرا، وابستگی‌ها، تنظیمات، مدیریت فرایند و دسترسی شبکه نیاز دارند. استقرار موفق زمانی کامل می‌شود که عملکرد برنامه، دامنه و نگهداری داده‌ها نیز بررسی شده باشند.

پاستاکلود با متمرکزکردن ابزارهای استقرار و مدیریت سرویس، این مسیر را ساده‌تر می‌کند. برای انتقال پروژه از محیط توسعه به Production، نیازهای برنامه را آماده کنید و در paasta.cloud سرویس مناسب خود را راه‌اندازی کنید.