پیش از شروع
- این راهنما را با یک پروژه آزمایشی یا منبعی که مجاز به تغییر آن هستید دنبال کنید.
- هزینه و اثر حذف یا جایگزینی داده در مرحله تأیید نهایی دوباره نمایش داده می‌شود.
- پس از هر تغییر، نتیجه مورد انتظار همان مرحله را در وضعیت پروژه، رخدادها یا گزارش فعالیت بررسی کنید.
استک تشخیص داده نمی‌شود
ZIP را باز کنید و مطمئن شوید manifest اصلی، Dockerfile یا compose.yaml داخل آن است. فایل پروژه نباید یک ZIP دیگر داخل ZIP باشد.
Build وابستگی یا Image پایه شکست می‌خورد
lockfile و نسخه runtime را بررسی کنید. در Python، requirements.txt یا pyproject.toml باید همه وابستگی‌های مستقیم را داشته باشد؛ Build استاندارد چند import رایج و بدون ابهام مانند requests، dotenv و yaml را در فایل‌های تو‌در‌تو هم بررسی و در صورت جاافتادن نصب می‌کند، اما سورس یا manifest شما را تغییر نمی‌دهد. خط اول خطای واقعی را در جزئیات Build پیدا کنید؛ هنگام نصب، خروجی مستقیم npm، pnpm یا Yarn نمایش داده می‌شود. در پاستا بوم، بخش مرتبط خطای قطعی کد یا کامپایل همان نسخه از لاگ Build به‌صورت خودکار برای اصلاح به عامل داده می‌شود؛ پس از ذخیره اصلاح، Build تازه همان پیش‌نمایش نیز روی سرور آغاز می‌شود و هر دو مرحله پس از بستن مرورگر ادامه دارند. خطاهای شبکه وارد اصلاح کد نمی‌شوند و هر درخواست حداکثر سه تلاش اصلاح دارد. در ساخت خودکار Node، lifecycle scriptهای نصب مانند postinstall پس از در دسترس‌بودن سورس کامل اجرا می‌شوند تا Prisma، workspace و patchها فایل‌های خود را پیدا کنند؛ پروژه‌های بدون این scriptها همچنان از cache سریع وابستگی استفاده می‌کنند. وجود package-lock باعث اجرای npm ci می‌شود و پروژه بدون lockfile با npm install ساخته می‌شود؛ اما فرمان صریح Dockerfile شما تغییر نمی‌کند. آدرس‌های عمومی منسوخ‌شده در lockfile هنگام Build به مسیر فعال منتقل می‌شوند و فایل اصلی تغییر نمی‌کند. خطاهای قطعی پیکربندی دوباره اجرا نمی‌شوند و Retry محدود برای اختلال موقت شبکه حفظ می‌شود. Imageهای Docker Hub و docker.n8n.io در ناحیه ایران خودکار از cache داخلی و mirror داخلی کشور دریافت می‌شوند؛ cache پروژه نیز در Build بعدی استفاده می‌شود.
Dockerfile خودم خطا می‌دهد
اگر پروژه تک‌سرویسی باشد و سورس هنوز نگه‌داری شود، صفحه استقرار گزینه «ساخت بدون Dockerfile» را نشان می‌دهد. پس از تأیید شما، پاستا فقط برای نسخه جدید Dockerfile را کنار می‌گذارد، استک را از فایل‌های پروژه تشخیص می‌دهد و تنظیم ساخت استاندارد می‌سازد. Dockerfile اصلی، سورس، متغیرها، Secretها و نسخه فعال Production تغییر نمی‌کنند. پروژه‌های Compose برای جلوگیری از تغییر ناخواسته توپولوژی شامل این بازیابی نیستند.
اپ پس از Build بالا نمی‌آید
صفحه استقرار خطاهایی مانند OOMKilled، CrashLoopBackOff، ErrImagePull، تنظیمات اجباری ناقص، DI دات‌نت، ناسازگاری shell، مشکل Permission، دیتابیس، پورت و Health Check را تشخیص می‌دهد و چک‌لیست مرتبط نشان می‌دهد. خطای تکراری جداگانه اعلام می‌شود تا Retry بدون تغییر انجام نشود. برنامه‌های معمولی پنج دقیقه و سپس دو دقیقه فرصت بازیابی کنترل‌شده دارند؛ اگر نسخه فعال در این بازه واقعاً آماده و از مسیر عمومی قابل دسترس شود، وضعیت همان نسخه بدون Build دوباره اصلاح می‌شود.
متغیرهای لازم قبل از انتشار ناقص‌اند
در paasta.json فیلد requiredEnv را به‌شکل فهرست نام‌ها تعریف کنید؛ برای نمونه {"requiredEnv":["DATABASE_URL","API_TOKEN"]}. پاستا نام متغیرهای خالی را در بررسی پروژه نشان می‌دهد، مقدارهای واردشده را حفظ می‌کند و تا کامل‌شدن آن‌ها استقرار را شروع یا شارژ نمی‌کند.
Health Check ناموفق است
مسیر باید بدون احراز هویت پاسخ 2xx/3xx بدهد. اگر برنامه مسیر سلامت ندارد، فیلد را خالی بگذارید تا TCP بررسی شود.
دامنه شخصی تأیید نمی‌شود
رکورد TXT را دقیقاً روی نام نمایش‌داده‌شده بسازید، تا انتشار DNS صبر کنید و دوباره تأیید را بزنید. سپس وضعیت صدور TLS را بررسی کنید.