GitHub-hosted کے بجائے اپنا runner کیوں چلاؤں؟

تین حقیقی وجوہات: آپ کی اپنی dependencies اور toolchain اندر پکی (ہر run پر انہیں دوبارہ انسٹال نہیں)، ایک اندرونی registry یا database جیسے نجی وسائل تک رسائی، اور مشین پر کنٹرول — اس کا size، اس کے caches، اس کا network۔ اگر GitHub-hosted منٹ اور ایک صاف ماحول آپ کے مطابق ہوں، تو ان پر رہیں۔ Self-host تب کریں جب آپ کو خاص طور پر ان تینوں میں سے ایک چاہیے۔

کیا ایک self-hosted runner استعمال کرنا محفوظ ہے؟

ایک private repo پر، جی ہاں۔ ایک public repo پر، نہیں — کبھی نہیں۔ ایک workflow جو کوئی بھی trigger کرے اُس کا صوابدیدی code چلاتا ہے، اور ایک public repo پر ایک اجنبی کی pull request اُن کا code آپ کے runner پر چلا سکتی ہے۔ GitHub کی اپنی docs یہی کہتی ہیں۔ self-hosted runners کو private repos تک رکھیں، یا قبول کریں کہ آپ اپنا باکس انٹرنیٹ کو دے رہے ہیں۔

ایک runner کو کتنا CPU اور RAM چاہیے؟

مکمل طور پر آپ کے build پر منحصر۔ ایک عام compile-and-test job 2 cores اور 4-8 GB سے آرام دہ ہے — یہاں Small یا Medium۔ بھاری builds (بڑے native compiles، بڑی Docker images، memory-ہنگری test suites) زیادہ چاہتے ہیں، اور آپ کو اپنے دراصل job کے لیے size کرنا چاہیے، ایک اندازے کے لیے نہیں۔ ایک حقیقی run دیکھیں اور آپ کو پتہ چل جائے گا۔

کیا ایک runner متعدد repos سنبھال سکتا ہے؟

ایک runner ایک organization سے register ہو کر کئی repos کے ذریعے اٹھایا جا سکتا ہے، ڈیفالٹ ایک وقت میں ایک job۔ زیادہ parallelism کے لیے، زیادہ runners چلائیں — ہر ایک اپنی systemd سروس۔ بس انہیں سب private repos پر رکھیں۔

کیا مجھے آپ کو ایک ID دینا ہوگا؟

نہیں۔ sign up کو ای میل، ادا کرنے کو USDC یا USDT۔ کوئی دستاویزات نہیں، تقریباً ایک منٹ میں root۔

ایک VPS پر ایک Self-Hosted GitHub Actions Runner چلانا

GitHub-hosted runners ایک ٹھیک ڈیفالٹ ہیں۔ آپ کو ان کی ضرورت اُس لمحے رکنا شروع ہوتی ہے جب ایک build کو کچھ ایسا چاہیے جو ان کے پاس نہیں — آپ کی نجی package registry، ایک مخصوص toolchain ورژن جسے ہر run پر دوبارہ انسٹال کرنے سے آپ تھک گئے، آپ کے اپنے network پر ایک database، یا بس مشین پر زیادہ کنٹرول۔ تبھی ایک VPS پر ایک self-hosted runner اپنا حق کماتا ہے۔

یہ گائیڈ ایک کو صحیح چلاتی ہے: انسٹال، register، systemd کے تحت زندہ، اور — وہ حصہ جو لوگ غلط کرتے ہیں — محفوظ۔ آئیے اُس آخری سے شروع کریں، کیونکہ یہ وہ حصہ ہے جو کاٹتا ہے۔

وہ ایک سیکیورٹی قاعدہ

ایک GitHub Actions workflow صوابدیدی code چلاتا ہے — جو کچھ بھی workflow فائل میں ہو، اور جو کچھ بھی وہ code کھینچے۔ آپ کے اپنے repo پر یہ آپ کا code ہے، اور یہ ٹھیک ہے۔ ایک public repo پر، ایک اجنبی کی ایک pull request ان کا code آپ کے runner پر چلا سکتی ہے۔ یہ ایک bug نہیں؛ یہ ہے کہ CI کیسے کام کرتا ہے۔ GitHub کی اپنی دستاویزات صاف کہتی ہیں: public repositories کے ساتھ self-hosted runners استعمال نہ کریں۔

تو قاعدہ سادہ اور ناقابلِ-مذاکرہ ہے: self-hosted runners private repos کے لیے ہیں۔ اگر آپ کا repo public ہے، تو GitHub-hosted runners استعمال کریں اور آگے بڑھیں۔ نیچے سب کچھ ایک private repo فرض کرتا ہے۔

ایک runner کو باکس سے کیا چاہیے

یہ build پر منحصر ہے، اور آپ کو ایک صفحے کے نمبر کے بجائے اپنے کے لیے size کرنا چاہیے:

ایک عام compile-and-test job — 2 cores اور 4-8 GB آرام دہ۔ Small ($8، 4 vCPU / 4 GB) یا Medium ($12، 6 vCPU / 6 GB) ان میں سے زیادہ تر کور کرتا ہے۔
بھاری builds — بڑے native compiles، بڑی Docker image builds، memory-ہنگری test suites — زیادہ headroom چاہتے ہیں۔ ایک حقیقی run دیکھیں (htop جب یہ build کرے) اور جو آپ دراصل دیکھیں اُس کے لیے size کریں، امید کے لیے نہیں۔

ڈسک بھی اہم ہے: build caches، Docker layers، اور cloned repos جمع ہوتے ہیں۔ اس پر نظر رکھیں اور prune کریں۔

1. باکس تیار کریں

runner کے لیے ایک non-root user بنائیں — GitHub کا installer ویسے بھی root کے طور پر چلنے سے انکار کرتا ہے، اور آپ اسے ایسا چاہتے ہیں:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # صرف اگر آپ کے builds کو واقعی sudo چاہیے

جو کچھ بھی آپ کے builds کو چاہیے انسٹال کریں — ایک language toolchain، Docker، build tools۔ مثلاً، اگر آپ کے jobs containers بناتے ہیں:

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

2. runner ڈاؤنلوڈ اور register کریں

GitHub پر اپنے repo (یا org) میں، Settings → Actions → Runners → New self-hosted runner پر جائیں۔ GitHub آپ کو بالکل ڈاؤنلوڈ کمانڈز اور ایک registration token دیتا ہے (یہ مختصر-مدتی ہے — اسے تازہ لیں)۔ runner user کے طور پر:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# اپنے OS/arch کے لیے GitHub جو بالکل URL دکھائے وہ استعمال کریں:
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 نام، labels، اور ایک work folder مانگتا ہے — شروع کرنے کو defaults ٹھیک ہیں۔ Labels یہ ہیں کہ آپ کا workflow اس runner کو کیسے نشانہ بناتا ہے (runs-on: self-hosted)۔

3. اسے ایک systemd سروس کے طور پر چلائیں

runner ایک helper کے ساتھ آتا ہے جو آپ کے لیے ایک systemd سروس انسٹال کرتا ہے — اسے استعمال کریں، تاکہ runner reboots سے بچے اور ناکامی پر restart ہو۔ پھر بھی runner user کے install کے طور پر، لیکن سروس کمانڈز کو root چاہیے:

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

یہ actions.runner.* کو runner user کے طور پر چلتی ایک systemd unit کے طور پر register کرتا ہے، boot پر شروع ہوتی۔ Logs 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 آپ کے باکس پر چلتا ہے۔

4. اسے صاف رکھیں

ایک self-hosted runner jobs کے بیچ اپنا filesystem دوبارہ استعمال کرتا ہے — یہی رفتار کی جیت (گرم caches) اور footgun (بچی-کھچی state) ہے۔ دو عادات اسے صحت مند رکھتی ہیں:

باقاعدگی سے Prune کریں۔ خاص طور پر Docker — ایک cron پر docker system prune، ورنہ ڈسک خاموشی سے مردہ layers سے بھر جاتا ہے۔
باکس پر secrets ذخیرہ نہ کریں۔ GitHub Actions secrets استعمال کریں، فی-run injected، runner کے home میں پڑی فائلیں نہیں۔ اگر runner سمجھوتہ ہو، تو ڈسک پر جو کچھ ہو وہ اس کے ساتھ جاتا ہے۔

اگر آپ کو فی job ایک واقعی صاف ماحول چاہیے، تو ہر job کو ایک container step کے اندر چلائیں — runner رہتا ہے، job کی گندگی نہیں۔

کب self-host کریں، ایمانداری سے

Self-host تب کریں جب آپ کو اپنا toolchain اندر پکا، نجی network وسائل تک رسائی، یا مشین پر کنٹرول چاہیے۔ GitHub-hosted runners پر رہیں جب ایک صاف، throwaway ماحول اور ان کے منٹ آپ کے مطابق ہوں — یہ حقیقتاً سادہ تر ہے، اور سادہ تر کچھ اہمیت رکھتا ہے۔ اور کبھی، ایک public repo پر، self-host نہ کریں۔ وہ ایک ترجیح نہیں۔

اگر ایک private-repo runner وہ ہے جو آپ کو چاہیے: ایک پلان چنیں — ہلکے builds کے لیے Small ($8)، جب وہ بھاری ہوں تو Medium ($12) — USDC یا USDT میں ادا کریں (کوئی KYC، کوئی دستاویزات نہیں)، اور آپ کے پاس تقریباً 60 سیکنڈ میں root ہوگا۔ پھر اس صفحے پر نیچے کام کریں اور آپ کے پاس چند منٹ بعد jobs اٹھاتا ایک runner ہوگا۔

پلان دیکھیں اور VPS آرڈر کریں ←