اگر بیشترِ روزتان در ترمینال می‌گذرد، باز کردنِ پنل فقط برای زدنِ یک دکمه‌ی دیپلو حواس را پرت می‌کند. کد را push می‌کنید، به مرورگر می‌روید، سرویس را پیدا می‌کنید، دیپلو می‌زنید و منتظرِ لاگ می‌مانید.
CLI وب‌لاینز همین چرخه را به ترمینال می‌آورد. با دستورِ weblines دیپلو می‌کنید، لاگِ build را تا پایان همان‌جا می‌بینید، لاگِ زنده را دنبال می‌کنید و متغیرهای محیطی را تنظیم می‌کنید. همین دستورها در CI هم کار می‌کنند، پس دیپلویِ خودکار بعد از تست هم با چند خط درست می‌شود.
نصب در یک دقیقه#
CLI به Node.js نسخه‌ی ۱۸.۱۷ یا جدیدتر نیاز دارد و هیچ وابستگیِ دیگری ندارد:
npm install -g weblines
weblines --version
اگر npm شما روی یک آینه‌ی داخلی تنظیم است و پکیج را پیدا نمی‌کند، رجیستریِ اصلی را بدهید:
npm install -g weblines --registry=https://registry.npmjs.org
کدِ CLI متن‌باز است: github.com/weblines-cloud/cli.
ورود بدونِ کپیِ کلید#
weblines login
مرورگر باز می‌شود و صفحه‌ی تأییدِ کنسولِ وب‌لاینز را نشان می‌دهد. دسترسی‌هایی را که CLI می‌خواهد می‌بینید و APPROVE را می‌زنید. کلیدی کپی و جابه‌جا نمی‌شود. تأیید فقط از مالک یا ادمینِ سازمان پذیرفته می‌شود.
ورود در ~/.config/weblines/config.json ذخیره می‌شود و فقط کاربرِ خودتان می‌تواند آن را بخواند. هر وقت خواستید، weblines logout ورود را باطل می‌کند. فهرستِ اتصال‌های فعال را هم در پنل، بخشِ Settings → API keys → Connected apps می‌بینید و از همان‌جا قطع می‌کنید.
اولین دیپلو از ترمینال#
اول ببینید چه سرویس‌هایی دارید:
weblines ps
خروجی یک جدول است با نام، نوع، وضعیت و اندازه‌ی هر سرویس. حالا پوشه‌ی پروژه را یک بار به سرویسش وصل کنید:
cd my-app
weblines link my-app
این دستور یک فایلِ کوچکِ .weblines.json می‌سازد. از این به بعد، داخلِ همین پوشه لازم نیست نامِ سرویس را بنویسید:
weblines deploy
دیپلو شروع می‌شود و لاگِ build زنده در ترمینال می‌آید تا وقتی تمام شود. اگر build شکست بخورد، دستور با کدِ خروجِ 1 تمام می‌شود. این برای اسکریپت و CI مهم است، چون شکستِ دیپلو را می‌فهمند.
دو گزینه‌ی کاربردی:
weblines deploy --force: build بدونِ cache. فقط وقتی وابستگی‌ها یا Dockerfile عوض شده‌اند؛ کندتر است.weblines deploy --no-wait: دیپلو را شروع می‌کند و منتظرِ پایان نمی‌ماند.
یک نکته‌ی مهم:
weblines deployفایل‌های پوشه‌ی شما را آپلود نمی‌کند. سرویس از همان منبعی build می‌شود که در وب‌لاینز برایش تنظیم شده، مثلاً ریپو و برنچِ گیت. پس اولgit pushکنید، بعد دیپلو. اگر کد روی گیت نیست، از ساخت با فایل ZIP در پنل استفاده کنید.
لاگ، وضعیت و کنترلِ سرویس#
بعد از دیپلو، برای دیدنِ لاگِ اجرای اپ:
weblines logs -f
-f لاگ را زنده دنبال می‌کند. با -n 500 یا -n 2000 خط‌های بیشتری از گذشته می‌گیرید.
بقیه‌ی دستورهای روزمره:
| دستور | کار |
|---|---|
weblines status | وضعیتِ سرویس و آدرس‌هایش، همراهِ وضعیتِ SSL |
weblines open | آدرسِ وبِ سرویس |
weblines restart | ری‌استارت |
weblines stop / weblines start | خاموش و روشن کردن |
یادتان باشد سرویسِ خاموش هزینه‌ی CPU و RAM ندارد و فقط دیسکش حساب می‌شود. پس weblines stop برای محیطِ تست در آخرِ هفته راهِ ساده‌ای برای صرفه‌جویی است. (کیف پول و هزینه‌ها)
متغیرهای محیطی#
weblines env ls
weblines env set NODE_ENV=production API_URL=https://api.example.com
weblines env unset OLD_FLAG
weblines deploy
env ls فقط نامِ متغیرها را نشان می‌دهد، نه مقدارشان. مقدارِ رمزها هیچ‌وقت در ترمینال چاپ نمی‌شود، پس اسکرین‌شات یا لاگِ ترمینال چیزی را لو نمی‌دهد. بعد از تغییرِ متغیرها یک بار دیپلو کنید تا اپ مقدارهای تازه را بگیرد.
دیپلویِ خودکار در CI#
روی سرورِ CI کسی نیست که در مرورگر تأیید کند. آن‌جا به‌جای ورود، یک کلیدِ API بسازید:
- در پنل: Settings → API keys → New key، فقط با دسترسیِ
readوdeploy. - کلید را به‌عنوانِ secret با نامِ
WEBLINES_TOKENدر CI ذخیره کنید. هیچ‌وقت در ریپو commit نکنید.
GitHub Actions#
اکشنِ آماده‌ی وب‌لاینز همه‌ی کار را می‌کند. این فایل را در .github/workflows/deploy.yml بگذارید:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: weblines-cloud/deploy-action@v1
with:
app: my-app
token: ${{ secrets.WEBLINES_TOKEN }}
لاگِ build در خودِ job دیده می‌شود و اگر دیپلو شکست بخورد، pipeline هم قرمز می‌شود.
GitLab و همگیت#
deploy:
stage: deploy
image: node:20-alpine
rules:
- if: $CI_COMMIT_BRANCH == "main"
before_script:
- npm install -g https://codeload.github.com/weblines-cloud/cli/tar.gz/v0.1.1
script:
- weblines deploy my-app
اگر runner شما به GitHub دسترسی ندارد (بعضی runnerهای داخلِ ایران)، به‌جای CLI از Deploy Hook استفاده کنید. یک curl است و چیزی نصب نمی‌خواهد. نمونه‌های کامل در مستنداتِ دیپلوی از CI هست.
اگر اپ با GitHub وصل‌شده ساخته شده و «دیپلوی با هر push» روشن است، وقتی CI را راه انداختید آن را خاموش کنید. وگرنه هر push دو بار دیپلو می‌شود و اپ قبل از گذشتنِ تست‌ها هم بالا می‌آید.
امنیت: CLI چه کارهایی نمی‌کند#
- حذف ندارد. هیچ سرویسی را نمی‌شود از CLI پاک کرد؛ حذف فقط از پنل است.
- مقدارِ رمزها را نمی‌خواند. فقط نامِ متغیرها را می‌بیند.
- کلید در CI با کمترین دسترسی. کلیدِ
read+deployنمی‌تواند سرویس بسازد یا متغیر عوض کند. - همه‌چیز ثبت می‌شود. هر دیپلو در Activity سازمان با نامِ کلید یا اتصال ثبت می‌شود.
محدودیت‌های نسخه‌ی فعلی#
صادقانه بگوییم CLI هنوز چه کارهایی را نمی‌کند:
- ساختِ سرویسِ تازه از ترمینال نیست؛ سرویس را یک بار از پنل بسازید.
env pullنداریم، چون مقدارِ متغیرها عمداً خوانده نمی‌شود.- ترمینالِ کانتینر و شِلِ دیتابیس فعلاً فقط در پنل هستند.
CLI یا دستیارِ هوش مصنوعی؟#
هر دو یک کار را از دو راه انجام می‌دهند. CLI برای وقتی است که خودتان دستور می‌دهید یا اسکریپت و CI دارید. اگر ترجیح می‌دهید به زبانِ عادی بنویسید «لاگ را بخوان و بگو چرا خطا می‌دهد»، وب‌لاینز را به Claude Code، Cursor یا Gemini CLI وصل کنید. خیلی‌ها هر دو را کنارِ هم استفاده می‌کنند.
سؤال‌های رایج#
روی ویندوز کار می‌کند؟ بله. CLI با Node.js اجرا می‌شود و روی ویندوز، مک و لینوکس یکسان است.
چند سازمان دارم. CLI با کدام کار می‌کند؟
با همان سازمانی که موقعِ weblines login در صفحه‌ی تأیید انتخاب کردید. برای سازمانِ دیگر، دوباره وارد شوید.
هزینه‌ی جداگانه دارد؟ نه. CLI رایگان است؛ فقط بابتِ سرویس‌هایی که روشن است، طبقِ قیمت‌گذاری پرداخت می‌کنید.
از کجا شروع کنیم؟#
اگر هنوز سرویسی روی وب‌لاینز ندارید، اول ریپوی GitHub را دیپلو کنید یا اولین اپ Docker را بالا بیاورید. بعد CLI را نصب کنید، weblines login بزنید و دیپلوی بعدی را از ترمینال انجام دهید. فهرستِ کاملِ دستورها در مستنداتِ CLI است.