Infrastructure auto-hébergée

Les cinq machines qui font tourner mon homelab.

Le homelab, c’est le cluster Proxmox de cinq nœuds que j’exploite depuis 2020 pour une soixantaine d’utilisateurs réguliers : routage et DNS en frontal, une forge Git auto-hébergée avec sa propre CI/CD, et une vingtaine de services derrière un seul reverse proxy Traefik. Les chiffres de cette page sont un instantané pris à la génération du site.

Cinq nœuds, chacun son rôle

Un cluster Proxmox, cinq hôtes. Le relevé de chaque carte est un instantané de l’API Proxmox du cluster, capturé une fois et daté ci-dessous.
Charge du cluster
nœuds en ligne
5/5
VM et conteneurs actifs
28/33
adresses surveillées joignables
26/26
CPU10 %
mémoire35 %

CPU et mémoire sur la dernière semaine, un point toutes les 8 h · relevé le 23 sept. 2026

edge

2 CPU · 3,7 Go

Le nœud frontal. Le routeur VyOS, Traefik et la supervision de disponibilité.

CPU
18 %
mémoire
56 %
en service
46 j

apps

2 CPU · 11,6 Go

Apps et sites auto-hébergés, plus le DNS du LAN et Home Assistant.

CPU
7 %
mémoire
43 %
en service
14 j

aux

2 CPU · 7,6 Go

Un petit nœud d’appoint : une seconde VM routeur et les gabarits de VM.

CPU
3 %
mémoire
50 %
en service
46 j

core

4 CPU · 31 Go

Le nœud principal. Une forge Git, les runners CI, Nextcloud, un PaaS.

CPU
26 %
mémoire
29 %
en service
14 j

gpu

12 CPU · 32 Go · GTX 1050

Capacité et GPU. Les services multimédias, la VM Kubernetes et l’inférence LLM locale.

CPU
4 %
mémoire
33 %
en service
6 j

relevé le 23 sept. 2026

Comment une requête atteint un service

Chaque visite d’une de mes apps auto-hébergées suit le même chemin, du point d’entrée public jusqu’au backend qui répond.
  1. Visiteurun navigateur
  2. CloudflareDNS
  3. VPSWireGuard
  4. VyOSle routeur
  5. TraefikTLS, routage
  6. appsapps auto-hébergées

Comment un projet auto-hébergé se déploie

Un push sur main lance trois jobs sur un runner auto-hébergé et passe en production en deux minutes environ, avec un rollback automatique si la vérification après déploiement échoue. Ce site-ci (Astro, sur GitHub Pages) passe par un autre pipeline ; celui-là sert à mes projets auto-hébergés.
  1. ~45 sverifylint, types, build et les vérifications rapides
  2. ~50 simagebuild, scan Trivy, push vers le registre
  3. ~15 sdeploypull, vérification de l’URL publique, rollback si échec

Une exécution représentative du pipeline derrière mes services auto-hébergés.

Les outils qui tiennent l’ensemble

Des outils standard et répandus.
  • Proxmox VELe cluster d’hyperviseurs à cinq nœuds
  • VyOSLe routeur en bordure
  • WireGuardTunnel vers le VPS public
  • TraefikReverse proxy, certificats Let’s Encrypt
  • DockerChaque service, conteneurisé
  • Gitea + ActionsForge auto-hébergée et CI/CD
  • Cloudflare DNSDNS et le défi ACME
  • AdGuard HomeDNS du LAN avec filtrage
  • TailscaleAccès nomade au LAN
  • CoolifyUn petit PaaS pour les apps annexes

Exploité de bout en bout

Sauvegardes, supervision et une procédure écrite pour chaque opération courante.

  • Exploité par une seule personne

    Je gère moi-même les sauvegardes, le renouvellement des certificats, la supervision et les incidents.

  • Surveillé des deux côtés

    Uptime Kuma dans le cluster, et Gatus sur un serveur extérieur, pour qu’une panne du cluster ne puisse pas masquer sa propre alerte.

  • Les runbooks dans un dépôt privé

    La configuration, les runbooks et l’automatisation du cluster vivent dans un dépôt versionné privé. Ajouter un nœud ou restaurer un service suit une procédure écrite.