چطور یک اپ ساخته‌شده با هوش مصنوعی را خروجی بگیریم و روی سرور خودمان میزبانی کنیم
برای میزبانی خودتان از یک اپ ساخته‌شده با هوش مصنوعی، کد را بیرون بیاورید (با دانلود یا همگام‌سازی با یک مخزن GitHub که مال شماست)، اسرار را به‌عنوان متغیرهای محیطی دوباره بسازید، پایگاه داده را منتقل یا دوباره بسازید و آن را روی میزبانی که با نوع اپ می‌خواند مستقر کنید: یک میزبان استاتیک برای فرانت‌اِند ساده، یا پلتفرمی که سرور یا کانتینر اجرا کند برای هر چیزی که بک‌اِند دارد. کد معمولاً بخش آسان ماجراست. داده، اسرار و سرویس‌هایی که سازنده بی‌سروصدا برایتان اجرا می‌کرد، جایی است که کار واقعی اتفاق می‌افتد.
چرا اصلاً خروجی بگیریم
دلایل خوبی برای بردن کدتان با خود وجود دارد و دلایل کمتر خوب هم.
دلایل خوب:
- مالکیت و بیمه. یک نسخه از کد در مخزن خودتان از شما محافظت می‌کند اگر سازنده قیمت، امکانات یا شرایطش را تغییر دهد.
- تحویل به توسعه‌دهندگان. یک تیم مهندسی کد را در Git، در ابزارها و فرایند بررسی معمول خودش می‌خواهد.
- نیازهای مشخص. محل نگهداری داده، یک ارائه‌دهنده‌ی ابری خاص، سیاست‌های امنیتی شرکت، یا زیرساختی که سازنده ارائه نمی‌دهد.
- مقیاس یا هزینه در اندازه‌ای که اجرای زیرساخت خودتان واقعاً سودمند باشد.
دلایل کمتر خوب: جابه‌جایی یک اپ کوچک با چند کاربر برای صرفه‌جویی در مبلغ کم ماهانه. میزبانی خودتان کار را به دوش شما می‌گذارد: به‌روزرسانی، پشتیبان‌گیری، مانیتورینگ و وصله‌های امنیتی. این می‌تواند معامله‌ی درستی باشد؛ فقط آگاهانه انجامش دهید.
یک راه میانه‌ی معقول: همان‌جا که هستید بسازید و میزبانی کنید، اما از همان ابتدا با مخزن GitHub خودتان همگام‌سازی کنید. بیمه را بدون کار عملیاتی به دست می‌آورید. اگر Git برایتان تازه است، GitHub چیست را بخوانید.
خروجی چه چیزی را دارد و چه چیزی را ندارد
پیش از تکیه بر خروجی، بازش کنید و بررسی کنید. معمولاً:
| شامل می‌شود | معمولاً شامل نمی‌شود |
|---|---|
| کد منبع (فرانت‌اِند، بک‌اِند) | مقادیر اسرار (کلیدهای API، رمزها) |
فایل‌های پیکربندی (package.json، Dockerfile، تنظیمات بیلد) | وابستگی‌های نصب‌شده (node_modules و مشابه آن) — دوباره نصب می‌شوند |
| ساختار پایگاه داده و فایل‌های مهاجرت، اگر اپ از آن‌ها استفاده کند | داده‌ی واقعی پایگاه داده |
| دارایی‌های استاتیک داخل پروژه | فایل‌هایی که کاربران در فضای ذخیره‌سازی جداگانه آپلود کرده‌اند |
| سرویس‌های مدیریت‌شده توسط سازنده: میزبانی، دامنه‌ها، سرور پایگاه داده، فضای ذخیره‌سازی فایل |
اسرار عمداً کنار گذاشته می‌شوند؛ آرشیوی که ممکن است ایمیل شود یا commit شود، نباید کلیدهای زنده داشته باشد. وابستگی‌ها کنار گذاشته می‌شوند چون از روی فایل قفل دوباره ساخته می‌شوند.
گام ۱: کد را بیرون بیاورید
دو مسیر رایج:
- دانلود یک آرشیو از پروژه. سریع است و برای یک انتقال یک‌باره یا پشتیبان‌گیری مناسب است.
- همگام‌سازی با GitHub. برای هر چیزی که ادامه دارد بهتر است: تاریخچه‌ی کامل، کلون آسان در هر جا، و بیشتر میزبان‌ها مستقیم از یک مخزن GitHub در هر push دیپلوی می‌کنند.
در هر حال، آن را روی یک کامپیوتر (یا محیط توسعه‌ی ابری) کلون یا باز کنید و دنبال README بگردید. اگر نبود، پیش از خروج از سازنده، از هوش مصنوعی بخواهید یکی بنویسد:
یک README برای اجرای این پروژه بیرون از این پلتفرم بنویس: پشته‌ی فنی، نسخه‌های لازم زمان اجرا، دستورهای نصب و بیلد، دستور شروع و پورت، هر متغیر محیطی که کد می‌خواند (نام و کاربرد، بدون مقدار)، و اینکه مهاجرت‌های پایگاه داده چطور اجرا می‌شوند.
این یک پرامپت ساعت‌ها وقت را ذخیره می‌کند، چون بخش‌های ضمنی راه‌اندازی را به نوشته تبدیل می‌کند.
گام ۲: اول به‌صورت محلی اجرایش کنید
پیش از دیپلوی در هر جا، ثابت کنید اپ به تنهایی اجرا می‌شود:
- زمان اجرای لازم که README نام برده را نصب کنید — Node.js، Python، Java، .NET — با نسخه‌ی سازگار.
- وابستگی‌ها را نصب کنید (
npm install،pnpm install،pip install -r requirements.txtیا معادل آن). - یک فایل محلی
.envبسازید با متغیرهای محیطی، و تا جایی که ممکن است از کلیدهای تست استفاده کنید. آن را خارج از Git نگه دارید. متغیرهای محیطی و اسرار چیست مفهوم را توضیح می‌دهد. - به یک پایگاه داده وصلش کنید — یک Postgres محلی، یا یک پایگاه داده‌ی توسعه‌ی رایگان از یک ارائه‌دهنده‌ی مدیریت‌شده.
- مهاجرت‌ها را اجرا کنید، سپس اپ را روشن کنید و جریان‌های اصلی را امتحان کنید.
هر چیزی که اینجا خراب شود روی میزبان هم خراب می‌شود، و اشکال‌زدایی روی ماشین خودتان خیلی ساده‌تر است. غافلگیری‌های رایج: یک نشانی سختکد شده از پیش‌نمایش سازنده، یک متغیر محیطی که سازنده خودکار تزریق می‌کرد و جا افتاده، یا سرویسی (ذخیره‌ی فایل، تغییر اندازه‌ی تصویر) که فقط روی پلتفرم وجود داشت.
گام ۳: داده را منتقل کنید
اگر اپ کاربران واقعی دارد، داده از کد مهم‌تر است.
- پایگاه داده را خروجی بگیرید. برای Postgres،
pg_dumpفایلی می‌سازد که باpg_restoreیاpsqlدر پایگاه داده‌ی جدید بازیابی می‌شود. اگر دسترسی مستقیم ندارید، از هوش مصنوعی سازنده بخواهید اجرایش کند و توضیح دهد چه تولید کرده است. - فایل‌های آپلودشده را منتقل کنید. اگر کاربران تصویر یا سند آپلود کرده‌اند، آن‌ها در فضای ذخیره‌سازی شیءمحور جدا از پایگاه داده هستند. آن‌ها را در فضای جدید کپی کنید (مثلاً یک باکت سازگار با S3) و اگر نشانی‌های ذخیره‌شده شامل میزبان قدیمی‌اند، آن‌ها را به‌روز کنید.
- جابه‌جایی را برنامه‌ریزی کنید. برای یک اپ زنده، روش ساده یک پنجره‌ی نگهداری کوتاه است: نوشتن را متوقف کنید، خروجی نهایی بگیرید، در میزبان جدید بازیابی کنید، DNS را عوض کنید و دوباره باز کنید. پیش از آن هر گام را بنویسید.
- یک بازیابی آزمایشی انجام دهید در یک پایگاه داده‌ی موقت پیش از جابه‌جایی واقعی.
اگر Postgres برایتان ناآشناست، Postgres چیست مبانی را توضیح می‌دهد.
گام ۴: انتخاب محل میزبانی
میزبان را با نوع اپ هماهنگ کنید. نام‌های زیر نمونه‌هایی از ارائه‌دهندگان معروف در هر دسته، از سپتامبر ۲۰۲۶، و نه رتبه‌بندی هستند؛ امکانات و قیمت فعلی را در سایت خودشان بررسی کنید.
| نوع اپ | چه چیزی لازم دارد | نمونه‌ی میزبان‌ها |
|---|---|---|
| سایت استاتیک یا SPA (فقط HTML، CSS، JS) | میزبانی فایل با CDN | Netlify، Vercel، Cloudflare Pages، GitHub Pages |
| فریم‌ورک کامل‌پشته (Next.js و مشابه آن) | سرور یا توابع بدون سرور | Vercel، Netlify، Render، Railway |
| API یا بک‌اِند (Node، Python، Java، C#) | سرور همیشه‌روشن یا با مقیاس تا صفر | Render، Railway، Fly.io، سرویس‌های کانتینری ابری |
| هر چیزی با Dockerfile | زمان اجرای کانتینر | Fly.io، Render، Railway، AWS، Google Cloud، Azure |
| کنترل کامل | یک سرور مجازی که خودتان مدیریت می‌کنید | DigitalOcean، Hetzner، Linode، یا هر VM ابری |
همچنین به این‌ها نیاز دارید:
- یک پایگاه داده‌ی مدیریت‌شده — بسیاری از میزبان‌های اپ Postgres ارائه می‌دهند و سرویس‌های اختصاصی مثل Neon یا Supabase آن را به‌تنهایی عرضه می‌کنند. مدیریت‌شده ارزشش را دارد: پشتیبان‌گیری و به‌روزرسانی کار شخص دیگری است.
- فضای ذخیره‌سازی شیءمحور برای آپلودها، اگر اپ آپلود دارد.
- ارسال ایمیل، پرداخت و ارائه‌دهندگان هوش مصنوعی — معمولاً فقط به همان کلیدهای API روی میزبان جدید نیاز دارند.
درباره‌ی مبادلات منصفانه باشیم: میزبان‌های پلتفرمی (ردیف‌های چهار اول) راه‌اندازی و نگهداری سریع‌تری دارند، اما کنترل کمتری دارید و هزینه‌ها با ترافیک بالا می‌رود. یک سرور مجازی در بار ثابت اغلب ارزان‌تر است و کاملاً زیر کنترل شماست، اما وصله‌گذاری، TLS، پشتیبان‌گیری، مانیتورینگ و بازیابی با خودتان است. اگر کسی در تیم نمی‌خواهد این کار را بر عهده بگیرد، یک پلتفرم انتخاب کنید. برای مبانی میزبانی وب، میزبانی وب چیست را ببینید.
گام ۵: دیپلوی کنید و سوئیچ کنید
- مخزن را به میزبان وصل کنید، یا یک ایمیج کانتینر push کنید.
- متغیرهای محیطی را در داشبورد میزبان تنظیم کنید — هر کدام را از README، با مقادیر زنده.
- دستورهای بیلد و شروع و پورت را تنظیم کنید. بسیاری از میزبان‌ها پورت را در متغیر
PORTمی‌فرستند؛ اپ باید روی همان و روی همه‌ی رابط‌ها (0.0.0.0) گوش دهد، نه فقط رویlocalhost. - مهاجرت‌ها را روی پایگاه داده‌ی جدید اجرا کنید.
- روی نشانی موقت میزبان تست کنید پیش از اینکه به DNS دست بزنید.
- سرویس‌های بیرونی که به نشانی قدیمی اشاره می‌کنند را به‌روز کنید: وب‌هوک‌های پرداخت، نشانی‌های بازگشت OAuth برای ورود، لینک‌های ایمیل، مبداهای مجاز.
- دامنه را منتقل کنید با به‌روزرسانی رکوردهای DNS به میزبان جدید. چطور دامنه‌ی اختصاصی وصل کنیم رکوردها را توضیح می‌دهد.
- دیپلوی قدیمی را برای مدتی کوتاه در حال اجرا نگه دارید تا مطمئن شوید، بعد خاموشش کنید.
گام ۶ معمولاً فراموش می‌شود: ورود یا پرداختی که بی‌صدا بعد از جابه‌جایی خراب می‌شود، معمولاً به یک نشانی callback برمی‌گردد که هنوز به میزبان قدیمی اشاره می‌کند.
گام ۶: عملیات را خودتان بر عهده بگیرید
وقتی خودتان میزبانی می‌کنید، کارهایی که سازنده انجام می‌داد به شما می‌رسد. حداقل: پشتیبان‌گیری خودکار از پایگاه داده با بازیابی آزمایش‌شده، ردیابی خطا، هشدار uptime، به‌روزرسانی وابستگی‌ها و یادداشتی از اینکه چه کسی به هر حساب دسترسی دارد. چطور یک نمونه‌ی اولیه‌ی هوش مصنوعی را به محصول واقعی ببریم این فهرست را با جزئیات بیشتر مرور می‌کند.
فهرست بررسی خروجی
- کد در مخزنی که مال شماست، با README شامل اجرا، بیلد و متغیرهای محیطی
- اپ از یک کلون تمیز به‌صورت محلی اجرا می‌شود
- پایگاه داده خروجی گرفته و بازیابی آن آزمایش شده؛ فایل‌های آپلودشده کپی شده‌اند
- میزبان متناسب با نوع اپ انتخاب شده، به‌همراه پایگاه داده و فضای ذخیره‌سازی مدیریت‌شده
- همه‌ی متغیرهای محیطی با مقادیر زنده روی میزبان جدید تنظیم شده‌اند
- وب‌هوک‌ها، ریدایرکت‌های OAuth و لینک‌های ایمیل به‌روز شده‌اند
- DNS سوئیچ شده، دیپلوی قدیمی برای مدتی نگه داشته و سپس حذف شده
- پشتیبان‌گیری، مانیتورینگ و فهرست دسترسی برقرار است
خروجی گرفتن از Mythex
در Mythex، کدی که می‌سازید مال خودتان است. در پلن Pro می‌توانید پروژه را از Project settings → Export به‌صورت آرشیو دانلود کنید، یا GitHub را وصل کنید و با مخزن خودتان push و pull کنید؛ پلن‌های رایگان فقط می‌توانند کد را به‌صورت فقط‌خواندنی ببینند و نمی‌توانند خروجی بگیرند یا همگام‌سازی کنند. اسرار و node_modules از خروجی حذف می‌شوند، پس اسرار را روی میزبان جدید دوباره بسازید. مستندات مراحل را در خروجی و اجرا در جای دیگر و GitHub، خروجی و ورودی پوشش داده‌اند. می‌توانید همچنان روی Mythex میزبانی کنید و همگام‌سازی GitHub را فقط به‌عنوان نسخه‌ی خودتان و مسیر تحویل استفاده کنید؛ و اگر جابه‌جا شدید، پس از زنده شدن میزبان جدید، اپ Mythex را منتشرنشده کنید.
پرسش‌ها
آیا می‌توانم کد را از یک سازنده‌ی اپ هوش مصنوعی خروجی بگیرم؟
به ابزار و پلن بستگی دارد. برخی سازنده‌ها اجازه می‌دهند کل پروژه را دانلود کنید یا آن را با یک مخزن GitHub که مال خودتان است همگام کنید؛ برخی دیگر اپ را داخل پلتفرم خودشان نگه می‌دارند. پیش از سرمایه‌گذاری ماه‌ها روی یک ابزار، بررسی کنید و بخوانید چه چیزی در خروجی هست و چه چیزی نیست.
آیا خروجی شامل پایگاه داده و کلیدهای API من می‌شود؟
معمولاً کد خروجی گرفته می‌شود، اما داده و اسرار نه. کلیدهای مخفی عمداً معمولاً کنار گذاشته می‌شوند و محتوای پایگاه داده به خروجی جداگانه نیاز دارد، مثل pg_dump برای Postgres. پیش از تغییر میزبان، هر دو را برنامه‌ریزی کنید.
یک اپ خروجی‌گرفته‌شده را کجا میزبانی کنم؟
یک فرانت‌اِند استاتیک به میزبان‌های استاتیک مثل Netlify، Vercel یا Cloudflare Pages می‌خورد. اپی که سرور خودش را دارد به پلتفرمی نیاز دارد که کد یا کانتینر اجرا کند، مثل Render، Railway یا Fly.io، یا یک سرور مجازی که خودتان مدیریت می‌کنید. اگر اپ پایگاه داده دارد، یک پایگاه داده‌ی مدیریت‌شده هم لازم است.
آیا میزبانی خودم ارزان‌تر از ماندن روی سازنده است؟
گاهی، در مقیاس بزرگ. برای اپ‌های کوچک، تفاوت اغلب ناچیز است وقتی پایگاه داده، ایمیل، مانیتورینگ و زمانی که خودتان صرف نگهداری می‌کنید را حساب کنید. برای کنترل یا نیازهای مشخص جابه‌جا شوید، نه فقط برای صرفه‌جویی چند دلار در ماه.