Runners GitHub-hosted vs Self-hosted

Le choix entre runners GitHub-hosted et self-hosted dépend de vos contraintes : performances, sécurité, coût et accès aux ressources internes. Ce guide donne les critères pour trancher.

Ce que vous allez apprendre

• Comparer GitHub-hosted et self-hosted sur les critères qui comptent
• Identifier les cas d'usage idéaux de chaque type
• Calculer le seuil de rentabilité d'un runner self-hosted
• Combiner les deux dans une architecture hybride
• Migrer progressivement un workflow vers le self-hosted

Comparaison rapide

Avant d'entrer dans le détail, ce tableau pose les sept critères qui opposent les deux types de runners.

Critère	GitHub-hosted	Self-hosted
Maintenance	Aucune	À votre charge
Démarrage	~20-40s	Instantané si pré-chaud
Environnement	Propre à chaque job	Persistant
Coût	Minutes facturées (privé)	Infrastructure à payer
Réseau	Internet uniquement	Accès réseau interne
Sécurité	Isolation garantie	Votre responsabilité
Specs	Fixes (4 CPU, 16 Go)	Personnalisables

Glissez pour voir

Quand choisir GitHub-hosted

Cas d'usage idéaux

1. Projets open source : gratuit et illimité
2. Builds standards : Node.js, Python, Java sans dépendances exotiques
3. Équipe sans ops : pas de maintenance d'infrastructure
4. Sécurité critique : isolation garantie entre jobs

Configuration typique

permissions: {}

jobs:
  test:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test

Avantages détaillés

Zéro maintenance :

• Mises à jour automatiques des logiciels
• Patches de sécurité appliqués par GitHub
• Pas de serveurs à gérer

Isolation parfaite :

• VM neuve à chaque job
• Pas de risque de contamination entre jobs
• Secrets inaccessibles entre runs

Logiciels pré-installés :

• Docker, Buildx, Compose
• AWS CLI, Azure CLI, gcloud
• kubectl, helm, terraform
• Langages multiples

Quand choisir self-hosted

Cas d'usage idéaux

1. Accès réseau interne : bases de données, registries privés
2. Hardware spécialisé : GPU, ARM, grandes quantités de RAM
3. Builds longs/fréquents : économies sur les minutes
4. Cache persistant : éviter de re-télécharger les dépendances
5. Contraintes légales : données ne devant pas sortir du réseau

Configuration typique

permissions: {}

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Build avec accès au registry interne
        env:
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker login registry.internal.company.com
          docker build -t "registry.internal.company.com/app:$IMAGE_TAG" .

Self-hosted et dépôts publics

Un runner self-hosted ne doit jamais servir un dépôt public ni traiter les pull requests de forks : n'importe qui peut alors ouvrir une PR qui exécute du code arbitraire sur votre infrastructure. Réservez le self-hosted aux dépôts privés et exigez l'approbation des workflows de forks.

Avantages détaillés

Performances :

• Pas de cold start si runner pré-chaud
• Cache local (dépendances, images Docker)
• Hardware sur-mesure (SSD NVMe, 128 Go RAM)

Accès réseau :

• Déploiement direct sur Kubernetes interne
• Tests contre bases de données internes
• Pas de tunnel ou VPN à configurer

Coût prévisible :

• Pas de facturation à la minute
• Rentable pour les gros volumes

Comparaison des coûts

Le coût est souvent le facteur décisif. Comparons la facturation à la minute des runners hosted au coût fixe d'une machine self-hosted.

GitHub-hosted (repository privé)

Minutes gratuites (plan Free) : 2 000/mois
Prix après quota :
  - Linux  : $0.008/min
  - Windows: $0.016/min
  - macOS  : $0.08/min

Exemple : 10 000 minutes Linux/mois = 8 000 minutes facturées = $64/mois

Self-hosted

VM Linux (4 CPU, 16 Go) chez un cloud provider :
  - ~$80-150/mois selon le provider
  - Peut servir plusieurs repos

Seuil de rentabilité : environ 10 000-15 000 minutes/mois

Calcul personnalisé

Analysez vos minutes actuelles dans Settings > Billing > Actions pour estimer si le self-hosted est rentable pour vous.

Comparaison des performances

Au-delà du coût, la vitesse sépare nettement les deux options — au démarrage du job comme pendant le build.

Temps de démarrage

Type	Cold start	Warm start
GitHub-hosted	20-40s	N/A (toujours cold)
Self-hosted	0-5s	0s (runner pré-chaud)

Glissez pour voir

Temps de build avec cache

# GitHub-hosted : télécharge le cache à chaque job
- uses: actions/cache@5a3ec84eff668545956fd18022155c47e93e2684 # v4.2.3
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}
# Temps de restore : 10-30s selon la taille

# Self-hosted : cache local sur disque
# Temps de restore : < 1s

Architecture hybride

La meilleure approche est souvent de combiner les deux :

permissions: {}

jobs:
  # Tests rapides sur GitHub-hosted
  lint:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - run: npm run lint

  # Build lourd sur self-hosted
  build:
    needs: lint
    runs-on: [self-hosted, linux, docker]
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - run: docker build -t app .

  # Déploiement interne sur self-hosted
  deploy:
    needs: build
    runs-on: [self-hosted, production-network]
    steps:
      - run: kubectl apply -f k8s/

Critères de décision

Pour trancher rapidement, cochez les cases qui correspondent à votre situation : la colonne qui en récolte le plus l'emporte.

Choisir GitHub-hosted si

• Le projet est open source
• Les builds durent moins de 10 minutes
• Pas besoin d'accès réseau interne
• L'équipe n'a pas de capacité ops
• L'isolation entre jobs est critique

Choisir self-hosted si

• Plus de 10 000 minutes/mois
• Besoin de GPU ou hardware spécialisé
• Accès au réseau interne requis
• Builds très longs (> 30 min)
• Contraintes de localisation des données

Migration vers self-hosted

Inutile de tout basculer d'un coup. Une migration réussie est progressive : on cible quelques workflows, on teste, puis on étend.

Étape 1 : Identifier les workflows candidats

Commencez par les workflows :

• Les plus longs (économies maximales)
• Nécessitant un accès réseau interne
• Les plus fréquents

Étape 2 : Déployer un runner de test

# Télécharger le runner
curl -O -L https://github.com/actions/runner/releases/download/v2.xxx.x/actions-runner-linux-x64-2.xxx.x.tar.gz

# Installer
tar xzf ./actions-runner-linux-x64-*.tar.gz

# Configurer
./config.sh --url https://github.com/OWNER/REPO --token TOKEN

# Démarrer
./run.sh

Étape 3 : Migrer progressivement

jobs:
  build:
    # Phase 1 : tester sur self-hosted
    # runs-on: ubuntu-24.04
    runs-on: [self-hosted, linux, x64]

À retenir

• GitHub-hosted = zéro maintenance, isolation garantie, idéal pour 90 % des cas.
• Self-hosted = vos machines, pour le GPU, le réseau interne et les gros volumes.
• Le seuil de rentabilité du self-hosted tourne autour de 10 000–15 000 minutes/mois.
• Une architecture hybride combine les deux : tests rapides hosted, builds lourds self-hosted.
• Un runner self-hosted sur un dépôt public est un risque majeur — réservez-le aux dépôts privés.

Prochaines étapes

Sécuriser les runners Durcir un runner self-hosted contre les abus

Runners éphémères Détruire le runner après chaque job

Isolation des runners Cloisonner les exécutions sur un runner self-hosted

Optimiser les workflows Cache, artifacts et parallélisation

×

📖 Voir la documentation →