# Comment installer un runner GitHub Actions auto-hébergé sur un serveur dédié loué ?

> Installez un runner GitHub Actions auto-hébergé en 8 étapes, d'après la documentation officielle. Crypto, sans KYC, dès 91,65 $US.

- URL: https://lumenfer.com/fr/github-actions-runner-dedicated-server/
- Dernière mise à jour: 2026-11-01
- Éditeur: Lumenfer (https://lumenfer.com)

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.

## Ce dont le runner a besoin, selon la référence GitHub

| Attribut | Valeur |
| --- | --- |
| 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 |

## De quoi ai-je besoin avant d'installer le runner ?

**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](https://lumenfer.com/fr/build-server-hardware/ "What hardware a build server needs: cores, RAM and NVMe") explique comment les compilateurs et les éditeurs de liens utilisent les cœurs et la mémoire.

## Puis-je utiliser un runner auto-hébergé sur un dépôt public ?

**É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.

- **Restreignez le token.** Réglez la permission par défaut de `GITHUB_TOKEN` sur lecture seule pour le contenu des dépôts, et accordez davantage par job.
- **Évitez les déclencheurs privilégiés.** Ne combinez jamais `pull_request_target` ou `workflow_run` avec un checkout de code de pull request non fiable.
- **Regroupez vos runners.** Les runners d'organisation peuvent prendre des jobs de nombreux dépôts. Les groupes de runners confinent une compromission à une seule frontière.
- **Gardez les secrets hors du disque.** GitHub vous demande de minimiser les éléments sensibles stockés sur le runner.

## Comment installer le runner, étape par étape ?

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.

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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.
8. **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.

*Étapes 2, 5 et 6 sous Ubuntu ou Debian (l'URL et le token viennent de votre page New runner)*

```bash
# 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 status
```

*Étape 7 : un job qui s'exécute sur le serveur loué*

```yaml
permissions:
  contents: read

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v7
      - run: make -j"$(nproc)" test
```

## Dois-je utiliser des runners éphémères sur un seul serveur loué ?

**Oui, 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.

- **Machines virtuelles.** Commandez l'image Proxmox VE et clonez une VM modèle par job. Voir [comment monter un cluster Proxmox sur des serveurs loués](https://lumenfer.com/fr/proxmox-cluster-dedicated-servers/ "Proxmox cluster with rented dedicated servers").
- **Kubernetes.** L'Actions Runner Controller de GitHub est un opérateur Kubernetes qui met à l'échelle les runners auto-hébergés. Voir [comment exécuter Kubernetes sur du bare metal](https://lumenfer.com/fr/kubernetes-bare-metal/ "Kubernetes on bare metal servers").
- **Logs.** Un runner à un seul job ne laisse rien à inspecter ensuite, donc GitHub vous demande d'abord de transférer ses logs vers un stockage externe.

## Combien de runners un serveur peut-il héberger ?

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

### Offres Lumenfer comme hôtes de runners CI

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

## Que gère GitHub avec ses runners hébergés que je gère désormais moi-même ?

**La machine propre, les mises à jour et la reprise : GitHub vous rend responsable du système d'exploitation et de tous les autres logiciels.**

- **Croissance du disque.** Les espaces de travail, les images Docker et les caches s'accumulent entre les jobs. Planifiez un nettoyage, sinon le NVMe se remplit pendant une release.
- **Mises à jour du runner.** Le runner se met à jour lui-même lorsqu'il reçoit un job. Si vous vous enregistrez avec `--disableupdate`, vous devez tout de même mettre à jour sous 30 jours.
- **Verrouillages.** Il n'y a pas de console IPMI ni KVM-over-IP pour les clients : vous demandez les redémarrages et les réinstallations dans le tableau de bord et l'équipe les exécute. Testez les modifications de pare-feu avec une seconde session SSH ouverte.
- **Mail issu des builds.** Le SMTP sortant sur le port 25 est bloqué sur chaque serveur et n'est jamais débloqué ; les ports de soumission 465 et 587 vers les fournisseurs de messagerie restent ouverts.
- **Données.** Les sauvegardes ne sont pas incluses : conservez des copies de vos données ailleurs.

**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](https://lumenfer.com/fr/self-hosted-runner-vs-github-hosted-cost/ "Is a rented server cheaper than GitHub-hosted runners?"), et chaque offre est sur la [page de tarifs Lumenfer](https://lumenfer.com/fr/pricing/ "Lumenfer plans and prices per 30 days").

## Quelle offre doit héberger mes runners ?

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.

| Offre | Quantité | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 cœurs · 32 GB DDR5 | 91,65 $US | 247,45 $US (−10%) | 439,92 $US (−20%) | 769,86 $US (−30%) |
| Lumen 8 | 8 cœurs · 64 GB DDR5 | 109,37 $US | 295,29 $US (−10%) | 524,97 $US (−20%) | 918,70 $US (−30%) |
| Lumen 16 | 16 cœurs · 128 GB DDR5 | 205,27 $US | 554,22 $US (−10%) | 985,29 $US (−20%) | 1 724,26 $US (−30%) |

Dans chaque formule: 2022+ CPU · DDR5 · NVMe uniquement · RAID 1 · IPv4 dédiée · Sans KYC

**Avant de payer**

- Rechargement minimum de 1 $US. Rechargez une fois en crypto, puis achetez n'importe quelle formule depuis votre solde.
- Les crédits de votre solde n'expirent pas et permettent de renouveler n'importe lequel de vos serveurs. Lorsqu'un rechargement est effectué uniquement pour atteindre le minimum, la partie non dépensée est remboursée sur demande dans les 30 jours suivant le paiement, en USDT ou USDC. Le reste d'un solde n'est pas versé, sauf si la loi l'exige.
- Crédité dès que votre paiement a été vérifié sur la blockchain. Délai habituel de confirmation du réseau : BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min · XMR ≈ 20 min

## Runner GitHub auto-hébergé sur un serveur loué : FAQ

### Puis-je exécuter le runner GitHub en tant que root ?

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.

### Le runner a-t-il besoin de ports entrants ?

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.

### Un seul serveur peut-il servir plusieurs dépôts ?

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.

### Que se passe-t-il si mon serveur redémarre ou passe hors ligne ?

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.

### Puis-je héberger des runners GitLab ou des agents Jenkins de la même façon ?

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.

### Comment payer, et avez-vous besoin de mon identité ?

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.

## Sources

1. [Ajout de runners auto-hébergés](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners) — GitHub Docs (read 2026-11-01)
2. [Configuration de l'application runner auto-hébergé en tant que service](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application) — GitHub Docs (read 2026-11-01)
3. [Utilisation de runners auto-hébergés dans un workflow](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow) — GitHub Docs (read 2026-11-01)
4. [Référence des runners auto-hébergés (exigences, autoscaling, runners éphémères, communication)](https://docs.github.com/en/actions/reference/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
5. [Runners auto-hébergés](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
6. [Référence d'utilisation sécurisée](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub Docs (read 2026-11-01)
7. [Suppression de runners auto-hébergés](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/remove-runners) — GitHub Docs (read 2026-11-01)
8. [Limites d'Actions](https://docs.github.com/en/actions/reference/limits) — GitHub Docs (read 2026-11-01)
9. [Endpoints REST API pour les runners auto-hébergés](https://docs.github.com/en/rest/actions/self-hosted-runners) — GitHub Docs (read 2026-11-01)
10. [Actions Runner Controller](https://docs.github.com/en/actions/concepts/runners/actions-runner-controller) — GitHub Docs (read 2026-11-01)
11. [Étapes post-installation Linux pour Docker Engine](https://docs.docker.com/engine/install/linux-postinstall/) — Docker Docs (read 2026-11-01)
12. [actions/checkout (utilisation dans le README)](https://github.com/actions/checkout) — GitHub (read 2026-11-01)

---

Lumenfer: Lumenfer loue des serveurs bare-metal de génération actuelle à Amsterdam, Reykjavik, Zurich et Bucarest, payés en crypto sans KYC : pas de pièce d'identité, pas de selfie, pas de documents. Chaque machine dispose d'un CPU lancé en 2022 ou plus récent, de mémoire DDR5 et de disques NVMe, et est louée entière à un seul client avec accès root. Elle est exploitée par DomaineGoat LLC, une société panaméenne qui ignore les notifications DMCA, ne répond que devant la loi panaméenne, autorise les relais de sortie Tor et ne conserve aucun journal. Sur l'engagement de 30 jours, chaque offre est facturée au moins 25 % sous un serveur de génération actuelle équivalent nommé, parmi 13 hébergeurs crypto sans KYC, relevés le 30 octobre 2026.