10 services à auto-héberger sur ton homelab Proxmox en 2026

Je paie aujourd’hui moins de €15/mois de SaaS. Il y a deux ans, c’était €85/mois : Google One, Dropbox, Bitwarden premium, GitHub Teams pour les dépôts privés, Plex Pass. La majeure partie de ces coûts tourne maintenant sur le MS-01. Ce n’est pas que l’argent – c’est le contrôle des données et le fait de comprendre ce qui tourne où.

Ce guide n’est pas un catalogue exhaustif du self-hosting. C’est ma liste réelle, avec les ressources mesurées après plusieurs semaines de fonctionnement, ce qui marche vraiment, et ce qui m’a déçu.

Avant de commencer : Nginx Proxy Manager en premier

Tous les services de cette liste ont besoin d’un reverse proxy pour être accessibles en HTTPS avec un certificat valide. Déployer Nginx Proxy Manager avant tout le reste.

pct create 160 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst 
  --hostname npm 
  --memory 512 
  --cores 1 
  --net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.160/24,gw=192.168.30.1 
  --storage rpool 
  --rootfs rpool:4 
  --unprivileged 1 
  --onboot 1

pct start 160

Le script communautaire ProxmoxVE Helper est plus rapide :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/nginx-proxy-manager.sh)"

Interface NPM accessible sur http://192.168.30.160:81. Login initial : admin@example.com / changeme. Changer immédiatement.

Pour chaque service ajouté : créer un Proxy Host dans NPM avec le sous-domaine, pointer vers l’IP:port du service, activer SSL Let’s Encrypt. NPM renouvelle les certificats automatiquement.

1. Vaultwarden – mots de passe (LXC 161)

Remplace : Bitwarden premium (€10/an), 1Password (€36/an)

C’est le premier service que j’ai déployé et celui dont l’impact est le plus immédiat. Vaultwarden est un serveur Bitwarden compatible, réécrit en Rust, qui tourne dans 50 Mo de RAM. Tous les clients officiels Bitwarden (iOS, Android, Firefox, Chrome, CLI) s’y connectent sans modification.

pct create 161 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst 
  --hostname vaultwarden --memory 256 --cores 1 
  --net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.161/24,gw=192.168.30.1 
  --storage rpool --rootfs rpool:2 --unprivileged 1 --onboot 1

pct start 161
pct enter 161

apt update && apt install -y docker.io docker-compose-v2

mkdir -p /opt/vaultwarden && cd /opt/vaultwarden
cat > compose.yml << 'EOF'
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    volumes:
      - ./vw-data:/data
    environment:
      WEBSOCKET_ENABLED: "true"
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: ""  # Générer avec: openssl rand -base64 48
    ports:
      - "3010:80"
      - "3012:3012"
EOF

docker compose up -d

Consommation réelle après un mois : 52 Mo de RAM, ~0% CPU au repos. Le volume vw-data fait 2.1 Mo pour 340 entrées.

Bilan après 8 mois : aucune interruption, toutes les fonctionnalités Bitwarden (TOTP, notes, cartes bancaires, identités) fonctionnent. Les clients iOS et Android se synchronisent en quelques secondes.

2. Nextcloud - stockage fichiers (LXC 162)

Remplace : Google Drive (€2.99/mois pour 200 Go), iCloud+ (€2.99/mois)

Nextcloud est le service le plus utilisé de mon homelab, et aussi le plus complexe à maintenir. 32 Go de photos de famille, 18 Go de documents, sync automatique depuis 4 appareils.

Le script ProxmoxVE Helper installe Nextcloud avec Apache, MariaDB et Redis en une seule commande :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/nextcloud.sh)"

Il créé un LXC Ubuntu 24.04 (ID choisi pendant l'installation, j'ai pris 162) avec 2 Go RAM alloués. Nextcloud tourne sur http://192.168.30.162:80 après installation.

Configuration post-install obligatoire dans /var/www/nextcloud/config/config.php :

'trusted_proxies' => ['192.168.30.160'],  // IP NPM
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://nextcloud.arewel.com',
'default_phone_region' => 'FR',

Consommation réelle : 380 Mo RAM au repos, 1.2 Go lors d'une synchronisation massive. MariaDB consomme 120 Mo supplémentaires. Allouer 2 Go minimum, 4 Go si on héberge beaucoup de photos avec Nextcloud Photos.

Ce qui déçoit : la gestion des conflits de fichiers est moins bonne que Dropbox. Nextcloud crée des fichiers _conflict qu'il faut résoudre manuellement. Et l'application iOS en 2026 reste lente à synchroniser les albums photos par rapport à iCloud.

3. Gitea - forge Git (LXC 163)

Remplace : GitHub Teams (€16/mois pour les dépôts privés), GitLab self-hosted (plus lourd)

Gitea est une forge Git complète en Go. Interface similaire à GitHub, très légère, déploie en 30 secondes. J'y héberge une trentaine de dépôts privés - configs serveurs, scripts, projets personnels, ce blog.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/gitea.sh)"
# LXC créé : Debian 12, 512 MB RAM, IP assignée pendant l'install → 192.168.30.163

Fonctionnalités qui me servent quotidiennement : Gitea Actions (CI/CD compatible GitHub Actions - j'y fais tourner les déploiements de ce site), mirroring automatique vers GitHub pour les dépôts publics, interface web correcte pour les petites revues de code.

Ce qui manque par rapport à GitHub : pas de Dependabot natif, pas de GitHub Copilot intégration, l'écosystème d'Actions est plus restreint. Pour un usage personnel et des projets où l'IA n'est pas dans la boucle, Gitea couvre tout.

Consommation réelle : 68 Mo RAM après démarrage, 145 Mo avec 5 pipelines CI actifs. Démarrage en 3 secondes.

4. Jellyfin - serveur média (LXC 164)

Remplace : Plex Pass (€119/an), Netflix (pour les films que j'ai en DVD)

Jellyfin lit les fichiers media depuis un partage NFS monté depuis le DS414. Les clients (TV, téléphones, tablettes) se connectent à Jellyfin en local via l'app officielle.

Le MS-01 i9-13900H a Intel Quick Sync intégré (Gen 12, identique sur l'i5-12600H). Pour le passthrough hardware dans un LXC :

# Dans le LXC Jellyfin (LXC 164, Ubuntu 22.04)
# Ajouter au fichier de config LXC : /etc/pve/lxc/164.conf
lxc.cgroup2.devices.allow: c 226:* rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

Avec Quick Sync actif, le transcoding d'un fichier 1080p H.264 → 1080p H.264 (pour un client qui ne supporte pas le codec source) utilise ~8% CPU au lieu de ~85% CPU. C'est la différence entre "le homelab chauffe un peu" et "le homelab sonne comme un PC gamer".

Consommation réelle sans transcoding actif : 210 Mo RAM. Avec un stream 4K + Quick Sync : 280 Mo RAM, 15% CPU.

Ce qui déçoit : l'interface Jellyfin est fonctionnelle mais pas aussi polie que Plex. La découverte automatique des metadata (titres, jaquettes) rate plus souvent et nécessite des corrections manuelles.

5. Home Assistant OS (VM 300)

Remplace : Apple HomeKit (partiel), Google Home, intégrations cloud des ampoules

Home Assistant tourne en VM dédiée (HAOS), pas en LXC. HAOS est un OS complet avec son propre noyau - pas possible en container. L'image officielle pour Proxmox :

cd /tmp
wget https://github.com/home-assistant/operating-system/releases/latest/download/haos_ova-14.1.qcow2.xz
unxz haos_ova-14.1.qcow2.xz

qm create 300 
  --name homeassistant 
  --memory 2048 
  --cores 2 
  --net0 virtio,bridge=vmbr0,tag=10 
  --onboot 1

qm importdisk 300 haos_ova-14.1.qcow2 rpool
qm set 300 --scsi0 rpool:vm-300-disk-0 --boot order=scsi0
qm start 300

HAOS prend 2–3 minutes pour démarrer au premier boot (provisioning). Accessible sur http://homeassistant.local:8123 ou son IP DHCP.

Ce qui tourne chez moi via HA : ampoules Ikea Tradfri (via Zigbee USB passthrough), thermostat Netatmo, caméra Reolink, capteurs de présence. HA local sans cloud - les automatisations fonctionnent même si Internet est coupé.

Consommation réelle : 1.1 Go RAM, ~5% CPU au repos. Avec une dizaine d'automatisations actives : stable à 1.3 Go.

6. Immich - photos (VM 301)

Remplace : Google Photos (€2.99/mois pour 200 Go)

Immich est le service qui m'a le plus surpris. L'interface ressemble à Google Photos : timeline, albums, recherche par IA (visages, objets, lieux), partage. La reconnaissance faciale locale fonctionne correctement après quelques jours d'apprentissage sur la bibliothèque existante.

Immich nécessite Docker avec plusieurs containers (serveur, microservices, PostgreSQL, Redis). Je le fais tourner dans une VM Ubuntu 24.04 (VM 301, 4 Go RAM, 2 vCPU) :

mkdir -p /opt/immich && cd /opt/immich
wget https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget https://github.com/immich-app/immich/releases/latest/download/example.env -O .env

# Éditer .env : UPLOAD_LOCATION, DB_PASSWORD, etc.
docker compose up -d

Les photos sont stockées sur un partage NFS depuis le DS414. Le volume de photos (32 Go) a été importé en une nuit via l'outil de migration Google Takeout → Immich.

Consommation réelle : 2.1 Go RAM avec tous les microservices. Pendant une tâche de reconnaissance faciale sur 8000 photos : 3.4 Go RAM, 150% CPU pendant 2h. La reconnaisance faciale tourne en background, ça ne bloque rien.

Ce qui déçoit : le machine learning local est moins précis que Google Photos sur les visages d'enfants et les groupes. La reconnaissance de lieux (sans GPS dans les métadonnées) ne fonctionne pas du tout.

7. Paperless-ngx - gestion documentaire (LXC 165)

Remplace : dossiers de scan + chercher "où est ma feuille d'impôts"

Paperless ingère les PDFs (scan depuis l'imprimante, fichiers téléchargés), fait de l'OCR, les classe automatiquement par correspondant et type de document. Ma facture EDF du mois dernier est trouvable en 3 secondes par la recherche "EDF octobre".

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/paperless-ngx.sh)"

Il m'a fallu 2 semaines pour configurer correctement les règles de classification automatique - la courbe d'apprentissage est réelle. Mais depuis que c'est en place, je scanne et oublie. La recherche retrouve tout.

Consommation réelle : 380 Mo RAM, 1 vCPU. L'OCR (Tesseract) monte à 100% CPU pendant 5–10 secondes par document lors du traitement, puis redescend.

8. Uptime Kuma - monitoring disponibilité (LXC 166)

Remplace : UptimeRobot (limité en free tier), Freshping

Uptime Kuma surveille que tous mes services répondent. Il ping chaque endpoint toutes les 60 secondes et envoie une alerte Telegram si quelque chose ne répond plus.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/uptimekuma.sh)"

Services surveillés : Nextcloud (HTTPS), Gitea (HTTPS), Vaultwarden (HTTPS), Jellyfin (TCP 8096), Home Assistant (HTTP), PBS (HTTPS), Proxmox (HTTPS), Pi-hole (DNS query), Synology DS414 (ping).

Consommation réelle : 95 Mo RAM. Uptime Kuma est bâti sur Node.js - c'est plus lourd que prévu pour un simple outil de monitoring, mais la UI est correcte et l'intégration Telegram fonctionne bien.

9. Mealie - recettes (LXC 167)

Remplace : bookmarks Marmiton qui disparaissent

C'est le service "plaisir" de la liste. Mealie importe les recettes depuis n'importe quelle URL (Marmiton, Cuisine AZ, NYT Cooking), les structure proprement, et génère une liste de courses à partir du planificateur hebdomadaire.

pct create 167 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst 
  --hostname mealie --memory 256 --cores 1 
  --net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.167/24,gw=192.168.30.1 
  --storage rpool --rootfs rpool:2 --unprivileged 1 --onboot 1

pct start 167
pct enter 167

apt update && apt install -y docker.io docker-compose-v2
mkdir -p /opt/mealie && cd /opt/mealie

cat > compose.yml << 'EOF'
services:
  mealie:
    image: ghcr.io/mealie-recipes/mealie:latest
    restart: unless-stopped
    ports:
      - "9925:9000"
    volumes:
      - mealie-data:/app/data/
    environment:
      ALLOW_SIGNUP: "false"
      TZ: Europe/Paris
      DEFAULT_EMAIL: you@arewel.com
volumes:
  mealie-data:
EOF

docker compose up -d

Consommation réelle : 75 Mo RAM. L'import depuis Marmiton rate environ 30% du temps (scraping instable), mais le taux de réussite sur les sites anglo-saxons est meilleur.

10. Grafana + Prometheus - monitoring infra (LXC 120 + 121)

Remplace : Datadog (€15/host/mois), New Relic

Ce sujet mérite son propre article - c'est le suivant dans la série. En résumé : Prometheus scrape toutes les métriques des VMs et LXC via node_exporter, Grafana les affiche dans des dashboards. AlertManager envoie les alertes Telegram.

Consommation réelle : Prometheus = 280 Mo RAM, Grafana = 190 Mo RAM.

Tableau récapitulatif

Sur 32 Go de RAM, il reste ~26 Go pour les futurs services, la marge Proxmox et l'ARC ZFS. En pratique avec l'ARC limité à 4 Go, on a ~22 Go de RAM libre - confortable.

Ce qui a coincé

Immich m'a donné le plus de fil à retordre. Après la migration initiale des 8000 photos, le service de machine learning (reconnaissance faciale et classification) a tourné pendant 36h sans s'arrêter, consommant 100% des 2 vCPU et faisant monter la température du MS-01 à 78°C (mesurée via sensors).

# Dans la VM Immich
docker stats
# immich-machine-learning : CPU 198%, MEM 3.2 GB

La cause : Immich avait détecté les 8000 photos comme "nouvelles" et relancé l'analyse complète chaque fois que le service redémarrait, parce que la base de données d'embeddings n'était pas persistée correctement.

# Correction dans docker-compose.yml - ajouter le volume pour la DB ML
services:
  immich-machine-learning:
    volumes:
      - model-cache:/cache   # ← ce volume existait déjà
      - ./ml-data:/usr/src/app/model_data  # ← celui-ci manquait
volumes:
  model-cache:
  ml-data:

Après correction, l'analyse initiale s'est terminée et n'a plus redémarré. Consommation redescendue à 2.1 Go RAM au repos.

Série « Homelab Proxmox MS-01 » - Article 8/10