20 avr. 2026 • Projet

Home Infrastructure : Self-hosting sur VPS OVH

Infrastructure self-hostée sur VPS OVH : reverse proxy Traefik, authentification Authelia, monitoring Prometheus/Grafana/node_exporter, cache Dragonfly, object storage Garage, messaging Redpanda/NATS — déploiement via Docker Compose avec réseau proxy externe.

DockerTraefikPrometheusGrafanaLinuxDragonflyGarageRedpandaNATS

Contexte: Un VPS OVH perso pour héberger mes services, et tester des briques qu'on trouve d'habitude en cloud managé.
Mon rôle: Tout le montage : réseau, reverse proxy, authentification, supervision, stockage objet et messaging, en Docker Compose.
Résultat: Une plateforme de lab qui tourne : Traefik comme seul point d'entrée, services sensibles derrière une 2FA, S3 et brokers validés.

L’objectif

Mettre en place une infrastructure personnelle sur un VPS OVH (Ubuntu), capable d’héberger plusieurs services avec TLS automatique, authentification centralisée et monitoring complet — le tout via Docker Compose. Au-delà du socle réseau/auth/observabilité, l’infra inclut aussi des briques data inspirées des services cloud managés (object storage, cache mémoire, message streaming), pour expérimenter ces patterns en dehors d’un contexte AWS/GCP.

Architecture

Réseau proxy externe

Tous les services partagent un réseau Docker proxy externe. Traefik est le seul point d’entrée exposé publiquement. Les services internes ne publient aucun port directement : ils communiquent uniquement via ce réseau.

networks:
  proxy:
    external: true

Reverse proxy Traefik

Traefik gère la terminaison TLS (Let’s Encrypt via challenge DNS) et le routage vers les services via labels Docker. Chaque conteneur déclare sa propre règle de routage sans modifier la config centrale.

Authentification Authelia

Authelia s’intercale comme middleware d’authentification. Les services sensibles (Grafana, dashboard Traefik) demandent une session valide avec une double authentification avant de laisser passer la requête.

Avec le recul, Authelia ne convient plus à mon usage : il est pensé pour un portail web, alors que j’ai besoin d’authentifier certains services par API. Authentik serait un bon remplaçant.

Monitoring Prometheus / Grafana

node_exporter collecte les métriques système (CPU, RAM, disque, réseau)
Prometheus interroge les cibles toutes les 15 secondes
Grafana expose des dashboards temps réel avec alerting sur les seuils critiques

Cache mémoire Dragonfly

Dragonfly remplace Redis comme cache applicatif : il sert de couche de cache à plusieurs services hébergés sur le VPS.

Object storage Garage

Garage fournit un stockage objet compatible S3, auto-hébergé. La configuration et les tests sont faits (buckets, policies d’accès).

Messaging Redpanda & NATS

Deux brokers de messages cohabitent sur l’infra pour explorer différents patterns d’event streaming :

Redpanda (compatible API Kafka) pour du event streaming durable et du replay de messages
NATS pour de la messagerie légère pub/sub et request/reply à faible latence

Les deux sont fonctionnels et validés avec des messages de démonstration. L’objectif est de les mettre à disposition de mes futurs projets et de mes tests.

Ce que j’ai appris

J’ai dû gérer plusieurs problèmes : gestion des secrets via fichiers .env hors dépôt, debug réseau inter-conteneurs, et tuning des alertes pour éviter le bruit.

Dragonfly, Garage, Redpanda et NATS ont aussi été l’occasion de comprendre par la pratique des patterns qu’on retrouve côté cloud managé (S3, ElastiCache, Kinesis/SQS) : configuration de policies d’accès, compatibilité de protocole comme contrainte de migration. Avoir deux brokers, l’un orienté durabilité et rejeu (Redpanda), l’autre orienté latence (NATS), me permet de comparer les deux approches en pratique.