EQVPS

د یوه ځان-کوربه شوي GitHub Actions Runner په یوه VPS چلول

Jul 27, 2026 · 5 دقیقې لوستل · EQVPS Team

GitHub-کوربه شوي runnerونه یو ښه ډیفالټ دي. تاسو هغه شیبه ورته اړتیا درولوئ چې یوه جوړونه یو څه وغواړي چې دوی یې نلري — ستاسو خصوصي د بستې راجستري، یوه ځانګړې د toolchain نسخه چې تاسو د یې هره کاله بیا نصبولو ستړي یاست، یو ډیټابیس ستاسو په خپله شبکه، یا یوازې د ماشین ډیر کنټرول. هغه وخت یو ځان-کوربه شوی runner په یوه VPS خپل ځای ګټي.

دا لارښود یو یې په سمه توګه چلوي: نصب شوی، راجستر شوی، د systemd لاندې ژوندی، او — هغه برخه چې خلک یې غلط کوي — خوندي. راځئ چې د هغه وروستي سره پیل وکړو، ځکه چې دا هغه برخه ده چې چیچي.

هغه یو د امنیت قاعده

یو GitHub Actions workflow خپل‌سري کوډ چلوي — هر څه چې د workflow فایل کې دي، او هر څه چې هغه کوډ یې راکشوي. په ستاسو خپل repo هغه ستاسو کوډ دی، او دا سم دی. په یوه عامه repo، د یوه اجنبي یو pull request کولی شي د دوی کوډ ستاسو په runner وچلوي. دا یو bug نه دی؛ دا هغه څنګه دی چې CI کار کوي. د GitHub خپل اسناد په ښکاره وايي: ځان-کوربه شوي runnerونه د عامه reposونو سره مه کاروئ.

نو قاعده ساده او غیر-د-خبرو وړ ده: ځان-کوربه شوي runnerونه د خصوصي reposونو لپاره دي. که ستاسو repo عامه وي، GitHub-کوربه شوي runnerونه وکاروئ او مخته لاړ شئ. لاندې هر څه یو خصوصي repo فرض کوي.

یو runner له box څه ته اړتیا لري

دا د جوړونې پورې اړه لري، او تاسو باید خپل ته یې اندازه کړئ نه یوې شمیرې ته د یوې پاڼې څخه:

ديسک هم مهم دی: د جوړونې کیشونه، د Docker layerونه، او clone شوي reposونه زیاتیږي. سترګه پرې وساتئ او prune یې کړئ.

۱. box چمتو کړئ

د runner لپاره یو غیر-root کاروونکی جوړ کړئ — د GitHub نصبوونکی په هر ډول د root په توګه چلولو انکار کوي، او تاسو دا داسې غواړئ:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # only if your builds genuinely need sudo

هر څه نصب کړئ چې ستاسو جوړونې ورته اړتیا لري — د ژبې toolchain، Docker، د جوړونې وسیلې. د بیلګې په توګه، که ستاسو jobونه کانټینرونه جوړوي:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

۲. runner ښکته او راجستر کړئ

ستاسو په repo (یا org) کې په GitHub، Settings → Actions → Runners → New self-hosted runner ته لاړ شئ. GitHub تاسو ته دقیق د ښکته کولو کمانډونه او یو د راجستر نښه درکوي (دا لنډ-عمره دی — تازه یې واخلئ). د runner کاروونکي په توګه:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# use the exact URL GitHub shows you for your OS/arch:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh د یوه runner نوم، لیبلونو، او یوه کاري فولډر پوښتنه کوي — ډیفالټونه یې د پیل لپاره سم دي. لیبلونه هغه څنګه دي چې ستاسو workflow دا runner هدف کوي (runs-on: self-hosted).

۳. دا د یوه systemd خدمت په توګه وچلوئ

runner یو مرستندوی سره راځي چې تاسو لپاره یو systemd خدمت نصبوي — هغه وکاروئ، نو runner د بیا پیلونو ژوندی پاتې کیږي او په ناکامۍ بیا پیلیږي. لا هم د runner کاروونکي نصب، خو د خدمت کمانډونه root ته اړتیا لري:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

دا actions.runner.* د یوه systemd unit په توګه راجستروي چې د runner کاروونکي په توګه چلیږي، په boot پیلیږي. logونه journald ته ځي:

sudo journalctl -u 'actions.runner.*' -f

بیرته د GitHub Runners پاڼه کې، ستاسو runner اوس Idle ښیي — شنه ټکی. یو workflow ورته اشاره کړئ:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

Push، او job ستاسو په box چلیږي.

۴. پاک یې وساتئ

یو ځان-کوربه شوی runner خپل فایل‌سیسټم د jobونو ترمنځ بیا کاروي — دا د سرعت ګټه ده (تود کیشونه) او footgun (پاتې حالت). دوه عادتونه یې روغ ساتي:

که تاسو د هر job لپاره یو واقعاً پاک چاپیریال ته اړتیا لرئ، هر job د یوه کانټینر ګام دننه وچلوئ — runner پاتې کیږي، د job ګډوډي نه.

کله ځان-کوربه کړئ، په ریښتیا

هغه وخت ځان-کوربه کړئ چې تاسو خپل toolchain پکې پخ شوی، خصوصي شبکه سرچینو ته لاسرسی، یا د ماشین کنټرول ته اړتیا ولرئ. په GitHub-کوربه شوي runnerونو پاتې شئ کله چې یو پاک، غورځولو وړ چاپیریال او د دوی دقیقې تاسو سره سم وي — دا په ریښتیا ساده دی، او ساده یو ارزښت لري. او هیڅکله، په یوه عامه repo، ځان-کوربه مه کوئ. هغه یو غوره‌توب نه دی.

که یو خصوصي-repo runner هغه څه وي چې تاسو ورته اړتیا لرئ: یو پلان وټاکئSmall ($8) د سپکو جوړونو لپاره، Medium ($12) کله چې درنه شي — په USDC یا USDT تادیه وکړئ (بې KYC، بې اسنادو)، او تاسو به شاوخوا ۶۰ ثانیو کې root ولرئ. بیا د دې پاڼې لاندې کار وکړئ او تاسو به یو څو دقیقې وروسته یو runner ولرئ چې jobونه اخلي.

پلان وګورئ او یو VPS امر کړئ →

پوښتنې

ولې د GitHub-کوربه شوي پر ځای خپل runner وچلوم؟

درې ریښتیني دلایل: ستاسو خپل وابستګۍ او toolchain پکې پخ شوي (نه یې هره کاله بیا نصبول)، خصوصي سرچینو ته لاسرسی لکه یو داخلي راجستري یا ډیټابیس، او د ماشین کنټرول — د هغه اندازه، د هغه کیشونه، د هغه شبکه. که GitHub-کوربه شوي دقیقې او یو پاک چاپیریال ستاسو سره سم وي، په هغو پاتې شئ. هغه وخت ځان-کوربه کړئ چې تاسو په ځانګړي توګه د هغو درېو څخه یو ته اړتیا ولرئ.

ایا د یوه ځان-کوربه شوي runner کارول خوندي دي؟

په یوه خصوصي repo، هو. په یوه عامه repo، نه — هیڅکله. یو workflow د هر چا لخوا چې یې پیلوي خپل‌سري کوډ چلوي، او په یوه عامه repo د یوه اجنبي pull request کولی شي د دوی کوډ ستاسو په runner وچلوي. د GitHub خپل اسناد همدا وايي. ځان-کوربه شوي runnerونه خصوصي reposونو ته وساتئ، یا ومنئ چې تاسو خپل box انټرنیټ ته سپارئ.

یو runner څومره CPU او RAM ته اړتیا لري؟

په بشپړه توګه د ستاسو د جوړونې پورې اړه لري. یو عادي compile-او-test job د 2 هستو او 4-8 GB سره آرام دی — دلته Small یا Medium. درنه جوړونې (لوی native compileونه، لوی Docker تصویرونه، د حافظې-تږي د ازموینې سیټونه) نور غواړي، او تاسو باید خپل اصلي job ته اندازه کړئ، نه یو اټکل. یو ریښتینی چلونه وګورئ او تاسو به پوه شئ.

ایا یو runner کولی شي څو reposونه اداره کړي؟

یو runner کولی شي یوې سازمان ته راجستر شي او د څو reposونو لخوا واخیستل شي، په ډیفالټ یو ځل یو job. د نور موازیوالي لپاره، نور runnerونه وچلوئ — هر یو خپل systemd خدمت دی. یوازې دوی ټول خصوصي reposونو ته وساتئ.

ایا زه باید تاسو ته یو ID درکړم؟

نه. راجستر لپاره بریښنالیک، تادیې لپاره USDC یا USDT. بې اسنادو، شاوخوا یوه دقیقه کې root.

← بلاګ ته بیرتهپلانونه او بیې وګورئ →

تبصرې

لا تبصرې نشته. لومړی اوسئ.

یوه تبصره پریږدئ

تبصرې د ښکاره کیدو مخکې اعتدال کیږي.