GitHub self-hosted रनर: Linux सेटअप, Docker और Kubernetes

GitHub self-hosted रनर, GitHub के ओपन सोर्स actions/runner एजेंट से आपकी दी हुई मशीन पर GitHub Actions जॉब चलाता है। काम पाने के लिए रनर HTTPS पर GitHub से आउटबाउंड कनेक्शन बनाता है। 4 नवंबर 2026 तक, GitHub के बिलिंग डॉक्स के अनुसार self-hosted रनर का कंप्यूट मुफ़्त है; मशीन और उसके रखरखाव का खर्च आप देते हैं। GitHub रनर रेफ़रेंस, GitHub Actions बिलिंग।

Lizard हम बनाते हैं, जो GitHub Actions रनर बेचता है; कीमतें 4 नवंबर 2026 को जांची गई थीं।

सबसे सीधा तरीका है एक Linux VM, अपनी रिपॉज़िटरी की सेटिंग्स से रजिस्ट्रेशन टोकन, और मेल खाते रनर लेबल वाला वर्कफ़्लो। शुरुआत एक प्राइवेट टेस्ट रिपॉज़िटरी से करें। कई रनर के लिए ephemeral VM, ARC के साथ Kubernetes या AWS Terraform मॉड्यूल चुनें। मौजूदा रनर के लिए सीधे सुरक्षा, समस्या का हल या मशीन की लागत पर जाएँ।

Self-hosted रनर बनाम GitHub पर होस्टेड रनर

GitHub हर होस्टेड जॉब के लिए नया एनवायरनमेंट तैयार करता है और उसका रखरखाव करता है। Self-hosted रनर में मशीन देना, पैच लगाना और उसे सुरक्षित रखना आपका काम है।

सोर्स: GitHub का self-hosted रनर ओवरव्यू, होस्टेड रनर ओवरव्यू और बिलिंग डॉक्स।

अगर आपका ओपन सोर्स प्रोजेक्ट पहले से मुफ़्त चल रहा है या आपकी टीम बिल्ड मशीनों का रखरखाव नहीं करना चाहती, तो GitHub पर होस्टेड रनर इस्तेमाल करते रहें। Self-hosting तब सही है जब आपको खास हार्डवेयर या प्राइवेट नेटवर्क तक ऐक्सेस चाहिए, या आपके पास इतना नियमित काम हो कि मशीनें खुद चलाना उचित लगे।

कौन-सा सेटअप सही है?

Linux पर GitHub Actions self-hosted रनर कैसे सेट अप करें?

GitHub Actions self-hosted रनर जोड़ने के लिए:

1. अपनी रिपॉज़िटरी में Settings → Actions → Runners → New self-hosted runner खोलें।
2. actions/runner डाउनलोड करें और उसका SHA-256 चेकसम जांचें।
3. ./config.sh, रिपॉज़िटरी URL और पेज के रजिस्ट्रेशन टोकन से उसे रजिस्टर करें।
4. ./run.sh शुरू करें और पुष्टि करें कि वह जॉब का इंतज़ार कर रहा है।
5. नीचे दिए गए कस्टम लेबल से मेल खाते runs-on: [self-hosted, linux, x64, linux-build] के साथ एक जॉब भेजें।

systemd वाली Ubuntu 24.04 या Debian 12 x64 VM इस्तेमाल करें। ऐसे सामान्य, non-root यूज़र के तौर पर लॉग इन करें जो sudo इस्तेमाल कर सके। आपके पास एक प्राइवेट GitHub रिपॉज़िटरी होनी चाहिए जिसके आप एडमिन हों, आउटबाउंड इंटरनेट ऐक्सेस हो, और बिल्ड के लिए पर्याप्त डिस्क और मेमोरी हो। GitHub की रनर संबंधी ज़रूरी शर्तों में दोनों ऑपरेटिंग सिस्टम का सपोर्ट है और पोर्ट 443 पर आउटबाउंड HTTPS ज़रूरी है। रनर को इनबाउंड वेबहुक पोर्ट की ज़रूरत नहीं है।

4 नवंबर 2026 को हमने systemd और actions/runner v2.338.2 वाली नई Debian 12 x64 VM पर ये स्टेप टेस्ट किए: डाउनलोड और चेकसम, प्राइवेट टेस्ट रिपॉज़िटरी में रजिस्ट्रेशन, स्मोक-टेस्ट वर्कफ़्लो, सर्विस इंस्टॉल करना, हटाना और रिपॉज़िटरी स्तर का JIT रनर। नीचे दिए गए आउटपुट उसी टेस्ट के अंश हैं; हमारे टेस्ट का लॉगिन नाम builder था।

रनर डाउनलोड करें और उसकी जांच करें

रिपॉज़िटरी में Settings → Actions → Runners → New self-hosted runner खोलें, फिर Linux और x64 चुनें। ऑर्गनाइज़ेशन रनर के लिए ऑर्गनाइज़ेशन की सेटिंग्स और ऑर्गनाइज़ेशन ओनर अकाउंट इस्तेमाल करें। Enterprise एडमिन Enterprise स्तर पर भी रनर जोड़ सकते हैं। GitHub के सेटअप निर्देश हर स्कोप समझाते हैं।

अपने non-root लॉगिन से Bash में यह चलाएँ। यह GitHub की रिलीज़ API से मौजूदा रिलीज़ और उसका SHA-256 डाइजेस्ट लेता है, फिर आर्काइव एक्सट्रैक्ट करने से पहले उसकी जांच करता है:

sudo apt-get update
sudo apt-get install -y ca-certificates curl jq
mkdir actions-runner
cd actions-runner
curl -fsSL https://api.github.com/repos/actions/runner/releases/latest -o release.json
RUNNER_VERSION=$(jq -er '.tag_name | ltrimstr("v")' release.json)
RUNNER_TARBALL="actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz"
RUNNER_URL=$(jq -er --arg name "$RUNNER_TARBALL" \
  '.assets[] | select(.name == $name) | .browser_download_url' release.json)
RUNNER_SHA=$(jq -er --arg name "$RUNNER_TARBALL" \
  '.assets[] | select(.name == $name) | .digest | select(startswith("sha256:")) | ltrimstr("sha256:")' release.json)
curl -fsSL "$RUNNER_URL" -o "$RUNNER_TARBALL"
printf '%s  %s\n' "$RUNNER_SHA" "$RUNNER_TARBALL" | sha256sum -c - && \
  tar xzf "$RUNNER_TARBALL" && \
  sudo ./bin/installdependencies.sh && \
  ./config.sh --help

अपेक्षित नतीजा: actions-runner-linux-x64-2.338.2.tar.gz: OK। चेकसम सही मिलने पर ही एक्सट्रैक्शन होता है; जांच फ़ेल हो या GitHub डाइजेस्ट न दे तो रुकें। रिलीज़ धीरे-धीरे रोल आउट होती हैं, इसलिए ज़रूरत पड़ने पर अपनी रिपॉज़िटरी के सेटअप पेज का वर्ज़न और चेकसम इस्तेमाल करें। GitHub रनर रिलीज़।

Debian 12 पर installdependencies.sh ने ICU के वर्ज़न आज़माते समय E: Unable to locate package libicu80 और ऐसी ही लाइनें दिखाई थीं, फिर उसे libicu72 मिल गया। हमारे टेस्ट में फ़ॉलबैक के ये प्रयास अपेक्षित थे; जांचें कि स्क्रिप्ट सफलतापूर्वक पूरी होती है।

रजिस्टर करें और जॉब का इंतज़ार शुरू करें

सेटअप पेज से रजिस्ट्रेशन टोकन कॉपी करें। GitHub के अनुसार यह टोकन एक घंटे बाद एक्सपायर हो जाता है। यह रनर रजिस्ट्रेशन टोकन है, पर्सनल ऐक्सेस टोकन नहीं। नीचे YOUR_OWNER/YOUR_REPO की जगह रिपॉज़िटरी का पाथ डालें; ऑर्गनाइज़ेशन स्कोप के लिए https://github.com/YOUR_ORG इस्तेमाल करें।

read -rsp 'Registration token: ' RUNNER_TOKEN
printf '\n'
./config.sh --unattended \
  --url https://github.com/YOUR_OWNER/YOUR_REPO \
  --token "$RUNNER_TOKEN" \
  --name linux-build-01 \
  --labels linux-build
unset RUNNER_TOKEN
./run.sh

अपेक्षित नतीजा: √ Connected to GitHub, √ Runner successfully added, √ Settings Saved., फिर ./run.sh के बाद Listening for Jobs। कनेक्ट होने और तैयार होने पर Settings → Actions → Runners में Idle देखें। पहले जॉब के लिए टर्मिनल चालू रहने दें। रजिस्ट्रेशन, रनर की स्थिति।

उसे एक जॉब भेजें

इस फ़ाइल को अपनी रिपॉज़िटरी की डिफ़ॉल्ट ब्रांच पर .github/workflows/runner-check.yml नाम से कमिट करें:

name: Check self-hosted runner
on:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  check:
    runs-on: [self-hosted, linux, x64, linux-build]
    steps:
      - name: Show the execution environment
        run: |
          echo "Runner accepted the job"
          uname -s -m
          whoami

Actions → Check self-hosted runner → Run workflow खोलें। हमारे टेस्ट का अपेक्षित नतीजा: Runner accepted the job / Linux x86_64 / builder। आपका लॉगिन नाम अलग हो सकता है। इस स्मोक टेस्ट के लिए चेकआउट या टूलचेन की ज़रूरत नहीं है; अपने बिल्ड के लिए उन्हें जोड़ें। अगर यह क्यू में ही रहे, तो जॉब के इंतज़ार करने की वजह देखें।

GitHub runs-on सूची के सभी लेबल का मिलान करता है। रनर को रजिस्ट्रेशन से self-hosted, linux और x64 मिलते हैं; linux-build हमारे उदाहरण का कस्टम लेबल है। लेबल रनर के बारे में बताता है, लेकिन सॉफ़्टवेयर इंस्टॉल नहीं करता या रिपॉज़िटरी का ऐक्सेस नहीं देता। GitHub वर्कफ़्लो रूटिंग।

उसे सर्विस के तौर पर चालू रखें

टेस्ट पूरा होने के बाद Ctrl-C दबाएँ और सर्विस शुरू करने से पहले पुष्टि करें कि फ़ोरग्राउंड में चल रहा ./run.sh लिसनर बंद हो चुका है। वरना जर्नल में A session for this runner already exists. और Conflict दिख सकते हैं, जबकि पुराना लिसनर जॉब लेता रहता है। हमारे टेस्ट में ऐसा हुआ था। उसी non-root लॉगिन से रनर डायरेक्टरी में:

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

अपेक्षित नतीजा: svc.sh status से Active: active (running)। GitHub रजिस्ट्रेशन के बाद svc.sh बनाता है; systemd पर ये कमांड लॉगआउट और रीबूट के बाद भी रनर चालू रखती हैं। GitHub सर्विस सेटअप।

रनर हटाएँ

Settings → Actions → Runners में रनर चुनें और हटाने का टोकन पाने के लिए Remove पर क्लिक करें। उसकी डायरेक्टरी से सर्विस रोकें और अनइंस्टॉल करें, फिर रजिस्ट्रेशन हटाएँ:

sudo ./svc.sh stop
sudo ./svc.sh uninstall
read -rsp 'Removal token: ' REMOVAL_TOKEN
printf '\n'
./config.sh remove --token "$REMOVAL_TOKEN"
unset REMOVAL_TOKEN

अपेक्षित नतीजा: √ Runner removed successfully, √ Removed .credentials, √ Removed .runner। GitHub के रनर हटाने के निर्देश UI का तरीका बताते हैं; ऑटोमेशन रिपॉज़िटरी से हटाने का टोकन मांग सकता है।

रनर ग्रुप और लेबल में क्या फ़र्क है?

GitHub Actions रनर ग्रुप यह नियंत्रित करता है कि कौन-सी रिपॉज़िटरी रनर के किसी समूह को इस्तेमाल कर सकती हैं। लेबल उस अनुमति वाले समूह के अंदर रनर चुनने में मदद करते हैं। ऑर्गनाइज़ेशन रनर के लिए Settings → Actions → Runner groups खोलें, ग्रुप चुनें और Repository access सिर्फ़ उन रिपॉज़िटरी तक सीमित करें जिन्हें इसकी ज़रूरत है। GitHub रनर ग्रुप के नियंत्रण।

ऑर्गनाइज़ेशन रनर के लिए trusted-builds नाम का ग्रुप बनाएँ, फिर --url https://github.com/YOUR_ORG --runnergroup trusted-builds से रजिस्टर करें। ग्रुप पहले से मौजूद होना चाहिए; यह फ़्लैग ऊपर दिए गए रिपॉज़िटरी स्कोप वाले सेटअप पर लागू नहीं होता। एक जॉब ग्रुप और लेबल, दोनों की मांग कर सकता है:

runs-on:
  group: trusted-builds
  labels: linux-build

रिलीज़ जॉब को कम भरोसेमंद रिपॉज़िटरी के इस्तेमाल वाले रनर से दूर रखें। ग्रुप यह सीमित करते हैं कि कौन काम शेड्यूल कर सकता है; वे प्रोसेस अलग नहीं करते या साझा डिस्क को सुरक्षित नहीं बनाते। GitHub के रूटिंग डॉक्स के अनुसार ग्रुप का ऐक्सेस और मेल खाते लेबल, दोनों ज़रूरी हैं।

Ephemeral और जस्ट-इन-टाइम रनर कैसे काम करते हैं?

Ephemeral रनर एक जॉब स्वीकार करता है, फिर GitHub उसका रजिस्ट्रेशन हटा देता है; इसे --ephemeral से चालू करें। VM मिटाना या उसकी डिस्क साफ़ करना फिर भी आपके इंफ़्रास्ट्रक्चर की ज़िम्मेदारी है। GitHub ऑटोस्केलिंग के लिए ephemeral रनर सुझाता है और प्रोडक्शन में इस्तेमाल से पहले उनके लॉग बाहर सुरक्षित रखने को कहता है। GitHub ऑटोस्केलिंग रेफ़रेंस।

अगर आपने उसी linux-build लेबल वाला कोई पुराना रनर रखा हुआ है, तो sudo ./svc.sh stop से उसकी सर्विस रोकें, या नए रनर और वर्कफ़्लो, दोनों में अलग लेबल इस्तेमाल करें। वरना GitHub टेस्ट जॉब पुराने रनर को भेज सकता है। नई VM और अभी तक कॉन्फ़िगर न की गई रनर डायरेक्टरी पर नया रजिस्ट्रेशन टोकन इस्तेमाल करें:

read -rsp 'Registration token: ' RUNNER_TOKEN
printf '\n'
./config.sh --unattended \
  --url https://github.com/YOUR_OWNER/YOUR_REPO \
  --token "$RUNNER_TOKEN" \
  --name "ephemeral-$(hostname)" \
  --labels linux-build \
  --ephemeral
unset RUNNER_TOKEN
./run.sh

लिसनर बंद होने पर मशीन मिटा दें, विफलता के बाद भी। जॉब रद्द होने और कभी जॉब न पाने वाली मशीनों की स्थिति भी संभालें। उसी बिना साफ़ की गई VM को फिर से रजिस्टर करने से साफ़ एनवायरनमेंट नहीं बनता।

API से जस्ट-इन-टाइम कॉन्फ़िगरेशन जनरेट करें

JIT रनर को स्टार्टअप पर उसका कॉन्फ़िगरेशन मिलता है और वह अधिकतम एक जॉब चला सकता है। प्रोविज़नर, वर्कर पर लंबे समय तक मान्य रहने वाला GitHub API क्रेडेंशियल रखे बिना वह कॉन्फ़िगरेशन ले सकता है। GitHub फिर भी चेतावनी देता है कि उसी हार्डवेयर को दोबारा इस्तेमाल करने के लिए साफ़ एनवायरनमेंट ज़रूरी है। GitHub JIT सुरक्षा गाइड।

ऑर्गनाइज़ेशन स्तर के इस उदाहरण के लिए उस ऑर्गनाइज़ेशन के लिए अधिकृत API टोकन इस्तेमाल करें, जिसमें Self-hosted runners: write परमिशन हो। ऑर्गनाइज़ेशन एडमिन टेस्ट के लिए fine-grained टोकन इस्तेमाल कर सकता है; ऑटोमेशन में GitHub App इंस्टॉलेशन टोकन इस्तेमाल करें। GitHub की रनर ग्रुप API से ग्रुप की संख्या वाली ID लें और पहले उस ग्रुप का रिपॉज़िटरी ऐक्सेस सीमित करें।

Bash में ऑर्गनाइज़ेशन और ग्रुप के प्लेसहोल्डर बदलें। इसे नई मशीन की रनर डायरेक्टरी से चलाएँ (पहले डाउनलोड वाला ब्लॉक दोहराएँ), और सिर्फ़ भरोसेमंद टेस्ट के लिए; प्रोडक्शन में API रिक्वेस्ट प्रोविज़नर में चलाएँ और वर्कर तक सिर्फ़ वापस मिला कॉन्फ़िगरेशन पहुँचाएँ।

ORG='YOUR_ORG'
RUNNER_GROUP_ID='REPLACE_WITH_NUMERIC_GROUP_ID'
read -rsp 'GitHub API token: ' GH_API_TOKEN
printf '\n'
JIT_CONFIG=$(
  jq -n --arg name "jit-$(date +%s)" --argjson group "$RUNNER_GROUP_ID" \
    '{name: $name, runner_group_id: $group,
      labels: ["self-hosted", "linux", "x64", "linux-build"],
      work_folder: "_work"}' |
  curl -fsSL -X POST \
    -H 'Accept: application/vnd.github+json' \
    -H "Authorization: Bearer $GH_API_TOKEN" \
    -H 'X-GitHub-Api-Version: 2026-03-10' \
    --data-binary @- \
    "https://api.github.com/orgs/$ORG/actions/runners/generate-jitconfig" |
  jq -er '.encoded_jit_config'
)
unset GH_API_TOKEN
[ -n "$JIT_CONFIG" ] && ./run.sh --jitconfig "$JIT_CONFIG"
unset JIT_CONFIG

GitHub के डॉक्स में यह ऑर्गनाइज़ेशन JIT रिक्वेस्ट और एक रिपॉज़िटरी के टेस्ट के लिए रिपॉज़िटरी स्तर का JIT एंडपॉइंट दिया गया है; हमारे टेस्ट में दूसरे वाले को runner_group_id: 1 के साथ इस्तेमाल किया गया था। --jitconfig फ़्लैग काम करता है, भले ही ./run.sh --help में वह नहीं दिखता। एन्कोड किए गए कॉन्फ़िगरेशन को सीक्रेट की तरह रखें; रूटिंग अब भी स्कोप, ग्रुप और लेबल पर निर्भर करती है।

JIT जॉब के बाद अपेक्षित नतीजा: Job check completed with result: Succeeded, √ Removed .credentials, √ Removed .runner, फिर Runner listener exit with 0 return code, stop the service, no retry needed. और Exiting runner...।

Docker में self-hosted GitHub रनर कैसे चलाएँ?

GitHub जिस ghcr.io/actions/actions-runner इमेज का रखरखाव करता है, वह एजेंट को कंटेनर में चलाती है। इस उदाहरण में टैग 2.338.2 इस्तेमाल किया गया है, जो 4 नवंबर 2026 को रनर की सबसे नई रिलीज़ थी; हमने उसका Linux x64 मैनिफ़ेस्ट जांचा है, लेकिन उससे Docker जॉब नहीं चलाया है।

पहले Docker के Ubuntu निर्देशों या Debian निर्देशों से Docker Engine इंस्टॉल करें। कमांड sudo इस्तेमाल करती है; Docker का वैकल्पिक docker-group सेटअप root स्तर का ऐक्सेस देता है।

JIT रिक्वेस्ट इस्तेमाल करके GitHub की generate-jitconfig API से एक जॉब के लिए नया कॉन्फ़िगरेशन लें, लेकिन उसमें लोकल रनर शुरू करने और unset JIT_CONFIG वाली लाइनें छोड़ दें। वापस मिला कॉन्फ़िगरेशन JIT_CONFIG में रखकर यह चलाएँ:

sudo docker run --rm --init --platform linux/amd64 \
  --entrypoint /home/runner/run.sh \
  ghcr.io/actions/actions-runner:2.338.2 \
  --jitconfig "$JIT_CONFIG"
unset JIT_CONFIG

स्मोक-टेस्ट वर्कफ़्लो कंटेनर के लेबल पर भेजें। यह इमेज के runner यूज़र के तौर पर चलता है, कोई पर्सिस्टेंट वर्कस्पेस नहीं जोड़ता और बंद होने पर हट जाता है। GitHub के इमेज सोर्स में उसके टूल की सूची है; इससे बनी इमेज में बिल्ड डिपेंडेंसी जोड़ें।

एजेंट को Docker में चलाना, वर्कफ़्लो की container: सेटिंग से जॉब के स्टेप Docker में चलाने से अलग है। Docker कंटेनर ऐक्शन और सर्विस कंटेनर के लिए GitHub को Linux और काम करता हुआ Docker इंस्टॉलेशन चाहिए। ऊपर की कमांड नेस्टेड कंटेनर जॉब के लिए Docker डेमन कॉन्फ़िगर नहीं करती। GitHub कंटेनर जॉब।

होस्ट का Docker सॉकेट माउंट करने से जॉब का कोड उस डेमन को नियंत्रित कर सकता है, जिससे होस्ट का फ़ाइलसिस्टम खुल सकता है। Docker-in-Docker में अक्सर प्रिविलेज्ड कंटेनर चाहिए और उसके लिए डिस्क, नेटवर्किंग और सफ़ाई की अपनी योजना चाहिए। इनमें से कोई भी तरीका सामान्य साझा Docker होस्ट को नुकसान पहुँचाने वाले pull request के लिए सुरक्षित नहीं बनाता। जिस काम पर भरोसा न हो, उसके लिए अलग-थलग, इस्तेमाल के बाद मिटाई जाने वाली VM से सुरक्षा की सीमा बनाएँ और Docker की डेमन सुरक्षा गाइड पढ़ें।

Actions Runner Controller से Kubernetes पर ऑटोस्केल कैसे करें?

Actions Runner Controller (ARC), self-hosted GitHub Actions रनर के लिए ओपन सोर्स Kubernetes कंट्रोलर है, जिसका रखरखाव GitHub और कम्युनिटी के योगदानकर्ता करते हैं। यह क्यू में मौजूद जॉब के लिए रनर पॉड बनाता है और आपकी minRunners और maxRunners सेटिंग्स के अंदर रनर की संख्या घटाता-बढ़ाता है, कॉन्फ़िगर करने पर शून्य तक भी। इसे तब इस्तेमाल करें जब आपकी टीम पहले से Kubernetes चलाती हो; GitHub के ARC क्विकस्टार्ट के लिए क्लस्टर और Helm 3 चाहिए। ARC आर्किटेक्चर।

कंट्रोलर को उसके अलग नेमस्पेस में इंस्टॉल करें:

helm install arc \
  --namespace arc-systems \
  --create-namespace \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller
kubectl create namespace arc-runners

ऑर्गनाइज़ेशन स्कोप वाले इस उदाहरण के लिए ऑर्गनाइज़ेशन की Self-hosted runners: read and write और रिपॉज़िटरी की Metadata: read-only परमिशन वाला GitHub App बनाएँ और इंस्टॉल करें। उसकी प्राइवेट की को लोकल मशीन पर github-app.pem नाम से सेव करें। रिपॉज़िटरी स्कोप वाले रजिस्ट्रेशन के लिए Administration: read and write भी ज़रूरी है। GitHub के ARC ऑथेंटिकेशन निर्देशों का पालन करें।

App और इंस्टॉलेशन ID बदलें, फिर रनर नेमस्पेस में सीक्रेट बनाएँ:

kubectl create secret generic arc-github-app \
  --namespace arc-runners \
  --from-literal=github_app_id=YOUR_APP_ID \
  --from-literal=github_app_installation_id=YOUR_INSTALLATION_ID \
  --from-file=github_app_private_key=./github-app.pem

इसे runner-values.yaml नाम से सेव करें। इस उदाहरण में खाली बैठे रनर की संख्या शून्य और अधिकतम रनर की संख्या चार चुनी गई है; ये आपके बजट की सेटिंग्स हैं, ARC प्रोडक्ट की सीमाएँ नहीं।

githubConfigUrl: https://github.com/YOUR_ORG
githubConfigSecret: arc-github-app
runnerScaleSetName: arc-linux
minRunners: 0
maxRunners: 4

रनर स्केल सेट इंस्टॉल करें और कंट्रोलर जांचें:

helm install arc-linux \
  --namespace arc-runners \
  --values runner-values.yaml \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set
helm list -A
kubectl get pods -n arc-systems

पहले वाले स्मोक-टेस्ट वर्कफ़्लो में लेबल की सूची को इससे बदलें:

runs-on: arc-linux

वर्कफ़्लो ट्रिगर करें और रनर नेमस्पेस पर नज़र रखें:

kubectl get pods -n arc-runners -w

GitHub के अनुसार अपेक्षित नतीजा है चलता हुआ कंट्रोलर और जॉब के लिए बना रनर पॉड। रनर पॉड की संख्या शून्य करने से क्लस्टर का बना रहने वाला खर्च खत्म नहीं होता। इन चार्ट के नाम और वैल्यू GitHub के डिप्लॉयमेंट डॉक्स और चार्ट वैल्यू से जांचे गए थे; इस लेख के लिए हमने क्लस्टर डिप्लॉय नहीं किया था।

प्रोडक्शन से पहले टेस्ट किए गए चार्ट और इमेज वर्ज़न पिन करें, कंट्रोलर और रनर के लॉग इकट्ठा करें, और अपने बिल्ड के हिसाब से पॉड की रिसोर्स रिक्वेस्ट सेट करें। GitHub App सीक्रेट का ऐक्सेस सीमित करें। कंटेनर जॉब के लिए ARC के डॉक्स में दिया गया Docker-in-Docker या Kubernetes कंटेनर मोड चुनें और उसके विशेषाधिकार जांचें। ऊपर की न्यूनतम वैल्यू इनमें से कोई भी मोड कॉन्फ़िगर नहीं करतीं।

AWS पर self-hosted रनर ऑटोस्केल कैसे करें?

terraform-aws-github-runner एक ओपन सोर्स Terraform मॉड्यूल है, जो Kubernetes के बिना आपके AWS अकाउंट में EC2 पर self-hosted रनर ऑटोस्केल करता है। उसका वेबहुक आधारित सेटअप GitHub App से क्यू में लगे जॉब के इवेंट पाता है और मांग संभालने के लिए Lambda और SQS इस्तेमाल करता है। यह ephemeral रनर और Spot इंस्टेंस सपोर्ट करता है। प्रोजेक्ट आर्किटेक्चर।

अपने सेटअप के लिए प्रोजेक्ट का उदाहरण इस्तेमाल करें और मॉड्यूल का वर्ज़न पिन करें। अपना VPC, सबनेट, GitHub App और रनर इमेज दें, फिर लागू करने से पहले IAM परमिशन और Terraform प्लान की समीक्षा करें। बीच में रुकने वाले Spot जॉब, मशीन तैयार होने में विफलताओं और प्रबंधन से छूटे हुए इंस्टेंस के लिए योजना बनाएँ। बिल में EC2, डिस्क, लॉग, नेटवर्क सर्विस और कंट्रोलर के AWS रिसोर्स शामिल करें।

यह सेटअप तब चुनें जब नीति के अनुसार रनर आपके AWS अकाउंट में ही होने चाहिए। इमेज पर पैच लगाना और विफलताएँ संभालना फिर भी आपकी टीम का काम है। इस लेख के लिए हमने यह Terraform सेटअप डिप्लॉय नहीं किया है।

क्या पब्लिक रिपॉज़िटरी के लिए self-hosted रनर सुरक्षित तरीके से इस्तेमाल कर सकते हैं?

डिफ़ॉल्ट तौर पर नहीं। GitHub self-hosted रनर सिर्फ़ प्राइवेट रिपॉज़िटरी के लिए सुझाता है, क्योंकि फ़ोर्क से आया pull request मशीन पर हमलावर के नियंत्रण वाला कोड चला सकता है। प्राइवेट रिपॉज़िटरी में भी सावधानी चाहिए: जिसे फ़ोर्क करने और pull request खोलने की अनुमति है, वह आपके रनर एनवायरनमेंट में कोड चला सकता है। GitHub सुरक्षा गाइड।

पब्लिक योगदान के लिए GitHub पर होस्टेड रनर से शुरुआत करना ज़्यादा सुरक्षित है। इस ट्यूटोरियल की पर्सिस्टेंट VM को पब्लिक रिपॉज़िटरी से न जोड़ें। अगर आपको ऐसे कोड को खुद होस्ट करना ही पड़े जिस पर भरोसा नहीं है, तो हर जॉब के लिए अलग-थलग, इस्तेमाल के बाद मिटाया जाने वाला एनवायरनमेंट रखें, जिसमें क्रेडेंशियल और नेटवर्क ऐक्सेस सीमित हों। सिर्फ़ ephemeral रजिस्ट्रेशन वह सुरक्षा की सीमा नहीं बनाता।

• SSH की, क्लाउड एडमिन क्रेडेंशियल और प्रोडक्शन डेटा रनर की डिस्क पर न रखें। जहाँ संभव हो, कम समय तक मान्य रहने वाले और सीमित स्कोप वाले क्रेडेंशियल इस्तेमाल करें।
• अलग-अलग भरोसे के स्तर वाली रिपॉज़िटरी को रनर ग्रुप और अलग एक्ज़ीक्यूशन एनवायरनमेंट से अलग रखें। कस्टम लेबल ऐक्सेस कंट्रोल नहीं है।
• प्रिविलेज्ड pull_request_target वर्कफ़्लो के तहत ऐसे pull request को चेकआउट करके न चलाएँ जिस पर भरोसा नहीं है। इवेंट परमिशन और फ़ोर्क से रन चलाने की अप्रूवल नीतियाँ जांचें।
• इंटरनल सर्विस और क्लाउड मेटाडेटा एंडपॉइंट का ऐक्सेस सीमित करें। अपने जॉब के लिए ज़रूरी GitHub एंडपॉइंट और उनकी डिपेंडेंसी रजिस्ट्री की अनुमति दें; सिर्फ़ आउटबाउंड कनेक्टिविटी होने पर भी डेटा चोरी हो सकता है।
• कैश को साझा स्टेट मानें। जिन जॉब पर भरोसा नहीं है, उन्हें ऐसा डेटा लिखने न दें जिसे बाद में कोई प्रिविलेज्ड बिल्ड चलाएगा।

ये नियंत्रण GitHub की सुरक्षित उपयोग की गाइड के अनुसार हैं। उसके कम्युनिकेशन रेफ़रेंस में रनर अपडेट, ऐक्शन, लॉग, आर्टिफ़ैक्ट और कैश के लिए ज़रूरी डोमेन दिए गए हैं।

रनर और उसकी इमेज अपडेट रखें

GitHub के रनर रेफ़रेंस के अनुसार जिन रनर में ऑटोमैटिक अपडेट बंद हैं, उन्हें नई रिलीज़ आने के 30 दिनों के अंदर अपडेट करना ज़रूरी है, पैच रिलीज़ समेत। GitHub पुराने पड़ चुके रनर को काम भेजना बंद कर देता है; अनिवार्य गंभीर सुरक्षा अपडेट की वजह से जॉब इससे पहले भी रुक सकते हैं। GitHub अपडेट नीति।

रनर आम तौर पर खुद अपडेट होता है। --disableupdate तभी इस्तेमाल करें जब आपकी टीम उस समय-सीमा के अंदर रनर इमेज दोबारा बिल्ड करती हो। एजेंट अपडेट से Ubuntu, Docker या आपके बिल्ड टूल पर पैच नहीं लगते। रखरखाव के लिए मशीनें बदलें या उन पर नए जॉब लेना रोककर चल रहे जॉब पूरे होने दें, ताकि सक्रिय जॉब बीच में न रुकें।

रनर ऑफ़लाइन क्यों है या जॉब इंतज़ार क्यों कर रहा है?

जॉब तब इंतज़ार करता है जब कोई ऑनलाइन, खाली रनर उसके लेबल और अनुमति वाले स्कोप या ग्रुप से मेल नहीं खाता। ऑफ़लाइन रनर का लिसनर बंद हो गया है या वह GitHub तक नहीं पहुँच सकता। GitHub के रूटिंग रेफ़रेंस के अनुसार क्यू में पड़े जॉब 24 घंटे से ज़्यादा समय बाद फ़ेल हो जाते हैं।

GitHub के समस्या हल करने वाले रेफ़रेंस में रनर की स्थिति, लॉग, कनेक्टिविटी और Docker परमिशन की जानकारी है।

उदाहरण के लिए, systemd मशीन पर पहले जर्नल की आखिरी 100 लाइनें देखें, फिर डायग्नोस्टिक फ़ाइलें और डिस्क उपयोग जांचें:

sudo ./svc.sh status
sudo journalctl -u "$(cat .service)" -n 100 --no-pager
ls -lt _diag/
df -h

_diag में Runner_ फ़ाइलें लिसनर की जानकारी देती हैं और Worker_ फ़ाइलें अलग-अलग जॉब की। Ephemeral रनर मिटाने से पहले इन्हें सुरक्षित रखें। अगर जॉब कभी शुरू ही नहीं हुआ, तो सबसे नया Runner_ लॉग पढ़ें; अगर शुरू होकर फ़ेल हुआ, तो उसका Worker_ लॉग और जॉब आउटपुट पढ़ें।

Self-hosted रनर की मशीन का खर्च कितना है?

मशीन और उसके रखरखाव का बजट रखें: इमेज पैच, डिस्क की सफ़ाई, मॉनिटरिंग और फ़ेल हुए जॉब।

4 नवंबर 2026 तक, प्रस्तावित शुल्क टलने के बाद GitHub के बिलिंग डॉक्स अब भी self-hosted कंप्यूट को मुफ़्त बताते हैं; शुल्क और शामिल उपयोग के लिए GitHub Actions की कीमतों की पूरी सूची देखें।

उदाहरण: हमेशा चालू रहने वाली एक Linux VM

4 नवंबर 2026 को DigitalOcean की Basic Regular Droplet की कीमतों की टेबल में $24 प्रति माह पर 2 साझा vCPUs, 4 GiB RAM, 80 GiB SSD और 4,000 GiB ट्रांसफ़र दिए गए थे। उसके बिलिंग डॉक्स के अनुसार बंडल वाले Droplets बंद होने पर भी बिल में जुड़ते रहते हैं; उनका शुल्क रोकने के लिए Droplet मिटाएँ।

मान लें कि VM पूरे माह NYC3 में चलती है, जहाँ Basic Droplets उपलब्ध हैं, आपकी प्राइवेट रिपॉज़िटरी के बिल्ड एक-एक करके संभालती है और कोई क्रेडिट या बंडल से ज़्यादा उपयोग नहीं है। बजट के इस उदाहरण में टैक्स, बैकअप, स्नैपशॉट, अतिरिक्त स्टोरेज या ट्रैफ़िक, GitHub शुल्क और इसे चलाने वाले व्यक्ति का समय शामिल नहीं है; इसमें परफ़ॉर्मेंस का कोई दावा नहीं किया गया है।

इन मान्यताओं के तहत VM की लागत $24 ही रहती है, चाहे वह कभी-कभार जॉब चलाए या लगातार व्यस्त रहे। रिलीज़ के लिए उस पर निर्भर होने से पहले किसी को उसके रखरखाव की ज़िम्मेदारी दें।

हाल के जॉब इतिहास से पूरे मासिक बिल की तुलना करें, जिसमें खाली पड़ी क्षमता और रीट्राई शामिल हों, और पेड उपयोग की तुलना से पहले GitHub पर होस्टेड रनर का अपना अलाउंस लागू करें।

मैनेज्ड रनर कब बेहतर विकल्प है?

Lizard पर GitHub Actions रनर हर जॉब के लिए नई Firecracker VM में JIT कॉन्फ़िगरेशन से GitHub का actions/runner चलाते हैं; बाद में रनर का रजिस्ट्रेशन हटा दिया जाता है। Lizard सिर्फ़ प्राइवेट रिपॉज़िटरी के लिए कैश डिस्क रखता है और फ़ोर्क से आने वाले जॉब उसके साथ कभी नहीं चलते। pull request और दूसरी ब्रांच कैश पढ़ सकती हैं, लेकिन उसमें सिर्फ़ डिफ़ॉल्ट ब्रांच के पुश, शेड्यूल और मैनुअल रन ही सेव करते हैं।

Lizard Pro की कीमत $19 प्रति माह है, टैक्स सहित, जिसमें $19 का उपयोग शामिल है; यही न्यूनतम मासिक शुल्क है और इससे ज़्यादा उपयोग pay as you go है। रनर VM के समय का बिल हर सेकंड के हिसाब से बनता है, जिसमें सेटअप और खाली रहने का समय शामिल है।

Lizard रनर सिर्फ़ Ubuntu 24.04 पर Linux x64 और GitHub ऑर्गनाइज़ेशन सपोर्ट करते हैं, पर्सनल अकाउंट नहीं। ऑर्गनाइज़ेशन का एडमिन Lizard GitHub App इंस्टॉल करता है। 7 दिन के ट्रायल के लिए कार्ड ज़रूरी है, इसमें $5 का उपयोग शामिल है और सिर्फ़ Small रनर की अनुमति है, एक समय में अधिकतम 4 vCPU तक; ट्रायल का उपयोग खत्म होने पर वर्कलोड रुक जाते हैं, जब तक आप Pro शुरू न करें।

ट्रायल जॉब के लिए Small लेबल इस्तेमाल करें:

runs-on: lizard-small-ubuntu-2404

Windows, macOS और ARM जॉब GitHub पर रहते हैं; GPU जॉब के लिए सही प्रोवाइडर चुनें। अगर सबसे कम बिल्ड समय मायने रखता है तो प्रोवाइडर का बेंचमार्क करें, ज़रूरत हो तो अपने क्लाउड वाला सेटअप इस्तेमाल करें और पब्लिक प्रोजेक्ट के लिए GitHub पर होस्टेड मुफ़्त रनर आपकी ज़रूरत पूरी करते हों तो उन्हें बनाए रखें। मैनेज्ड रनर और दूसरे CI प्लेटफ़ॉर्म की तुलना देखें।

हमारे फ़्रंटएंड बिल्ड पर Lizard सस्ता और धीमा था; बिल्ड के माप और Lizard रनर सेटअप देखें, फिर एक भरोसेमंद Linux जॉब आज़माएँ और उसके रनटाइम, कुल बिल और रखरखाव की तुलना करें।

अक्सर पूछे जाने वाले सवाल

GitHub Actions self-hosted रनर पर एनवायरनमेंट वेरिएबल कैसे सेट करें? उदाहरण के लिए, actions-runner/.env में BUILD_MODE=test डालें, फिर sudo ./svc.sh stop और sudo ./svc.sh start से सर्विस रीस्टार्ट करें। सीधे NAME=value वाली लाइनें इस्तेमाल करें, बिना export, शेल एक्सपैंशन या वैल्यू के चारों ओर कोट लगाए। GitHub के प्रॉक्सी निर्देशों में .env का उपयोग बताया गया है; रनर का पार्सर इसे स्टार्टअप पर पढ़ता है, जबकि env.sh PATH को अलग से .path में सेव करता है। जॉब ये वैल्यू पढ़ सकते हैं, इसलिए जॉब सेटिंग्स के लिए वर्कफ़्लो का env: और क्रेडेंशियल के लिए GitHub सीक्रेट इस्तेमाल करें। .env को वर्ज़न कंट्रोल से बाहर रखें।

क्या GitHub self-hosted रनर मुफ़्त हैं? 4 नवंबर 2026 तक, अपने बिलिंग डॉक्स के अनुसार GitHub self-hosted कंप्यूट का कोई शुल्क नहीं लेता। मशीन और उसके रखरखाव का खर्च आपको फिर भी देना पड़ता है।

क्या self-hosted रनर को खुला इनबाउंड पोर्ट चाहिए? नहीं। GitHub की कम्युनिकेशन संबंधी ज़रूरी शर्तों के अनुसार पोर्ट 443 पर आउटबाउंड HTTPS चाहिए; रनर को इनबाउंड वेबहुक पोर्ट की ज़रूरत नहीं है।

रनर रजिस्ट्रेशन टोकन कितनी देर तक मान्य रहता है? GitHub के रनर सेटअप निर्देशों के अनुसार एक घंटे तक। अगर टोकन एक्सपायर होने से रजिस्ट्रेशन फ़ेल हो, तो नया टोकन जनरेट करें।