Certains liens de cette page sont des liens d'affiliation : si vous vous inscrivez via ces liens, ce site touche une commission, sans surcoût pour vous. Les prix et les recommandations ne changent pas.

Tout guide « faites tourner votre CI gratuitement » s’arrête au même endroit : GitHub offre des minutes gratuites, et les runners auto-hébergés sont gratuits. Aucune des deux affirmations n’est fausse, et aucune ne vous dit ce qu’un runner coûte réellement. Celui-ci fait l’arithmétique avec les chiffres que GitHub publie aujourd’hui, et un prix de VPS que nous avons mesuré nous-mêmes.

Ce que coûtent les runners GitHub-hosted par minute

Le chiffre choc est $0.006 par minute pour un runner Linux standard à 2 cœurs, et il ne s’applique qu’une fois vos minutes incluses épuisées. Avant cela, vous ne payez pas à la minute ; vous dépensez un quota mensuel.

RunnerTarif à la minute (USD)
Linux 1 cœur (x64)$0.002
Linux 2 cœurs (x64)$0.006
Linux 2 cœurs (arm64)$0.005
Windows 2 cœurs$0.010
macOS 3-4 cœurs$0.062

Deux choses se cachent dans ce tableau. D’abord, GitHub arrondit chaque job à la minute supérieure, donc un job de 30 secondes est facturé comme une minute. Ensuite, arm64 est moins cher que x64 ($0.005 contre $0.006) - une raison de basculer votre runner public sur un label Arm quand votre pile compile en Arm.

Les runners plus gros sont une autre échelle : Linux 4 cœurs à $0.012/min, 8 cœurs à $0.022, 16 cœurs à $0.042, jusqu’à 96 cœurs à $0.252. Ils ne comptent que si vous parallélisez à l’intérieur d’un seul job, et ils ne sont pas du tout disponibles sur le plan Free.

Le quota gratuit, en minutes

« Gratuit » signifie une quantité de calcul incluse, pas des minutes illimitées. Le quota mensuel, converti en minutes Linux standard à $0.006 :

PlanCalcul inclusMinutes Linux standard
Free$122 000
Pro$183 000
Team$183 000
Enterprise Cloud$30050 000

Deux règles comptent plus que le tableau. Les dépôts publics ont des runners hébergés standard gratuits en illimité - les minutes ci-dessus ne concernent que les dépôts privés. Et les runners auto-hébergés sont gratuits, toujours, et ne prélèvent rien sur votre calcul inclus. Cette deuxième règle est tout l’intérêt économique de faire tourner le vôtre.

Le point mort : quand un VPS bat GitHub

Un runner auto-hébergé coûte ce que coûte la machine, et les minutes sont gratuites. La question est de savoir combien de minutes hébergées cette machine doit remplacer avant d’être rentabilisée.

Prenez le Hetzner CX23 que nous avons mesuré pour notre comparatif VPS : 2 vCPU / 4 Go / 40 Go à 5,49 € par mois, environ $6. À $0.006 la minute Linux, $6 achètent exactement 1 000 minutes hébergées. Le CX23 est donc rentabilisé le mois où vous auriez autrement consommé 1 000 minutes payantes - c’est-à-dire des minutes au-delà de votre quota gratuit.

Exemple chiffré sur le plan Free :

  • Vous avez 2 000 minutes Linux gratuites.
  • Il vous en faut réellement 4 000 (un dépôt privé actif, ou plusieurs).
  • Coût hébergé : (4 000 - 2 000) × $0.006 = $12.
  • Coût auto-hébergé : 5,49 € ≈ $6, minutes illimitées.
  • Vous êtes gagnant dès le premier mois, et chaque minute en plus est gratuite.

Le même calcul en Pro (3 000 inclus) : l’auto-hébergement gagne dès que vous dépassez 3 000 + 1 000 = 4 000 minutes par mois. En dessous, l’hébergé est moins cher, car vous payez déjà Pro et le quota vous couvre.

La partie que l’arithmétique tait

Le VPS tourne, qu’un build soit en cours ou non. Les runners hébergés ne facturent que les minutes utilisées. Cette asymétrie tranche tout :

  • CI régulière et lourde - builds nocturnes, monorepo avec beaucoup de jobs - l’auto-hébergement gagne dès le premier mois chargé et continue de gagner.
  • CI en pointes - quelques pushs par semaine, des minutes par-ci par-là - vous restez dans le quota gratuit et l’hébergé ne coûte rien. Un VPS à 5,49 €, c’est 5,49 € que vous n’aviez pas besoin de dépenser.
  • Jobs courts - l’arrondi à la minute de GitHub punit les jobs de 20 secondes. Un runner auto-hébergé n’a pas de compteur à arrondir, donc cent jobs de 20 secondes ne sont que… du temps.

Il y a deux autres avantages de l’auto-hébergement qui ne sont pas une question d’argent. Les jobs hébergés sont plafonnés à 6 heures ; un runner auto-hébergé n’a pas ce plafond. Et la concurrence hébergée est limitée par le plan, alors qu’un runner auto-hébergé vous donne autant de jobs parallèles que les cœurs de la machine.

Ce qu’un runner auto-hébergé vous coûte réellement

Le prix en dollars n’est pas tout le prix. Vous faites désormais tourner un service qui exécute du code arbitraire de votre dépôt, et vous possédez les correctifs, les mises à jour et la frontière de sécurité.

Trois règles que nous suivons sur notre propre machine :

  1. Jamais sur l’hôte de production. Un runner exécute du code de workflow non fiable. Donnez-lui son propre VPS, ou au minimum son propre conteneur sans accès à votre site, vos configs ou vos sauvegardes.
  2. Éphémère, pas persistant. Enregistrez un runner frais par job ou par jour pour qu’une image empoisonnée ne traîne pas. Actions Runner Controller (ARC) le fait sur Kubernetes ; un simple docker run --rm de l’image du runner le fait sur une seule machine.
  3. Pas de secrets dans l’environnement du runner. Le runner ne voit que le GITHUB_TOKEN limité au dépôt pour les jobs qu’il exécute. Gardez vos clés de déploiement là où un job ne peut pas les lire - le même raisonnement que dans le guide de déploiement rsync.

Le runner lui-même est un binaire ou un conteneur que vous faites tourner sous Docker ; il n’a rien d’exotique. Ce qui est facile à rater, c’est tout ce qui l’entoure, et c’est là le vrai coût en temps.

La configuration est la même sur toute machine : créez un runner dans Settings → Actions → Runners → New self-hosted runner, copiez la commande de téléchargement - elle contient votre token et la version actuelle - puis lancez config.sh et installez-le en service. La page GitHub vous donne les trois commandes exactes ; le numéro de version change, pas le déroulé.

Que choisir ?

Choisissez GitHub-hosted si vous restez dans le quota gratuit - dépôts privés sous 2 000 minutes par mois, ou n’importe quel dépôt public - que vous voulez zéro maintenance, et que vos jobs finissent en minutes plutôt qu’en heures.

Choisissez un runner auto-hébergé chez Hetzner si vous épuisez le quota gratuit chaque mois, qu’il vous faut des jobs longs ou très parallèles, ou des builds sur le réseau privé à côté de vos serveurs.

Choisissez Vultr ou DigitalOcean si vous avez besoin d’un runner dans une région que Hetzner ne couvre pas, ou d’une facturation à la seconde pour un runner que vous ne lancez qu’à la demande.

FAQ

GitHub Actions est-il gratuit ? Les dépôts publics ont des runners hébergés standard gratuits en illimité. Les dépôts privés ont un quota mensuel inclus - $12 de calcul sur le plan Free, soit 2 000 minutes Linux standard - puis paient $0.006 par minute Linux supplémentaire.

Que coûte un runner auto-hébergé ? Le logiciel du runner est gratuit. Vous ne payez que la machine sur laquelle il tourne - à partir d’environ 5,49 € par mois pour un Hetzner CX23 - et votre temps de maintenance. Les minutes sont illimitées.

Quand un runner auto-hébergé est-il moins cher ? Quand votre consommation de dépôts privés dépasse le quota gratuit de plus d’environ 1 000 minutes Linux par mois. En dessous, le VPS à environ $6 coûte plus cher que les minutes hébergées qu’il remplace.

Les runners hébergés ont-ils des limites ? Oui. Les jobs expirent à 6 heures, et la concurrence est plafonnée par votre plan. Les runners auto-hébergés n’ont ni coût à la minute ni plafond de 6 heures, mais vous possédez la machine et ses mises à jour.

Un runner auto-hébergé est-il sûr à faire tourner ? Seulement si vous l’isolez. Il exécute du code arbitraire de votre dépôt, il ne doit donc jamais partager un hôte avec des charges de production, être éphémère et sans secrets persistants. Notre audit de serveur hérité est la checklist d’isolation.

Et ensuite ?

La machine en dessous est la décision que vous prenez réellement. Le comparatif VPS détaille Hetzner contre DigitalOcean contre Vultr avec des benchmarks que nous avons fait tourner nous-mêmes, et le guide Caddy + Docker montre le setup mono-machine qui garde un runner auto-hébergé et un petit site sur un seul serveur sans qu’ils se touchent.