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).

Ce que vous allez apprendre

Comprendre ce qu'est un runner et comment un job lui est assigné
Distinguer runners GitHub-hosted et self-hosted, et leurs compromis
Choisir le bon type selon performance, sécurité et coût
Lire le coût d'une exécution selon la machine, et le piège du tarif macOS
Router les jobs avec les labels runs-on

Comment fonctionne un runner ?

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

Flux d'exécution des runners GitHub Actions

Vous poussez du code : un événement déclenche le workflow
GitHub lit le YAML : il identifie les jobs et leurs labels runs-on
L'orchestrateur assigne : chaque job part vers un runner disponible
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-24.04  # Machine gérée par GitHub

Les principaux labels disponibles :

Système	Labels	Alias `-latest`
Ubuntu x64	`ubuntu-24.04`, `ubuntu-22.04`	`ubuntu-latest` pointe sur 24.04
Ubuntu arm64	`ubuntu-24.04-arm`, `ubuntu-22.04-arm`
Windows x64	`windows-2025`, `windows-2022`	`windows-latest` pointe sur 2025
Windows arm64	`windows-11-arm`
macOS arm64	`macos-26`, `macos-15`, `macos-14`	`macos-latest` pointe sur macOS 26
macOS Intel	`macos-26-intel`, `macos-15-intel`

Les caractéristiques dépendent de la visibilité du dépôt, et c'est le point que l'on découvre généralement en comparant des temps de build. Sur les runners standards Linux et Windows x64 :

Visibilité du dépôt	CPU	RAM	Stockage
Dépôt public	4	16 Go	14 Go SSD
Dépôt privé	2	8 Go	14 Go SSD

Un même workflow dispose donc de deux fois la puissance sur un dépôt public. Les images macOS ont leurs propres caractéristiques, détaillées dans la référence GitHub liée en fin de page.

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

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, chaque plan inclut un quota mensuel, puis l'usage se facture à la minute selon la machine. L'ancien modèle des multiplicateurs, où une minute Windows en consommait deux et une minute macOS dix, a disparu de la documentation GitHub au profit d'une grille de prix par type de runner.

Plan	Minutes incluses par mois
GitHub Free	2 000
GitHub Pro	3 000
GitHub Team	3 000
GitHub Enterprise Cloud	50 000

Runner standard 2 cœurs	Tarif à la minute
Linux x64	0,006 $
Linux arm64	0,005 $
Windows x64	0,010 $
macOS 3 ou 4 cœurs	0,062 $

L'écart de coût reste le même, seule sa lecture change : une minute macOS vaut environ dix minutes Linux, et une minute Windows environ 1,7. Un build macOS de 10 minutes coûte donc à peu près ce que coûteraient 100 minutes de Linux.

Attention à une conséquence du nouveau modèle : le quota mensuel ne couvre que les runners standards. Dès que vous demandez un larger runner, plus de cœurs, ARM64 de grande taille ou GPU, l'exécution est facturée dès la première minute, même si votre quota est intact.

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-24.04
    steps:
      - run: npm ci && npm run build

  # macOS uniquement pour les tests spécifiques iOS/macOS
  test-macos:
    runs-on: macos-15
    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 précédente, pour une compatibilité à maintenir
runs-on: ubuntu-22.04

# Version explicite et courante : le choix par défaut
runs-on: ubuntu-24.04

# Windows, version explicite
runs-on: windows-2025

# macOS Apple Silicon
runs-on: macos-15

# macOS Intel, si vous devez encore tester sur x86
runs-on: macos-15-intel

Aucune de ces lignes n'utilise -latest, et c'est volontaire : une version explicite est la seule qui garantisse que le build de demain s'exécute sur la même machine que celui d'aujourd'hui.

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]

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-24.04
    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 :

permissions: {}

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-24.04, windows-2025, macos-15]
    runs-on: ${{ matrix.os }}
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - 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@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
  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 = quota mensuel puis facturation à la minute, une minute macOS coûtant environ 10 fois une minute Linux
-latest est une référence mobile : épinglez ubuntu-24.04, jamais ubuntu-latest
Self-hosted + repo public = risque de sécurité, à éviter

Ressources externes

Pour les détails opérationnels, la documentation officielle reste la référence.

GitHub-hosted runners, Documentation officielle
Self-hosted runners, Guide d'installation
actions/runner-images, Logiciels pré-installés sur les runners hosted

Pour aller plus loin

Sécuriser les runners : Le durcissement d'un runner self-hosted, à faire avant la première mise en production.
Runners éphémères : Le pattern jetable qui supprime toute persistance entre deux jobs.
Maintenance des runners : Garder un parc à jour, supervisé et dimensionné à la charge réelle.