EQVPS

Self-Hosted GitHub Actions Runner በVPS ላይ ማሄድ

ጁላይ 27 2026 · 3 ደቂቃ ንባብ · EQVPS Team

GitHub-hosted runners ጥሩ default ናቸው። build እነሱ የሌላቸውን ነገር በሚፈልግበት ቅጽበት እነሱን መፈለግ ያቆማሉ — የprivate package-registryዎ፣ እያንዳንዱን run እንደገና ከመጫን የሰለቹት የተወሰነ toolchain version፣ በራስዎ network ላይ database፣ ወይም በmachine ላይ ተጨማሪ ቁጥጥር ብቻ። ያ በVPS ላይ self-hosted runner ገንዘቡን የሚያገኝበት ነው።

ይህ መመሪያ አንዱን በትክክል ያሄዳል: የተጫነ፣ የተመዘገበ፣ በsystemd ስር ሕያው፣ እና — ሰዎች የሚሳሳቱበት ክፍል — ደኅንነቱ የተጠበቀ። በዚያ የመጨረሻው እንጀምር፣ ምክንያቱም የሚነክሰው ክፍል ስለሆነ።

አንዱ security rule

GitHub Actions workflow arbitrary code ያሄዳል — በworkflow file ውስጥ ያለው ማንኛውም፣ እና ያ code የሚያመጣው ማንኛውም። በራስዎ repo ላይ ያ codeዎ ነው፣ እና ጥሩ ነው። በpublic repo ላይ የእንግዳ pull request codeቸውን በrunnerዎ ላይ ማሄድ ይችላል። ያ bug አይደለም፤ CI እንዲህ ነው የሚሠራው። የGitHub የራሱ documentation በግልጽ ይላል: self-hosted runners ከpublic repositories ጋር አይጠቀሙ።

ስለዚህ ደንቡ ቀላል እና የማይደራደር ነው: self-hosted runners ለprivate repos ናቸው። repoዎ public ከሆነ፣ GitHub-hosted runners ይጠቀሙ እና ይቀጥሉ። ከታች ያለው ሁሉ private repo ይገምታል።

runner ከbox ምን እንደሚፈልግ

በbuild ላይ ይወሰናል፣ እና ከገጽ ላይ ካለ ቁጥር ይልቅ ለእርስዎ መመዘን አለብዎ:

Disk ደግሞ ያስፈልጋል: build caches፣ Docker layers፣ እና cloned repos ይደራረባሉ። ዓይን ይጣሉበት እና ያprune ያድርጉ።

1. boxን ያዘጋጁ

ለrunner non-root user ይፍጠሩ — የGitHub installer ለማንኛውም እንደ root ማሄድ ይከለክላል፣ እና እንዲህ ይፈልጋሉ:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # only if your builds genuinely need 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ን ያውርዱ እና ይመዝግቡ

በrepoዎ (ወይም org) በGitHub ላይ፣ ወደ Settings → Actions → Runners → New self-hosted runner ይሂዱ። GitHub ትክክለኛዎቹን download commands እና registration token ይሰጥዎታል (አጭር-የሚኖር ነው — ትኩስ ይያዙት)። እንደ runner user:

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 name፣ labels፣ እና work folder ይጠይቃል — defaults ለመጀመር ጥሩ ናቸው። Labels workflowዎ ይህን runner እንዴት እንደሚtarget ያደርግ ናቸው (runs-on: self-hosted)።

3. እንደ systemd service ያሂዱት

runner systemd service ለእርስዎ የሚጭን helper ጋር ይመጣል — ይጠቀሙት፣ runner reboots እንዲተርፍ እና በfailure እንዲrestart። አሁንም እንደ runner user install፣ ግን service commands root ይፈልጋሉ:

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

actions.runner.*ን እንደ runner user የሚሮጥ systemd unit ይመዘግባል፣ በboot ይጀምራል። Logs ወደ journald ይሄዳሉ:

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

ወደ GitHub Runners page ተመልሰው፣ runnerዎ አሁን Idle ያሳያል — አረንጓዴ ነጥብ። workflow ወደ እሱ ይምሩ:

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

ይpush ያድርጉ፣ እና job በboxዎ ላይ ይሮጣል።

4. ንፁህ ያድርጉት

self-hosted runner በjobs መካከል filesystemውን እንደገና ይጠቀማል — ያ የፍጥነት ትርፉ (ሞቅ ያሉ caches) እና footgunው (የቀረ state) ነው። ሁለት ልማዶች ጤናማ ያደርጉታል:

በእያንዳንዱ job በእውነት ንፁህ environment ከፈለጉ፣ እያንዳንዱን job በcontainer step ውስጥ ያሂዱ — runner ይቆያል፣ የjob ብጥብጥ አይቀርም።

መቼ self-host ማድረግ፣ በሐቀኝነት

የራስዎ toolchain የተጋገረ ሲፈልጉ፣ private network resources መዳረሻ፣ ወይም በmachine ላይ ቁጥጥር ሲፈልጉ self-host ያድርጉ። ንፁህ፣ throwaway environment እና minutesቸው ሲስማሙዎ በGitHub-hosted runners ይቆዩ — ያ በእውነት ቀላል ነው፣ እና ቀላል ዋጋ አለው። እና ፈጽሞ፣ በpublic repo ላይ፣ self-host አያድርጉ። ያ ምርጫ አይደለም።

private-repo runner የሚፈልጉት ከሆነ: plan ይምረጡSmall ($8) ለቀላል builds፣ Medium ($12) ሲከብዱ — በUSDC ወይም USDT ይክፈሉ (KYC የለም፣ documents የለም)፣ እና በ60 ሰከንድ አካባቢ root ይኖርዎታል። ከዚያ ይህን ገጽ ወደታች ይሥሩ እና ከጥቂት ደቂቃዎች በኋላ jobs የሚይዝ runner ይኖርዎታል።

plan ይመልከቱ & VPS ያዙ →

FAQ

ከGitHub-hosted ይልቅ የራሴን runner ለምን አሄዳለሁ?

ሦስት እውነተኛ ምክንያቶች: የራስዎ dependencies እና toolchain የተጋገሩ (እያንዳንዱን run እንደገና ማይጫኑ)፣ እንደ internal registry ወይም database ያሉ private resources መዳረሻ፣ እና በmachine ላይ ቁጥጥር — መጠኑ፣ caches፣ networkው። GitHub-hosted minutes እና ንፁህ environment ከተስማሙዎ፣ በእነሱ ይቆዩ። ከእነዚያ ሦስት አንዱን በተለይ ሲፈልጉ self-host ያድርጉ።

self-hosted runner መጠቀም ደኅንነቱ የተጠበቀ ነው?

በprivate repo ላይ፣ አዎ። በpublic repo ላይ፣ አይ — ፈጽሞ። workflow የሚtrigger ካደረገው ማንኛውም arbitrary code ያሄዳል፣ እና በpublic repo ላይ የእንግዳ pull request codeቸውን በrunnerዎ ላይ ማሄድ ይችላል። የGitHub የራሱ docs ተመሳሳይ ይላል። self-hosted runners በprivate repos ላይ ያቆዩ፣ ወይም boxዎን ለinternet እየሰጡ መሆኑን ይቀበሉ።

runner ስንት CPU እና RAM ይፈልጋል?

ሙሉ በሙሉ በbuildዎ ላይ ይወሰናል። የተለመደ compile-and-test job በ2 cores እና 4-8 GB ምቹ ነው — እዚህ Small ወይም Medium። ከባድ builds (ትላልቅ native compiles፣ ትላልቅ Docker images፣ memory-የተራቡ test suites) ተጨማሪ ይፈልጋሉ፣ እና ለእውነተኛ jobዎ መመዘን አለብዎ፣ ግምት አይደለም። አንድ እውነተኛ run ይመልከቱ እና ያውቃሉ።

አንድ runner በርካታ repos ማስተናገድ ይችላል?

runner ለorganization ሊመዘገብ እና በበርካታ repos ሊነሳ ይችላል፣ በdefault በአንድ ጊዜ አንድ job። ለበለጠ parallelism፣ ተጨማሪ runners ያሂዱ — እያንዳንዱ የራሱ systemd service ነው። ሁሉንም በprivate repos ላይ ብቻ ያቆዩ።

ID መስጠት አለብኝ?

አይ። ለመመዝገብ ኢሜይል፣ ለመክፈል USDC ወይም USDT። documents የለም፣ root በአንድ ደቂቃ አካባቢ።

← ወደ ብሎግ ተመለስዕቅዶች & ዋጋዎች ይመልከቱ →

አስተያየቶች

እስካሁን አስተያየቶች የሉም። መጀመሪያ ይሁኑ።

አስተያየት ይተዉ

አስተያየቶች ከመታየታቸው በፊት ይጣራሉ።