Runners GitHub Actions auto-hébergés, dans l'UE
Les mêmes workflows, sur une machine à Prague ou Covilhã qui est à vous au mois plutôt qu'à la minute - avec le cache de compilation encore chaud et une adresse qu'un pare-feu peut réellement autoriser.
À qui cela s'adresse
Une équipe qui surveille le compteur de minutes
Une minute Linux 2 cœurs coûte 0,006 USD et une minute 16 cœurs 0,042 USD, si bien que la compilation en matrice qui a rendu la suite rapide est exactement ce qui a rendu la facture intéressante.
Un workflow qui doit atteindre quelque chose de privé
L'étape de déploiement doit parler à une base de données, un registre ou un équipement qui n'accepte que des adresses connues, et les runners hébergés de GitHub arrivent depuis une plage trop vaste pour être autorisée.
Une compilation qui a besoin de plus que ce que l'image apporte
Un compilateur sous licence, un émulateur, 30 Go de fixtures, ou simplement plus de disque que n'en a le runner hébergé - et le réinstaller à chaque job constitue l'essentiel de la pipeline.
Ce qui change quand le runner est à vous
- L'espace de travail et les caches persistent entre les jobs, si bien que la restauration des dépendances cesse d'être l'étape la plus longue du workflow.
- Une IPv4 statique issue d'AS204057 que votre base de données, votre registre ou votre VPN peuvent autoriser par adresse.
- Ce que vous installez reste installé - chaînes d'outils, SDK sous licence, émulateurs, gros jeux de fixtures, tout ce que l'image hébergée ne porte pas.
- Des runners enregistrés au niveau dépôt, organisation ou entreprise, avec les labels de votre choix et un workflow qui les sélectionne par runs-on.
- Le disque et la RAM que vous choisissez, plutôt que la forme figée d'un runner hébergé.
- Une machine à Prague ou Covilhã sous contrat chypriote, ce qui est une réponse de résidence des données et non un réglage de région.
Dimensionné d'après ce que la pipeline fait vraiment
Un service runner, c'est un job à la fois : le parallélisme est ici un nombre de processus runner et non un palier d'abonnement - plusieurs sur un hôte, chacun dans son répertoire, est la forme habituelle. Dimensionnez d'après le job le plus lourd plutôt que la moyenne, et laissez de la marge de disque : l'espace de travail, le cache d'outils et les couches de conteneurs y vivent tous, et c'est cette persistance qui justifie l'auto-hébergement. La moitié honnête du marché : un hôte mensuel fixe coûte pareil une semaine sans push, là où les minutes hébergées ne coûtent rien. Cela devient rentable dès que la pipeline tourne presque tous les jours.
Comment installer un runner GitHub Actions sur un hôte neuf
Linux x64, dans l'ordre que GitHub documente. Le jeton d'enregistrement est généré par runner et expire une heure après l'ouverture de la page : récupérez-le en dernier.
-
Créer un utilisateur non privilégié pour lui
sudo adduser --disabled-password --gecos "" runner sudo -iu runnerLe runner exécute ce qu'un workflow lui dit, il ne devrait donc pas être root ni partager son répertoire personnel avec quoi que ce soit. Tout ce qui suit tourne sous cet utilisateur.
-
Télécharger et décompresser le runner
mkdir actions-runner && cd actions-runner curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c tar xzf ./actions-runner-linux-x64-2.336.0.tar.gzCette version et cette empreinte sont celles publiées avec la release v2.336.0. Vérifiez s'il en existe une plus récente sur la page des releases avant de recopier ceci : le runner se met ensuite à jour tout seul, mais le premier téléchargement, c'est à vous de le vérifier.
-
Le configurer face à un dépôt ou une organisation
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,euPrenez le jeton dans Settings, puis Actions, puis Runners, puis New self-hosted runner - il est limité dans le temps et expire une heure après son émission. Pointez l'URL vers l'organisation plutôt que vers le dépôt pour partager un runner entre plusieurs dépôts.
-
Le faire tourner en service
sudo ./svc.sh install runner sudo ./svc.sh start sudo ./svc.sh statussvc.sh prend l'utilisateur sous lequel le service doit tourner, c'est pourquoi l'utilisateur runner a été créé d'abord. Prenez plutôt ./run.sh si vous voulez seulement voir un job atterrir avant de vous engager sur un service.
-
Empêcher needrestart de tuer des jobs en cours
echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.confSous Debian et Ubuntu, needrestart redémarre les services dont les bibliothèques ont été mises à jour - y compris un runner au milieu d'un job. GitHub documente exactement ce fichier comme moyen de l'en exempter.
-
Pointer un workflow dessus
name: smoke on: [push] jobs: build: runs-on: [self-hosted, linux, x64, eu] steps: - uses: actions/checkout@v6 - run: cat /etc/os-releaseruns-on correspond à tous les labels de la liste, un job qui en demande quatre n'atterrit donc que sur un runner qui les porte tous les quatre. S'il reste en file d'attente, un label manque - et un job en attente plus de 24 heures échoue.
Vérifié sur la documentation officielle le 2026-08-15 — lire la source
Ce que nous ne sommes pas
- Nous ne sommes pas GitHub. GitHub, GitHub Actions et le runner sont à eux, et rien sur cette page n'est approuvé par eux. Nous vendons la machine sur laquelle le runner tourne.
- Cela ne remplace pas votre abonnement GitHub. Les runners auto-hébergés ne coûtent aucune minute Actions, c'est bien le but, mais les licences, le stockage et tout le reste restent sur leur facture.
- Nous ne gérons pas le runner sauf demande. Vous l'installez, ou vous ajoutez notre service d'administration et nous le gardons à jour, enregistré et surveillé.
- Les runners auto-hébergés sont documentés comme peu adaptés aux dépôts publics : un fork peut proposer une modification du workflow, et ce workflow modifié tournerait sur votre machine. Gardez-les sur des dépôts privés sauf si vous avez bien réfléchi à la question.
- Il n'y a pas ici de plan de contrôle avec autoscaling. Si vous voulez des runners créés et détruits par job, c'est Actions Runner Controller sur un cluster Kubernetes - que nous hébergeons volontiers, sur une autre page.
Les parties que les équipes découvrent tard
- Un service runner exécute un job à la fois. Le parallélisme vient de l'installation de plusieurs, chacun dans son répertoire avec son propre service, pas d'un réglage.
- Le jeton d'enregistrement expire une heure après son émission : générez-le quand vous êtes prêt à lancer config.sh, pas en début d'après-midi.
- Les labels sont tout le mécanisme de routage. runs-on correspond à chaque label de la liste, une faute de frappe ne produit donc pas d'erreur - le job attend simplement, et échoue après 24 heures en file d'attente.
- Le runner a besoin de lttng-ust, OpenSSL, Kerberos, zlib et libicu. Debian et Ubuntu les portent ; une image de conteneur minimale souvent pas.
- x64 et ARM64 sont pris en charge sous Linux, et ARM32 sous Linux uniquement. Debian 10 et suivantes et Ubuntu 20.04 et suivantes sont les bases documentées.
- Tout ce que le workflow laisse derrière lui reste sur le disque - c'est la fonctionnalité, et c'est aussi pourquoi un runner auto-hébergé veut une tâche de nettoyage planifiée et un snapshot.
Minutes de CI hébergées face à un runner à vous
| Minutes de CI hébergées par le fournisseur | Un runner chez DCXV | |
|---|---|---|
| Ce que vous payez | Chaque minute de chaque job, aussi longtemps que le projet existe | Un hôte mensuel fixe, quoi que fasse la pipeline ce mois-là |
| Une compilation qui ralentit | Coûte plus cher chaque mois où elle reste lente | Ne coûte rien de plus - la machine est déjà payée |
| Cache de couches Docker | Froid à chaque job sauf si vous le téléversez et le retéléchargez vous-même | Chaud sur du NVMe local, entre les jobs et entre les journées |
| Parallélisme | Un palier d'abonnement que l'on augmente | Un nombre que vous posez dans votre propre fichier de configuration |
| Où atterrit le checkout | Une flotte partagée, souvent dans une région que vous ne pouvez pas fixer | Une machine à Prague ou Covilhã, sous contrat chypriote |
| Adresse sortante | Une vaste plage partagée que rien ne peut autoriser | Une IPv4 statique issue d'AS204057, la vôtre à autoriser |
| Ce que la machine peut contenir | Ce que l'image du runner apporte par hasard | Toute chaîne d'outils, licence ou jeu de fixtures installé une fois |
Comment cela démarre sur votre hôte
Dites-nous ce que fait la pipeline
Le job le plus lourd que vous exécutez aujourd'hui, combien vous en voulez en parallèle, et s'il construit des images de conteneur. Cela suffit pour dimensionner un hôte sans deviner.
Nous vous remettons la machine
Prague ou Covilhã, accès root et une IPv4 statique, en moins de dix minutes. Apportez votre propre image si le runner y est déjà intégré.
Suivez le pas à pas de cette page
C'est la séquence de l'éditeur, tirée de sa documentation actuelle plutôt que d'un article de blog, et elle prend quelques minutes sur un hôte propre.
Faites un snapshot, puis ajoutez le second
Prenez un snapshot dès que la première pipeline est verte, pour que la machine suivante soit une restauration et non une reconstruction. Un pool grandit en ajoutant des hôtes, pas en en rendant un énorme.
Pourquoi nous choisir
- Sites certifiés Tier III, SLA du site de 99,982 %
- Réseau propre, AS204057, IPv4 et IPv6
- Support 24/7/365 avec environ 10 minutes de réponse moyenne
- Société chypriote, juridiction de l'UE, conforme au RGPD depuis 2007
FAQ
- Combien coûtent les runners hébergés de GitHub par rapport à l'auto-hébergement ?
GitHub facture les runners Linux hébergés à la minute : 0,006 USD pour 2 cœurs, 0,012 pour 4, 0,022 pour 8 et 0,042 pour 16, Windows à 0,010 pour 2 cœurs et macOS à 0,062 pour une machine 3 ou 4 cœurs. Les runners auto-hébergés ne consomment aucune minute Actions. Un hôte ici démarre à 16,49 EUR par mois, soit à peu près le prix de 2 700 minutes sur un runner hébergé 2 cœurs - le point de bascule se situe donc vers 45 heures de compilation par mois
- Comment mettre en place un runner GitHub Actions auto-hébergé ?
Créez un utilisateur non privilégié, téléchargez l'archive du runner pour linux-x64 depuis les releases d'actions/runner et vérifiez son empreinte, lancez ./config.sh avec l'URL de votre dépôt ou organisation et le jeton d'enregistrement pris dans Settings, Actions, Runners, puis installez-le en service avec sudo ./svc.sh install et démarrez-le. Les commandes exactes sont sur cette page. Le jeton d'enregistrement expire une heure après son émission
- Combien de jobs un runner peut-il exécuter à la fois ?
Un seul. Un service runner prend un unique job à la fois, le parallélisme consiste donc à installer plusieurs services runner sur l'hôte, chacun dans son répertoire. C'est pourquoi le dimensionnement de cette page compte des services runner et non des jobs, et pourquoi une machine 8 vCPU porte confortablement une petite compilation en matrice
- Quels systèmes d'exploitation et architectures sont pris en charge ?
Sous Linux, Debian 10 et suivantes, Ubuntu 20.04 et suivantes, RHEL 8 et suivantes, CentOS 8 et suivantes, Fedora 29 et suivantes, openSUSE 15.2 et suivantes et leurs proches, sur x64, ARM64 et ARM32. Le runner a également besoin de lttng-ust, OpenSSL, Kerberos, zlib et libicu, que Debian et Ubuntu portent en standard
- Est-il sûr d'utiliser un runner auto-hébergé sur un dépôt public ?
GitHub le déconseille, et la raison est concrète : n'importe qui peut ouvrir une pull request qui modifie le fichier de workflow, et ce workflow modifié tournerait sur votre machine. Gardez les runners auto-hébergés sur des dépôts privés sauf si vous avez lu cela attentivement et mis en place une vraie isolation. Tout ce qu'un job laisse derrière lui persiste par ailleurs sur le disque, avantage pour le cache et risque pour les secrets
- Un runner peut-il servir plusieurs dépôts ?
Oui. Enregistrez-le au niveau de l'organisation plutôt que du dépôt et tout dépôt de l'organisation pourra le sélectionner, en utilisant les labels dans runs-on pour router le travail. Un job qui demande un label qu'aucun runner ne porte attend simplement, et échoue après 24 heures en file d'attente - voilà à quoi ressemble une faute de frappe dans runs-on
Si vous avez besoin d'aide ou avez des questions supplémentaires, veuillez contacter les managers ou écrire à l'équipe de support à support@dcxv.com
Prêt à commencer ?
Facturation mensuelle, sans frais de mise en service, sans engagement