Prérequis de l'auto-hébergement

Ce qu'il faut pour faire tourner la stack Obexal complète sur votre propre infrastructure UE : composants, dimensionnement honnête, prérequis et option Terraform.

Obexal est aussi livré comme une stack auto-hébergeable. Vous exécutez chaque composant sur des serveurs que vous contrôlez, et l'identité de votre organisation ne dépend jamais d'un opérateur tiers.

Ce que signifie l'auto-hébergement

Auto-héberger Obexal, c'est faire tourner la plateforme complète sur votre propre infrastructure, dans l'Union européenne si la souveraineté est votre objectif. Rien dans le chemin des requêtes n'appelle un service tiers : le contrôle des mots de passe compromis et la résolution GeoIP s'appuient sur des fichiers locaux, et les e-mails passent par le relais SMTP de votre choix. Hébergée chez vous, la plateforme échappe aux législations extraterritoriales hors UE comme le CLOUD Act américain : aucun fournisseur ne détient vos données ni vos clés.

En contrepartie, vous assumez les devoirs de l'exploitant : TLS, configuration, sauvegardes, rotation des clés et mises à jour. Cette section les couvre un par un.

Les composants

Composant	Rôle	Image
auth-service	L'API Go : OIDC/OAuth 2.1, SAML, SCIM, sessions, API admin, migrations SQL embarquées	Distroless statique, non-root
admin	La console d'administration (Next.js, sortie standalone)	node:20-slim, non-root
login-ui	L'interface de connexion, un export statique	nginx-unprivileged
PostgreSQL	Le seul état durable : comptes, identifiants, secrets chiffrés, journal d'audit	postgres:16 ou un PostgreSQL managé UE
Redis	Sessions et rate limiting, volatile par conception	redis:7 ou un Redis managé UE
MinIO (optionnel)	Stockage objet compatible S3 pour les logos de tenant	minio, ou tout bucket S3 compatible en UE
Caddy	Reverse proxy : terminaison HTTPS, ACME, TLS on-demand pour les domaines custom des tenants	caddy:2.8

Note

En production, préférez un PostgreSQL et un Redis managés UE et retirez ces deux services du fichier Compose. La stack fonctionne à l'identique dans les deux cas.

Dimensionnement indicatif

Honnêtement : un petit VPS suffit pour démarrer. L'auth-service est un binaire Go statique unique, l'interface de connexion est constituée de fichiers statiques, et la console admin est un seul processus Node.js. Une instance avec 2 vCPU, 4 Go de RAM et 40 Go de SSD fait tourner toute la stack confortablement.

Ce qui grandit réellement avec l'usage :

La mémoire pendant les connexions : le hachage des mots de passe utilise argon2id avec 64 Mio par hachage par défaut (ARGON2_MEMORY_KIB), donc de nombreuses connexions strictement simultanées constituent le principal pic mémoire.
Le disque : le volume PostgreSQL, dominé avec le temps par le journal d'audit (borné par AUDIT_RETENTION si vous en définissez une).

La stack Compose est volontairement mono-hôte. S'il vous faut davantage, externalisez d'abord PostgreSQL et Redis vers des services managés : ils portent tout l'état.

Prérequis

Un hôte Linux avec Docker Engine et le plugin Compose v2.
Un domaine que vous contrôlez, avec des enregistrements DNS pour l'API, la console admin et l'interface de connexion (voir Déployer avec Docker Compose).
Un relais SMTP UE : le service refuse de démarrer en production avec le transport de débogage log.
Les ports 80 et 443 joignables depuis Internet, et du HTTPS sortant pour l'émission des certificats ACME.
Optionnel : une base GeoIP .mmdb pour l'accès conditionnel par pays, et un corpus local de mots de passe compromis.

Le module Terraform Scaleway

Le dépôt fournit un module d'infrastructure sous deploy/terraform/scaleway/. Il provisionne, intégralement en région fr-par : un réseau privé, un PostgreSQL managé, un Redis managé avec TLS, une instance de calcul exécutant la stack Compose derrière Caddy, un bucket objet pour les sauvegardes chiffrées (cycle de vie de 35 jours), et un pare-feu où seuls les ports 80 et 443 sont publics, le SSH étant restreint à un CIDR de votre choix. Les secrets ne transitent jamais par Terraform : ils vivent dans un coffre à secrets et sont tirés au démarrage.

Ses limites, énoncées franchement :

C'est un module mono-hôte : une seule instance de calcul exécute l'application. La base managée peut être provisionnée en haute disponibilité, la couche applicative non.
Il n'y a pas de bascule multi-région ni multi-datacenter.
terraform apply crée des ressources facturées : relisez toujours terraform plan d'abord.

Le même schéma se décline sur OVHcloud ou Outscale (ce dernier si la qualification SecNumCloud de bout en bout est une exigence contractuelle).

Prochaines étapes

Déployer avec Docker Compose : DNS, environnement, premier lancement.
Référence de configuration : toutes les variables importantes, famille par famille.
Sauvegardes et restauration : avant la mise en production, pas après.