مسئله برنامه جمعهشب
مدیر شرکتی که میشناسیم یک جمعهشب را با یک دستیار هوش مصنوعی گذراند و تا نیمهشب ابزار داخلی واقعاً کاربردیای در دست داشت: پیگیری وظایف دقیقاً به شکلی که تیمش کار میکند، چون او کار را بهتر از هر فروشندهای میشناسد. برنامه عالی اجرا میشد — روی لپتاپ خودش.
گزینههای روز دوشنبه همه بد بودند. از واحد IT سرور بخواهد و هفتهها منتظر خزیدن یک تیکت بماند. دادههای شرکت را روی یک پلتفرم تفریحی خارجی بگذارد. یا یک VPS خام اجاره کند و یکشبه مسئول TLS، بکاپ، وصلههای امنیتی و فایروال شود. کد خوب بود. آنچه کم بود، یک راه بود.
چرا مسیرهای معمول استقرار جواب نمیدهند
هر مسیر رایجی چیزی را فرض میگیرد که این سازنده ندارد. استقرار مبتنی بر git یک مخزن و جریان کاری branch را فرض میکند. استقرار مبتنی بر image یک registry کانتینر و تسلط بر Docker برای تغذیه آن را. هر دو فرض میکنند کسی که منتشر میکند، دستکم پارهوقت، یک مهندس استقرار است.
آنچه سازنده متکی به هوش مصنوعی واقعاً دارد سادهتر است: پوشهای با کد کارا داخلش. پس راه باید دقیقاً از همانجا شروع شود — از پوشه. اگر مخزن دارید استقرار از Git را ببینید؛ هر دو راه به یک پلتفرم میرسند.
پوشه کافی است
یک CLI کوچک نصب کنید، یک فرمان در پوشه پروژه اجرا کنید، و cdnctl بقیه را خودش درمیآورد: زبان و فریمورک، پورت، اینکه Dockerfile هست یا نه (میتواند خودش یکی بسازد)، و حتی اینکه کدام agentهای کدنویسی هوش مصنوعی در پروژه پیکربندی شدهاند — چون agentی که برنامه را نوشته معمولاً همانی است که انتشارش را هم ادامه خواهد داد.
$ cdnctl init
Proje : gorev-takip (node/express, port 3000)
Agent : claude-code (claude on PATH), cursor
Paket : ✓ Large (max 5 app)
Karne : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı : cdnctl.yaml, AGENTS.md
→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).
یک کارنامه، پیش از آنکه کدتان از ماشین خارج شود
برنامههای ساخته هوش مصنوعی به چند دلیل بسیار تکرارشونده در محیط تولید خراب میشوند و همه آن دلایل پیش از استقرار در سورس قابلدیدناند. cdnctl check کاملاً روی ماشین شما اجرا میشود — هیچ کدی آپلود نمیشود — و اجازه نمیدهد برنامهای که خرابیاش از پیش معلوم است منتشر شود. این چهار یافته زیر فرضی نیستند: دقیقاً همان خطاهاییاند که برنامه آزمایشی خودمان با آنها نوشته شده بود و در نخستین اجرا گرفته شدند.
$ cdnctl check
[ERROR] bind-localhost (server.js:61)
The app binds to 127.0.0.1 — unreachable inside a container.
→ Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
A hard-coded secret (API key/token/password).
→ Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
SQLite loses data on restart / multiple replicas.
→ Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
No /health route — the platform can’t tell your app is alive.
یک فرمان تا URL زنده
پس از اصلاحها، استقرار یک فرمان واحد است. در پسزمینه سورس شما آرشیو میشود، روی TLS آپلود میشود، درون یک sandbox ایزوله به یک image کانتینر تبدیل میشود، به فضای registry خصوصی حساب خودتان push میشود و پشت یک سابدامنه واقعی HTTPS بالا میآید — اما هیچکدام از اینها نیازی به توجه شما ندارد. اجرای نخست حدود یک دقیقه طول میکشد؛ هر انتشار بعدی همان یک فرمان است.
$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
build: running
build: success (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up
✓ LIVE: https://ca…….cdn.com.tr
امنیت و پایداری پیشفرضاند، نه کار اضافه
بخشهایی که مسیر VPS را ترسناک میکردند، اینجا وظیفه پلتفرماند. TLS برایتان صادر و تمدید میشود. بیلدها در sandbox اجرا میشوند و imageها در فضای registryای زندگی میکنند که تنها به حساب شما تعلق دارد. یک healthcheck به پلتفرم اجازه میدهد لحظهای که برنامه از پاسخدادن بازماند آن را restart کند. و وقتی کارنامه یک دیتابیس فایلی میبیند، شما را به دیسکهای پایدار و MySQL/PostgreSQL مدیریتشده راهنمایی میکند — تا restart یک pod هرگز دادههایتان را نبلعد.
agent هوش مصنوعی شما میتواند کل این جریان را خودش اجرا کند
cdnctl init یک بخش deploy در AGENTS.md مینویسد (و اگر CLAUDE.md وجود داشته باشد، در آن هم)، تا agentی که برنامه را ساخته در نوبت بعدی فرمانهای دقیق را بداند. agentها خروجی ماشینخوان با --json میگیرند، یک سرور MCP از راه cdnctl mcp، و — مهمتر از همه — توکن فقط-deploy مخصوص خودشان را: میتواند آپلود، build و انتشار کند و نمیتواند به DNS، صورتحساب یا بقیه حسابتان دست بزند. رمز پنل شما هرگز از دستتان خارج نمیشود. جزئیات در صفحات راهنمای cdnctl آمده است. برای مدل کامل امنیتی — مرزهای توکن، پیکربندی MCP و محدودیتهای آزمودهشده — دسترسی deploy را ایمن به agent خود بدهید را ببینید.
راه شما کدام است؟
سه راه، یک پلتفرم. اگر کد را در مخزن نگه میدارید و push-to-deploy میخواهید، استقرار از Git را انتخاب کنید. اگر همین حالا image میسازید و یک فایل compose اجرا میکنید، هاستینگ Docker را ببینید. و اگر آنچه دارید یک پوشه کاراست — همان موقعیت جمعهشب — این راه برای شما ساخته شده است: cdnctl را نصب کنید، init را اجرا کنید، deploy را اجرا کنید و URL را برای تیمتان بفرستید.
پرسشهای پرتکرار
آیا به GitHub یا هر میزبانی git نیاز دارم؟
نه. سورس بهصورت یک آرشیو مستقیماً از پوشه پروژه شما سفر میکند؛ git اصلاً وارد جریان نمیشود. اگر بعدها مخزن گرفتید، راه git سر جایش است و برنامه همان میماند.
آیا باید Docker بلد باشم؟
نه. اگر پروژه Dockerfile ندارد، cdnctl init میتواند از آنچه تشخیص داده یک Dockerfile معقول بسازد. خود build روی پلتفرم اجرا میشود، نه روی ماشین شما.
کد من واقعاً کجا میرود؟
آرشیو روی TLS به حساب شما آپلود میشود، یک بار درون یک sandbox ایزوله build میشود و image حاصل در فضای registry خصوصیای ذخیره میشود که فقط حساب شما از آن استفاده میکند. هیچچیز به اشتراک گذاشته نمیشود و هیچچیز بیرون از namespace شما اجرا نمیشود.
هزینهاش چقدر است؟
هر پلنی که پلتفرم کانتینر را شامل شود — و همه پلنهای استاندارد شامل میشوند. اگر حسابتان آن را نداشته باشد، cdnctl میگوید و لینک صفحه خرید را میدهد؛ پرداخت در مرورگر تمام میشود و cdnctl از همانجا که مانده بود ادامه میدهد.
بهروزرسانی را چطور منتشر کنم؟
دوباره cdnctl deploy را اجرا کنید. پلتفرم image جدید را میسازد و جایگزین میکند؛ نسخه قدیمی تا بالا آمدن نسخه جدید همچنان سرویس میدهد.