EQVPS

একটি VPS-এ একটি সেলফ-হোস্টেড GitHub Actions Runner চালানো

Jul 27, 2026 · 4 min read · EQVPS Team

GitHub-hosted runner একটি ঠিক ডিফল্ট। যে মুহূর্তে একটি build এমন কিছু চায় যা এদের নেই তখনই আপনার এদের দরকার ফুরায় — আপনার প্রাইভেট package registry, একটি নির্দিষ্ট toolchain সংস্করণ যা প্রতি run-এ পুনরায় ইনস্টল করতে আপনি ক্লান্ত, আপনার নিজের network-এ একটি database, বা কেবল মেশিনের ওপর বেশি নিয়ন্ত্রণ। তখনই একটি VPS-এ একটি সেলফ-হোস্টেড runner তার মূল্য অর্জন করে।

এই গাইড একটি সঠিকভাবে চালু করে: ইনস্টল করা, register করা, systemd-র অধীনে জীবিত, ও — যে অংশ মানুষ ভুল করে — নিরাপদ। সেই শেষটা দিয়ে শুরু করি, কারণ ওটাই যে অংশটা কামড়ায়।

সেই এক নিরাপত্তা নিয়ম

একটি GitHub Actions workflow যেকোনো কোড চালায় — workflow ফাইলে যা আছে, ও সেই কোড যা টানে। আপনার নিজের repo-তে সেটি আপনার কোড, আর এটি ঠিক। একটি public repo-তে, একজন অচেনার একটি pull request আপনার runner-এ তাদের কোড চালাতে পারে। সেটি একটি bug নয়; CI এভাবেই কাজ করে। GitHub-এর নিজের ডকুমেন্টেশন স্পষ্ট বলে: public repository-র সাথে সেলফ-হোস্টেড runner ব্যবহার করবেন না।

তাই নিয়মটি সরল ও অ-আলোচনাযোগ্য: সেলফ-হোস্টেড runner private repo-র জন্য। আপনার repo public হলে, GitHub-hosted runner ব্যবহার করুন ও এগিয়ে যান। নিচের সবকিছু একটি private repo ধরে নেয়।

একটি runner বক্স থেকে কী চায়

এটি build-এর ওপর নির্ভর করে, আর আপনার একটি পেজের সংখ্যার বদলে নিজেরটার জন্য size করা উচিত:

ডিস্কও গুরুত্বপূর্ণ: build cache, Docker layer, ও clone-করা repo জমে। এতে নজর রাখুন ও prune করুন।

1. বক্স প্রস্তুত করুন

runner-এর জন্য একটি non-root ব্যবহারকারী তৈরি করুন — GitHub-এর installer যাই হোক root হিসেবে চলতে অস্বীকার করে, আর আপনি এটি সেভাবেই চান:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # শুধু যদি আপনার build-এর সত্যিই sudo দরকার হয়

আপনার build-এর যা লাগে তা ইনস্টল করুন — একটি language toolchain, Docker, build tool। উদাহরণস্বরূপ, আপনার job container বানালে:

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 ব্যবহারকারী হিসেবে:

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 নাম, label, ও একটি work ফোল্ডার চায় — শুরু করতে ডিফল্ট ঠিক। Label হলো যেভাবে আপনার workflow এই runner-কে লক্ষ্য করে (runs-on: self-hosted)।

3. এটিকে একটি systemd সার্ভিস হিসেবে চালান

runner-এর সাথে একটি helper আসে যা আপনার জন্য একটি systemd সার্ভিস ইনস্টল করে — এটি ব্যবহার করুন, যাতে runner reboot টেকায় ও failure-এ restart হয়। তবুও runner ব্যবহারকারীর install-এ, কিন্তু সার্ভিস কমান্ডের root দরকার:

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

তা runner ব্যবহারকারী হিসেবে চলা actions.runner.*-কে একটি systemd unit হিসেবে register করে, 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 আপনার বক্সে চলে।

4. এটি পরিষ্কার রাখুন

একটি সেলফ-হোস্টেড runner job-এর মধ্যে তার filesystem পুনঃব্যবহার করে — সেটাই গতির লাভ (গরম cache) ও footgun (অবশিষ্ট state)। দুটি অভ্যাস এটিকে সুস্থ রাখে:

আপনার প্রতি job একটি সত্যিই পরিচ্ছন্ন পরিবেশ লাগলে, প্রতিটি job একটি container ধাপের ভেতরে চালান — runner থাকে, job-এর জঞ্জাল থাকে না।

কখন সেলফ-হোস্ট করবেন, সৎভাবে

সেলফ-হোস্ট করুন যখন আপনার নিজের toolchain বেক-করা, প্রাইভেট network সম্পদে access, বা মেশিনের নিয়ন্ত্রণ দরকার। GitHub-hosted runner-এ থাকুন যখন একটি পরিচ্ছন্ন, throwaway পরিবেশ ও তাদের মিনিট আপনাকে মানায় — সেটি সত্যিই সরলতর, আর সরলের একটি মূল্য আছে। আর কখনও, একটি public repo-তে, সেলফ-হোস্ট করবেন না। ওটা একটি পছন্দ নয়।

একটি private-repo runner আপনার যা দরকার হলে: একটি প্ল্যান বাছুন — হালকা build-এর জন্য Small ($8), ভারী হলে Medium ($12) — USDC বা USDT-তে পরিশোধ করুন (no KYC, কোনো নথি নয়), আর প্রায় 60 সেকেন্ডে root পাবেন। তারপর এই পেজ ধরে নামুন আর কয়েক মিনিট পরে আপনার একটি runner job তুলবে।

প্ল্যান দেখুন ও VPS অর্ডার করুন →

FAQ

GitHub-hosted-এর বদলে নিজের runner চালাব কেন?

তিনটি আসল কারণ: আপনার নিজের dependency ও toolchain বেক-করা (প্রতি run-এ পুনরায় ইনস্টল নয়), একটি অভ্যন্তরীণ registry বা database-এর মতো প্রাইভেট সম্পদে access, ও মেশিনের নিয়ন্ত্রণ — এর আকার, cache, network। GitHub-hosted মিনিট ও একটি পরিচ্ছন্ন পরিবেশ আপনাকে মানালে, সেগুলোতে থাকুন। শুধু তখনই সেলফ-হোস্ট করুন যখন আপনার নির্দিষ্টভাবে ওই তিনটির একটি লাগে।

একটি সেলফ-হোস্টেড runner ব্যবহার করা কি নিরাপদ?

একটি private repo-তে, হ্যাঁ। একটি public repo-তে, না — কখনও নয়। একটি workflow যে ট্রিগার করে তার যেকোনো কোড চালায়, আর একটি public repo-তে একজন অচেনার pull request আপনার runner-এ তাদের কোড চালাতে পারে। GitHub-এর নিজের ডকুমেন্টেশন একই বলে। সেলফ-হোস্টেড runner private repo-তে রাখুন, বা মেনে নিন যে আপনি আপনার বক্স ইন্টারনেটকে দিচ্ছেন।

একটি runner-এর কত CPU ও RAM দরকার?

পুরোপুরি আপনার build-এর ওপর নির্ভর। একটি সাধারণ compile-and-test job 2 core ও 4-8 GB-তে আরামদায়ক — এখানে Small বা Medium। ভারী build (বড় native compile, বড় Docker image, memory-ক্ষুধার্ত test suite) বেশি চায়, আর আপনার একটি অনুমান নয়, আপনার আসল job-এর জন্য size করা উচিত। একটি আসল run দেখুন আর আপনি জানবেন।

একটি runner কি একাধিক repo সামলাতে পারে?

একটি runner একটি organization-এ register করা ও কয়েকটি repo দ্বারা তোলা যেতে পারে, ডিফল্টে একবারে একটি job। বেশি parallelism-এর জন্য, বেশি runner চালান — প্রতিটি নিজের systemd সার্ভিস। শুধু এদের সবগুলো private repo-তে রাখুন।

আপনাকে কি একটি ID দিতে হবে?

না। sign up করতে ইমেল, পরিশোধে USDC বা USDT। কোনো নথি নয়, প্রায় এক মিনিটে root।

← Back to blogSee plans & pricing →

মন্তব্য

এখনো কোনো মন্তব্য নেই। প্রথম হোন।

একটি মন্তব্য দিন

মন্তব্য প্রকাশের আগে মডারেট করা হয়।