Comment faire tourner un runner GitHub Actions auto-hébergé sur un VPS ?

Provisionnez un VPS Linux (Small — 4 vCPU / 4 Go — est le choix par défaut raisonnable), installez le paquet runner depuis Settings → Actions → Runners de votre dépôt, enregistrez-le avec le jeton fourni par GitHub, puis démarrez-le en tant que service. Les étapes complètes à copier-coller sont ci-dessous ; vous obtenez root en une minute environ.

Puis-je faire tourner le runner dans Docker ?

Oui. Faites tourner l'image officielle du runner (ou la vôtre) dans un conteneur, ou utilisez-le pour donner à chaque job un environnement isolé et jetable. Aucune IP dédiée n'est requise — le runner n'établit que des connexions sortantes vers GitHub, un plan NAT convient donc.

Comment garder le runner actif en tant que service ?

Le runner fournit un script d'aide svc.sh qui installe une unité systemd : ./svc.sh install && ./svc.sh start. Il survit ensuite aux redémarrages et redémarre en cas d'échec. Le guide ci-dessous donne les commandes exactes.

Un runner auto-hébergé est-il moins cher que les minutes hébergées par GitHub ?

Pour un CI lourd ou fréquent, oui. Les runners hébergés par GitHub facturent à la minute au-delà du quota gratuit ; un VPS à 8 $/mois offre des minutes illimitées pour un tarif fixe et reste « chaud » (pas de démarrage à froid, dépendances en cache). Un dépôt actif rembourse généralement la machine.

Demandez-vous une pièce d'identité ou une carte ?

Non. Inscription par e-mail, paiement en USDC ou USDT. Aucun document, aucune carte, jamais de KYC.

VPS pour runners GitHub Actions auto-hébergés

Faites tourner votre propre runner GitHub Actions auto-hébergé sur un VPS — CI plus rapide, sans facturation à la minute, contrôle total de l'environnement de build. Paiement en crypto, sans KYC. À partir de 8 $/mois.

Les runners hébergés par GitHub sont pratiques, jusqu'à ce que la facture ou le temps d'attente commence à faire mal. Au-delà du quota gratuit, vous payez à la minute, chaque job démarre « à froid » et retélécharge les dépendances à chaque fois. Un runner auto-hébergé sur votre propre VPS inverse ces trois points : coût mensuel fixe, machine « chaude » avec vos caches déjà sur le disque, et environnement de build que vous contrôlez entièrement — versions d'outils précises, plus de RAM, un cache de couches Docker qui persiste réellement.

Un runner n'a besoin que de joindre GitHub en sortie, il fonctionne donc sur nos plans les moins chers, se paie en crypto et ne demande pas de KYC.

Ce dont un runner a besoin

Du CPU et de la RAM pour vos builds. Small (8 $/mois — 4 vCPU, 4 Go RAM, 35 Go NVMe) est le choix confortable pour la plupart des CI : builds Node/Go/Rust, suites de tests, builds d'images Docker. Compilation lourde ou jobs parallèles ? Passez à Medium ou à un plan Pro.
Un disque NVMe pour les caches. Tout l'intérêt de l'auto-hébergement est la persistance — caches de dépendances, couches Docker et artefacts de build restent sur le disque entre les exécutions. Le NVMe garde les restaurations rapides.
Pas d'IP dédiée nécessaire. Le runner appelle GitHub en HTTPS ; aucun accès entrant n'est requis. Un plan NAT (à partir de 3 $/mois) suffit. Prenez une IP dédiée seulement si vous hébergez aussi quelque chose qui sert du trafic.

Configurer un runner (Ubuntu 24.04)

Créez le runner dans votre dépôt (ou organisation) : Settings → Actions → Runners → New self-hosted runner → Linux. GitHub affiche une commande de téléchargement et un jeton d'enregistrement à usage unique. Sur le VPS :

# en tant qu'utilisateur non-root (le runner refuse de tourner en root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# enregistrer avec l'URL + le jeton de l'interface GitHub
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Le garder actif en tant que service

Ne lancez pas ./run.sh dans un terminal — installez le runner en service systemd pour qu'il survive aux redémarrages :

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

Le runner apparaît maintenant comme Idle dans l'interface GitHub et prend tout job qui le cible.

Utiliser depuis un workflow

Dirigez un job vers votre runner via runs-on :

jobs:
  build:
    runs-on: self-hosted        # ou un label personnalisé défini à l'enregistrement
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Jobs basés sur Docker

Installez Docker une fois, et vos workflows peuvent construire des images ou faire tourner des conteneurs de service, le cache de couches persistant entre les exécutions :

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # laisser le runner utiliser Docker sans sudo

Pour une isolation jetable par job, faites tourner le runner lui-même dans un conteneur et recréez-le à chaque exécution — un schéma courant pour les builds non fiables ou en matrice.

Pourquoi EQVPS pour le CI

Coût fixe, minutes illimitées. Pas de comptage à la minute — un pipeline chargé coûte autant qu'un pipeline au repos.
Caches « chauds ». Dépendances et couches Docker restent sur NVMe entre les exécutions ; les builds accélèrent au lieu de ralentir.
Root en ~60 secondes, images propres. Ubuntu, Debian et plus via cloud-init ; installez exactement la chaîne d'outils dont vous avez besoin.
Sans KYC, paiement en crypto. E-mail pour s'inscrire, USDC/USDT pour payer. Lancez des runners supplémentaires pour les pics de release et résiliez-les ensuite — le temps payé non utilisé est recrédité sur votre solde.

Guide de configuration complet étape par étape →