Guide · GitHub Actions sur bare metal · docs consultées le 1er novembre 2026
Enregistrez un runner sur une machine Linux louée, exécutez-le en tant que service sous son propre utilisateur et tenez le code non fiable à l'écart. Chaque commande et chaque règle ci-dessous proviennent de la documentation de GitHub.
Réponse rapide
Comment installer un runner GitHub Actions auto-hébergé sur un serveur dédié loué ?
Pour installer un runner GitHub Actions auto-hébergé sur un serveur dédié loué, créez d'abord un utilisateur non root. Ouvrez ensuite Settings → Actions → Runners → New self-hosted runner, exécutez les commandes affichées par GitHub, puis sudo ./svc.sh install pour le maintenir en marche. Utilisez-le uniquement sur des dépôts privés. Les serveurs Lumenfer démarrent à 91,65 $US par 30 jours, payables en crypto sans KYC.
| Réseau | HTTPS sortant sur le port 443 vers github.com, api.github.com et *.actions.githubusercontent.com ; au moins 70 kbit/s dans chaque sens |
|---|---|
| Systèmes Linux | Ubuntu 20.04 ou ultérieur et Red Hat Enterprise Linux 8 ou ultérieur, entre autres, en x64 |
| Jobs en conteneur | Une machine Linux avec Docker installé |
| Mises à jour du runner | Automatiques lorsqu'un job est attribué ; vous devez mettre à jour dans les 30 jours suivant une nouvelle version |
| Limites des jobs | Jusqu'à 5 jours par job ; un job en file d'attente pendant 24 heures est annulé |
| Runners hors ligne | Supprimé après 14 jours sans connexion ; les runners éphémères après 1 jour |
| Images sur Lumenfer | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 et Proxmox VE 9 |
| Connexion | You log in as root over SSH. Paste a public key when ordering and password logins stay disabled, or skip it and receive a temporary root password with the server, to replace on your first login |
| Installation | Quelques minutes après la confirmation du paiement, et jamais plus d'une heure |
Il vous faut les droits d'administration dans GitHub et l'accès root sur une machine Linux. Pour un runner de dépôt, GitHub exige que vous soyez propriétaire du dépôt, propriétaire de l'organisation ou administrateur du dépôt. Un runner à l'échelle de l'organisation nécessite un propriétaire d'organisation.
Côté serveur, commandez une image Ubuntu 24.04 LTS ou Debian avec votre clé publique SSH. Votre serveur est en service quelques minutes après la confirmation du paiement, et l'attente ne dépasse jamais une heure ; le tableau de bord suit la préparation, puis affiche l'adresse IP dès que la machine tourne. L'adresse IP apparaît dans votre tableau de bord dès que la machine est prête.
Choisissez la taille d'après votre job le plus lourd, pas d'après la moyenne. Notre guide du matériel pour serveur de build explique comment les compilateurs et les éditeurs de liens utilisent les cœurs et la mémoire.
Évitez-le : GitHub recommande les runners auto-hébergés uniquement pour les dépôts privés. N'importe qui peut forker un dépôt public et ouvrir une pull request. Cette pull request peut exécuter du code sur votre machine.
La référence de sécurité de GitHub précise les enjeux. Un runner peut être compromis de façon persistante par du code de workflow non fiable. Ce code peut ensuite atteindre les secrets et le GITHUB_TOKEN. Les secrets d'environnement et les réviseurs obligatoires n'isolent pas la machine elle-même.
GITHUB_TOKEN sur lecture seule pour le contenu des dépôts, et accordez davantage par job.pull_request_target ou workflow_run avec un checkout de code de pull request non fiable.Ces étapes suivent trois pages de la documentation GitHub — ajout de runners, exécution en tant que service et utilisation dans les workflows — consultées le 1er novembre 2026. Chacune s'exécute en SSH.
Commandez le serveur avec votre clé SSH
Choisissez Ubuntu 24.04 LTS ou Debian au moment de la commande et collez votre clé publique. Les connexions par mot de passe restent alors désactivées.
Mettez à jour le système et ajoutez un utilisateur runner
Exécutez apt update && apt full-upgrade, puis créez un utilisateur non privilégié, par exemple gh-runner. Les jobs ne doivent jamais s'exécuter en root.
N'installez Docker que si les jobs utilisent des conteneurs
GitHub a besoin de Docker sous Linux pour les actions de conteneur et les conteneurs de service. La documentation de Docker avertit que le groupe docker accorde des privilèges de niveau root.
Ouvrez la page New self-hosted runner
Dans le dépôt, allez dans Settings → Actions → Runners → New self-hosted runner, puis choisissez Linux et x64. Les organisations passent d'abord par New runner.
Exécutez les commandes GitHub en tant qu'utilisateur runner
Collez les lignes de téléchargement, de checksum et de ./config.sh --url … --token … dans l'ordre indiqué. Le token d'enregistrement expire au bout d'une heure.
Installez le runner en tant que service
Depuis le dossier du runner, exécutez sudo ./svc.sh install gh-runner, puis sudo ./svc.sh start et sudo ./svc.sh status. Il survit désormais aux redémarrages.
Pointez un workflow vers ce runner
Définissez runs-on: [self-hosted, linux, x64]. Un runner doit porter chaque label listé pour prendre le job.
Verrouillez les paramètres du dépôt
Rendez GITHUB_TOKEN en lecture seule par défaut et limitez les dépôts autorisés à utiliser le runner. Lancez ensuite un job de test.
# step 2, as root: update and create the runner user
apt update && apt full-upgrade -y
adduser --disabled-password --gecos "" gh-runner
# step 5, as gh-runner, in the folder where you ran GitHub's download lines
./config.sh --url https://github.com/OWNER/REPO --token TOKEN
# for a runner that takes one job, then de-registers:
# ./config.sh --url https://github.com/OWNER/REPO --token TOKEN --ephemeral
# step 6, from the same folder, with sudo rights
sudo ./svc.sh install gh-runner
sudo ./svc.sh start
sudo ./svc.sh statuspermissions:
contents: read
jobs:
build:
runs-on: [self-hosted, linux, x64]
steps:
- uses: actions/checkout@v7
- run: make -j"$(nproc)" testOui, pour tout ce qui dépasse du code interne de confiance : GitHub recommande les runners éphémères, qui prennent un job puis se désenregistrent. Ajoutez --ephemeral lorsque vous exécutez config.sh. Votre propre automatisation efface alors l'espace de travail et enregistre un runner neuf.
GitHub propose aussi les runners just-in-time. L'endpoint REST POST /repos/{owner}/{repo}/actions/runners/generate-jitconfig renvoie une configuration pour un seul job. Pour l'enregistrement classique, POST /repos/{owner}/{repo}/actions/runners/registration-token renvoie un token valable une heure.
Des runners à un seul job sur le même hôte physique ne repartent pas de zéro. GitHub avertit que réutiliser le matériel pour des runners just-in-time peut exposer des informations de l'environnement. Sur du bare metal, donnez plutôt à chaque job une machine virtuelle ou un conteneur jetable.
Un processus runner prend un job : enregistrez donc autant de runners que de jobs en parallèle souhaités, chacun dans son propre dossier avec son propre service. Divisez la machine d'après votre job le plus lourd. Une répartition courante est un runner pour 4 à 8 threads, avec assez de RAM pour l'étape de liaison la plus lourde.
Le tableau associe chaque offre à un point de départ raisonnable. Ajustez après une semaine d'observation de htop et des temps de job.
| Offre | CPU | Cœurs | Mémoire | Disques | Par 30 jours | Bon départ |
|---|---|---|---|---|---|---|
| Lumen 6 | AMD EPYC 4244P | 6 cœurs / 12 threads | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | 1 à 2 runners : lint, tests unitaires, petits services |
| Lumen 8 | AMD Ryzen 7 9700X | 8 cœurs / 16 threads | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | 2 à 4 runners : builds Go, Rust ou Java |
| Lumen 16 | AMD Ryzen 9 9950X | 16 cœurs / 32 threads | 128 GB DDR5 | 2 × 1,92 TB NVMe | $205.27 | 4 à 8 runners, ou un gros build C++ |
| Lumen 24 | AMD EPYC 9254 | 24 cœurs / 48 threads | 256 GB DDR5 ECC | 2 × 1,92 TB NVMe | $356.25 | VMs de runner sous Proxmox, avec mémoire ECC |
| Lumen 32 | AMD EPYC 9354 | 32 cœurs / 64 threads | 384 GB DDR5 ECC | 2 × 3,84 TB NVMe | $749.67 | Un pool de runners pour toute une organisation |
La machine propre, les mises à jour et la reprise : GitHub vous rend responsable du système d'exploitation et de tous les autres logiciels.
--disableupdate, vous devez tout de même mettre à jour sous 30 jours.Dans le contrôle de Lumenfer sur 30 October 2026, les vendeurs de serveurs dédiés annonçaient des délais d'installation à partir de 30 minutes à 10 jours ouvrés, avec une médiane de 24 heures. Lumenfer se place du côté rapide : un hôte de runner tourne quelques minutes après la confirmation du paiement, avec une heure comme limite. Les coûts sont comparés minute par minute dans runner auto-hébergé vs coût hébergé par GitHub, et chaque offre est sur la page de tarifs Lumenfer.
Machines entières, un client chacune, facturées depuis un solde en crypto. Amsterdam (Pays-Bas), Reykjavik (Islande), Zurich (Suisse) et Bucarest (Roumanie) : les cinq plans dans les quatre villes, un seul prix partout.
6 cœurs · 32 GB DDR5
91,65 $US
3 months 247,45 $US (−10%)6 months 439,92 $US (−20%)1 year 769,86 $US (−30%)
8 cœurs · 64 GB DDR5
109,37 $US
3 months 295,29 $US (−10%)6 months 524,97 $US (−20%)1 year 918,70 $US (−30%)
Flagship
16 cœurs · 128 GB DDR5
205,27 $US
3 months 554,22 $US (−10%)6 months 985,29 $US (−20%)1 year 1 724,26 $US (−30%)
Dans chaque formule: 2022+ CPU · DDR5 · NVMe uniquement · RAID 1 · IPv4 dédiée · Sans KYC
Non. Créez un utilisateur dédié et installez le service pour lui avec sudo ./svc.sh install USERNAME, comme le montre la page de service de GitHub. Une tâche exécutée en tant que root peut modifier l'hôte pour toutes les tâches suivantes, et pour vous.
La liste des exigences de communication de GitHub indique du HTTPS sortant sur le port 443 vers ses domaines, plus au moins 70 kbit/s dans chaque sens. En entrant, vous pouvez tout fermer sauf SSH. Le runner ouvre lui-même chaque connexion, en sortant.
Oui, enregistrez le runner au niveau de l'organisation et affectez-le à un groupe de runners. GitHub avertit que les runners d'organisation peuvent recevoir des tâches de nombreux dépôts, donc un groupe limite la portée d'une mauvaise tâche.
Le service redémarre après un reboot. Les tâches attendent dans la file et sont annulées au bout de 24 heures. Un runner resté déconnecté plus de 14 jours est retiré de GitHub et doit être enregistré à nouveau.
Oui. Tout agent CI Linux s'exécute sur le serveur avec un accès root. Les règles de sécurité s'appliquent : le code non fiable reçoit une VM ou un conteneur jetable, jamais l'hôte lui-même.
Sans KYC : nous ne demandons jamais de pièce d'identité, de selfie, de documents, de carte ni de numéro de téléphone. Rechargez un solde en BTC, USDT, USDC, ETH, SOL, LTC, XMR (minimum 1 $US) et commandez depuis celui-ci pour 30 jours, 3 mois, 6 mois ou 12 mois.
À partir de 91,65 $/30 jours · sans KYC
Commander un bare metal