Ce qu'il vous faut¶

Rien d'exotique, et surtout pas un environnement de développement. Un serveur Linux avec Docker, un accès en lecture à vos sauvegardes, et une connexion sortante.

Une machine avec Docker¶

Le runner s'exécute lui-même dans un conteneur, et il démarre un conteneur par sonde et par bac à sable. Il lui faut donc un démon Docker, et l'accès à son socket :

-v /var/run/docker.sock:/var/run/docker.sock

C'est le même modèle que GitLab Runner : le conteneur tourne en root pour atteindre ce socket. Traitez la machine du runner comme une machine de confiance — quiconque atteint ce socket atteint le démon Docker de l'hôte.

Un volume de travail est également obligatoire :

-v restoreproof-work:/var/lib/restoreproof

C'est là que la sauvegarde est téléchargée, décompressée et restaurée, et c'est ce que les conteneurs de sondes montent. Sans ce volume, le runner refuse de démarrer avec un message explicite : depuis un conteneur, un chemin qui n'est pas sur un volume monté n'existe pas pour les conteneurs qu'il lance.

Prévoyez, sur ce volume, de quoi accueillir l'archive téléchargée et son contenu décompressé, en même temps. Chaque exécution nettoie derrière elle — conteneurs, volumes du bac à sable, espace de travail.

Aujourd'hui, le déploiement passe par Docker ou par Kubernetes. Le binaire seul reste annoncé « à venir » dans l'assistant.

Sur Kubernetes, l'assistant produit une commande helm install qui va chercher le chart sur oci://ghcr.io/kolapsis/restoreproof/charts. Le pod embarque son propre démon Docker (side-car Docker-in-Docker), donc le runner fonctionne quel que soit le moteur de conteneurs de vos nœuds — mais ce side-car est privilégié : votre cluster doit l'autoriser. Il faut aussi Kubernetes 1.29 ou plus récent, et une classe de stockage par défaut pour les deux volumes demandés (espace de travail et données Docker).

L'accès en lecture à vos sauvegardes¶

Selon l'endroit où elles vivent :

S3, MinIO, Wasabi, GCS, Azure — les identifiants sont fournis au runner (variables d'environnement, fichier de credentials, ou rôle IAM de l'instance pour AWS). Ils ne sont jamais enregistrés dans RestoreProof.
Disque local ou NFS — montez le répertoire dans le conteneur du runner, en lecture seule :
```
-v /chemin/hote/backups:/data/backups:ro
```
Le plan désignera ensuite /data/backups, le chemin vu par le runner. Pour un partage NFS, assurez-vous qu'il est monté avant le démarrage du runner. - HTTP/HTTPS — une URL directe vers le fichier. Les en-têtes d'authentification passent par les secrets du runner.

La lecture seule suffit. Le runner ne réécrit jamais dans vos sauvegardes.

Une connexion sortante¶

Le runner appelle, il n'est jamais appelé. Aucun port à ouvrir en entrée, aucune redirection, aucune IP fixe à nous communiquer.

Ce qu'il doit pouvoir joindre :

Le canal du control plane, en gRPC sur TLS. C'est l'adresse https://… que l'assistant de déploiement écrit dans votre commande. Il y maintient une connexion longue durée : le réseau doit laisser vivre une connexion inactive plusieurs minutes (le runner envoie un keepalive toutes les 20 secondes, ce qui suffit à la plupart des NAT et proxys).
Le registre des images de sondes, ghcr.io, d'où viennent les images ghcr.io/kolapsis/restoreproof/probe-*. Le préfixe et le tag sont configurables si vous préférez un miroir interne.
Le registre des images de bacs à sable — celles que vos plans nomment (mysql:8.0, postgres:16, une image applicative…), donc en général le Docker Hub ou votre registre privé.

Si vous préchargez toutes ces images sur la machine, seul le canal du control plane reste indispensable.

Un compte, et rien d'autre¶

La création de compte crée l'organisation et son premier utilisateur, sur le plan gratuit : 1 runner, 1 plan, 10 exécutions par mois, 7 jours de rétention. De quoi faire le parcours complet et obtenir une vraie preuve signée avant de payer quoi que ce soit.

Ce que le runner ne fait pas¶

Il n'envoie jamais de données de sauvegarde au control plane. Il envoie des verdicts, des mesures et des journaux assainis.
Il ne transmet aucun de vos secrets. Un plan ne contient que des références (env://, file://, vault://, sops://), résolues sur la machine du runner.
Il ne touche pas à votre production : la restauration a lieu dans un bac à sable jetable, détruit à la fin de l'exécution.
Il n'accepte aucune connexion entrante.

Deux réglages à connaître avant de vous lancer¶

RESTOREPROOF_PRIVATE_KEY — la clé Ed25519 qui signe vos rapports. Si vous ne la fournissez pas, le runner en génère une à chaque démarrage et le dit dans ses journaux : vos preuves restent vérifiables, mais elles ne sont plus signées par la même clé d'un redémarrage à l'autre. Pour une clé stable, lancez une fois le runner avec l'option -generate-keys : il affiche une paire de clés et s'arrête. Passez la partie privée dans cette variable.
RESTOREPROOF_TLS_SKIP — à laisser à false. Ne le passez à true que face à un control plane en certificat auto-signé, dans un environnement de test.

Une fois tout cela en place, suivez le parcours complet.