Runners GitHub Actions : où s'exécutent vos workflows ?

Quand vous déclenchez un workflow GitHub Actions, où s’exécute-t-il réellement ? Pas sur votre machine. Pas sur les serveurs de GitHub qui hébergent votre code. Il s’exécute sur un runner — une machine dédiée à l’exécution de vos jobs.

Comprendre les runners est essentiel car ce choix impacte directement :

• La vitesse de vos pipelines
• Le coût de votre CI/CD
• La sécurité de vos builds
• L’accès à des ressources spécifiques (GPU, réseau interne)

En bref : GitHub propose des runners gratuits et prêts à l’emploi (hosted). Si vos besoins sont spécifiques (GPU, réseau privé, gros volumes), vous pouvez aussi utiliser vos propres machines (self-hosted).

Comment fonctionne un runner ?

Un runner est un serveur qui attend des jobs à exécuter. Voici le flux simplifié :

1. Vous poussez du code — Un événement déclenche le workflow
2. GitHub lit le YAML — Il identifie les jobs et leurs labels runs-on
3. L’orchestrateur assigne — Chaque job part vers un runner disponible
4. Le runner exécute — Clone du repo, exécution des steps, renvoi des résultats

Le label runs-on est la clé : c’est lui qui détermine quel type de machine exécutera votre job.

Les deux types de runners

Runners GitHub-hosted : clé en main

Ce sont des machines virtuelles gérées par GitHub. Vous n’avez rien à installer, rien à maintenir. Elles sont prêtes à l’emploi.

jobs:
  build:
    runs-on: ubuntu-latest  # Machine gérée par GitHub

Caractéristiques des runners hosted :

OS	Label	CPU	RAM	Stockage
Ubuntu 24.04	ubuntu-latest	4 vCPU	16 Go	14 Go SSD
Ubuntu 22.04	ubuntu-22.04	4 vCPU	16 Go	14 Go SSD
Windows Server 2022	windows-latest	4 vCPU	16 Go	14 Go SSD
macOS 15 (Sequoia)	macos-latest	3 cores (M1)	7 Go	14 Go SSD
macOS 13	macos-13	4 cores (Intel)	14 Go	14 Go SSD

Ce qui est pré-installé : Node.js, Python, Java, Go, Ruby, Docker, git, curl, jq, AWS CLI, Azure CLI, kubectl, helm… La liste complète est disponible sur actions/runner-images ↗.

Runners self-hosted : vos machines

Ce sont des machines que vous gérez (serveurs physiques, VMs, conteneurs). Vous installez l’agent GitHub Actions dessus, et elles deviennent disponibles pour vos workflows.

jobs:
  train-model:
    runs-on: [self-hosted, linux, gpu]  # Votre serveur avec GPU

Pourquoi choisir self-hosted ?

• GPU ou matériel spécialisé — Les runners hosted n’ont pas de GPU
• Réseau privé — Accès à des bases de données internes, APIs privées
• Gros volumes de builds — Économies sur les minutes GitHub
• Environnement personnalisé — Outils propriétaires, licences spécifiques
• Temps d’exécution long — Pas de limite de 6h comme sur les hosted

Comparaison détaillée

Critère	GitHub-hosted	Self-hosted
Maintenance	Zéro (géré par GitHub)	À votre charge
Temps de démarrage	20-40 secondes	~5 secondes (machine déjà prête)
Environnement	Neuf à chaque job	Persistant (cache, outils)
Coût (repos publics)	Gratuit illimité	Votre infrastructure
Coût (repos privés)	Minutes facturées	Gratuit (minutes GitHub)
Limite de temps	6h par job	Illimité
Accès réseau	Internet uniquement	Réseau interne possible
GPU	Non disponible	Possible
Sécurité	Isolation totale	Dépend de votre config

Quand utiliser quoi ?

Restez sur GitHub-hosted si…

• Vos builds sont standards (Node.js, Python, Java, Go…)
• Vous n’avez pas besoin d’accès réseau privé
• Vos jobs durent moins de 6 heures
• Vous êtes sur un repo public (gratuit et illimité)
• Vous préférez zéro maintenance

Passez en self-hosted si…

• Vous avez besoin de GPU (machine learning, rendu 3D)
• Vous devez accéder à des ressources internes (BDD, API privée)
• Vos builds consomment beaucoup de minutes sur repos privés
• Vous avez des contraintes de conformité (données sensibles on-premise)
• Vous avez besoin d’un environnement très spécifique

Self-hosted et repos publics : attention

Un runner self-hosted sur un repo public est un risque de sécurité majeur. N’importe qui peut ouvrir une pull request qui exécutera du code sur votre machine. Réservez les self-hosted aux repos privés ou utilisez des environnements protégés.

Coût des runners GitHub-hosted

Pour les repositories publics : gratuit et illimité. C’est un des avantages majeurs de l’open source sur GitHub.

Pour les repositories privés, les minutes sont facturées avec un multiplicateur selon l’OS :

OS	Multiplicateur	Minutes incluses (plan Free)
Linux	×1	2 000 min/mois
Windows	×2	1 000 min/mois effectif
macOS	×10	200 min/mois effectif

Exemple concret : Un build macOS de 10 minutes consomme 100 minutes de votre quota (10 × 10). Le même build sur Linux ne consomme que 10 minutes.

Optimiser les coûts

Utilisez Linux quand c’est possible — Ne lancez pas un build Node.js sur macOS si vous n’avez pas besoin de tester spécifiquement sur macOS.

jobs:
  # ✅ Linux pour le build standard
  build:
    runs-on: ubuntu-latest
    steps:
      - run: npm ci && npm run build

  # ✅ macOS uniquement pour les tests spécifiques iOS/macOS
  test-macos:
    runs-on: macos-latest
    if: contains(github.event.pull_request.labels.*.name, 'test-macos')
    steps:
      - run: npm test

Passez en self-hosted pour les gros volumes — Si vous consommez des milliers de minutes par mois, un serveur dédié peut être plus économique.

Labels et routage des jobs

Le label runs-on détermine quel runner exécute le job. C’est un système de correspondance par tags.

Labels des runners hosted

# Version spécifique
runs-on: ubuntu-22.04

# Dernière version stable (recommandé)
runs-on: ubuntu-latest

# macOS Apple Silicon (M1)
runs-on: macos-14

# macOS Intel (si besoin de compatibilité x86)
runs-on: macos-13

Labels des runners self-hosted

Quand vous enregistrez un runner self-hosted, vous lui attribuez des labels. GitHub route les jobs vers les runners qui matchent tous les labels.

# Runner self-hosted Linux 64 bits
runs-on: [self-hosted, linux, x64]

# Runner avec GPU CUDA 12
runs-on: [self-hosted, linux, gpu, cuda-12]

# Runner dans le réseau de production
runs-on: [self-hosted, production-network]

Soyez spécifique avec les labels

Évitez runs-on: self-hosted seul. Si vous avez plusieurs runners, le job pourrait atterrir sur n’importe lequel. Utilisez des labels précis pour un routage prévisible.

Bonnes pratiques

1. Définissez des timeouts

Un job bloqué peut consommer des minutes inutilement (et bloquer un runner self-hosted). Définissez toujours un timeout raisonnable :

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 30  # Tue le job après 30 min
    steps:
      - run: npm ci && npm run build

2. Utilisez la matrice pour tester sur plusieurs OS

Plutôt que de dupliquer les jobs, utilisez une matrix strategy :

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - run: npm test

3. Sécurisez vos runners self-hosted

• Isolation — Un runner par projet ou par niveau de confiance
• Éphémères — Détruisez et recréez les runners après chaque job
• Mise à jour — Gardez l’agent GitHub Actions à jour
• Monitoring — Surveillez l’activité et les ressources

Consultez le guide Sécurité GitHub Actions pour les détails.

4. Exploitez le cache

Les runners hosted repartent de zéro à chaque job. Utilisez le cache pour accélérer vos builds :

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}

À retenir

• Runners hosted = machines GitHub, zéro maintenance, idéales pour 90% des cas
• Runners self-hosted = vos machines, pour GPU, réseau privé, ou gros volumes
• runs-on = le label qui route le job vers le bon runner
• Repos publics = runners hosted gratuits et illimités
• Repos privés = minutes facturées, macOS coûte 10× plus que Linux
• Self-hosted + repo public = risque de sécurité, à éviter

Pour aller plus loin

Dans cette section

• Introduction à GitHub Actions — Vue d’ensemble de la plateforme
• Qu’est-ce qu’un workflow ? — Anatomie d’un fichier workflow
• Matrix strategy — Tester sur plusieurs OS/versions en parallèle
• Artifacts vs Cache — Accélérer vos builds
• Sécurité GitHub Actions — Protéger vos workflows

Concepts connexes

• Qu’est-ce qu’une pipeline CI/CD ? — Les fondamentaux
• CI vs Delivery vs Deployment — Les trois niveaux d’automatisation
• Bonnes pratiques CI/CD — Principes pour des pipelines fiables
• GitLab Runner — L’équivalent chez GitLab

Ressources externes

• GitHub-hosted runners ↗ — Documentation officielle
• Self-hosted runners ↗ — Guide d’installation
• actions/runner-images ↗ — Logiciels pré-installés sur les runners hosted