Varför köra min egen runner istället för GitHub-hostad?

Tre verkliga skäl: din egen dependencies och toolchain inbakade (inte installera om dem varje körning), åtkomst till privata resurser som en intern registry eller databas, och kontroll över maskinen — dess storlek, dess cacher, dess nätverk. Om GitHub-hostade minuter och en ren miljö passar dig, stanna på dem. Self-hosta när du specifikt behöver en av de tre.

Är det säkert att använda en self-hostad runner?

På ett privat repo, ja. På ett publikt repo, nej — aldrig. En workflow kör godtycklig kod från vem som än triggar den, och på ett publikt repo kan en främlings pull request köra deras kod på din runner. GitHubs egna docs säger detsamma. Håll self-hostade runners till privata repos, eller acceptera att du överlämnar din box till internet.

Hur mycket CPU och RAM behöver en runner?

Beror helt på din build. Ett typiskt compile-and-test-jobb är bekvämt med 2 kärnor och 4-8 GB — Small eller Medium här. Tunga builds (stora native-kompileringar, stora Docker-images, minneshungriga test-sviter) vill ha mer, och du bör dimensionera för ditt faktiska jobb, inte en gissning. Titta på en riktig körning och du vet.

Kan en runner hantera flera repos?

En runner kan registreras till en organisation och plockas upp av flera repos, ett jobb i taget som standard. För mer parallellism, kör fler runners — var och en är sin egen systemd-tjänst. Håll dem bara alla på privata repos.

Måste jag ge dig ett ID?

Nej. E-post för att registrera, USDC eller USDT för att betala. Inga dokument, root på ungefär en minut.

Köra en self-hostad GitHub Actions runner på en VPS

GitHub-hostade runners är en fin standard. Du slutar behöva dem i det ögonblick en build vill ha något de inte har — din privata package-registry, en specifik toolchain-version du är trött på att installera om varje körning, en databas på ditt eget nätverk, eller bara mer kontroll över maskinen. Det är när en self-hostad runner på en VPS tjänar sitt uppehälle.

Denna guide får en körande ordentligt: installerad, registrerad, vid liv under systemd, och — delen folk gör fel — säker. Låt oss börja med den sista, för det är delen som biter.

Den enda säkerhetsregeln

En GitHub Actions-workflow kör godtycklig kod — vad som än finns i workflow-filen, och vad den koden drar in. På ditt eget repo är det din kod, och det är fint. På ett publikt repo kan en pull request från en främling köra deras kod på din runner. Det är inte en bugg; det är så CI fungerar. GitHubs egen dokumentation säger tydligt: använd inte self-hostade runners med publika repositories.

Så regeln är enkel och icke-förhandlingsbar: self-hostade runners är för privata repos. Om ditt repo är publikt, använd GitHub-hostade runners och gå vidare. Allt nedan förutsätter ett privat repo.

Vad en runner behöver från boxen

Det beror på builden, och du bör dimensionera för din snarare än ett tal från en sida:

Ett typiskt compile-and-test-jobb — 2 kärnor och 4-8 GB är bekvämt. Small ($8, 4 vCPU / 4 GB) eller Medium ($12, 6 vCPU / 6 GB) täcker de flesta av dessa.
Tyngre builds — stora native-kompileringar, stora Docker-image-builds, minneshungriga test-sviter — vill ha mer utrymme. Titta på en riktig körning (htop medan den bygger) och dimensionera för vad du faktiskt ser, inte för hopp.

Disk spelar också roll: build-cacher, Docker-lager, och klonade repos staplas. Håll ett öga på det och pruna.

1. Förbered boxen

Skapa en non-root-användare för runnern — GitHubs installer vägrar ändå köra som root, och du vill ha det så:

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

Installera vad dina builds behöver — en språk-toolchain, Docker, build-verktyg. Till exempel, om dina jobb bygger containrar:

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

2. Ladda ner och registrera runnern

I ditt repo (eller org) på GitHub, gå till Settings → Actions → Runners → New self-hosted runner. GitHub ger dig de exakta nedladdnings-kommandona och en registrerings-token (den är kortlivad — ta den färsk). Som runner-användaren:

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 frågar efter ett runner-namn, labels, och en work-folder — standarderna är fina att börja med. Labels är hur din workflow riktar denna runner (runs-on: self-hosted).

3. Kör den som en systemd-tjänst

Runnern kommer med en helper som installerar en systemd-tjänst åt dig — använd den, så att runnern överlever omstarter och startar om vid fel. Fortfarande som runner-användarens install, men service-kommandona behöver root:

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

Det registrerar actions.runner.* som en systemd-unit som körs som runner-användaren, startande vid boot. Loggar går till journald:

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

Tillbaka på GitHubs Runners-sida visar din runner nu Idle — grön prick. Rikta en workflow mot den:

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

Pusha, och jobbet körs på din box.

4. Håll det rent

En self-hostad runner återanvänder sitt filsystem mellan jobb — det är hastighetsvinsten (varma cacher) och footgunen (kvarlämnat state). Två vanor håller det friskt:

Pruna regelbundet. Docker särskilt — docker system prune på en cron, annars fylls disk tyst med döda lager.
Lagra inga secrets på boxen. Använd GitHub Actions secrets, injicerade per körning, inte filer som ligger i runnerns home. Om runnern komprometteras följer allt på disk med.

Om du behöver en verkligt ren miljö per jobb, kör varje jobb inuti ett container-steg — runnern stannar, jobbets röra gör det inte.

När man ska self-hosta, ärligt

Self-hosta när du behöver din egen toolchain inbakad, åtkomst till privata nätverksresurser, eller kontroll över maskinen. Stanna på GitHub-hostade runners när en ren, engångsmiljö och deras minuter passar dig — det är genuint enklare, och enklare är värt något. Och aldrig, på ett publikt repo, self-hosta. Den är inte en preferens.

Om en privat-repo-runner är vad du behöver: välj ett plan — Small ($8) för lättare builds, Medium ($12) när de blir tyngre — betala i USDC eller USDT (ingen KYC, inga dokument), och du har root på ungefär 60 sekunder. Arbeta sedan ner den här sidan och du har en runner som plockar upp jobb några minuter senare.

Se planet & beställ en VPS →