Recettes — installations en un clic
Installez et durcissez des logiciels sur votre serveur en un clic avec les recettes Servor — des playbooks vérifiés qui inspectent la machine, s'adaptent et déroulent étape par étape avec un suivi en temps réel.
Une recette est une installation vérifiée en un clic. Choisissez « Installer nginx », « Installer PostgreSQL », « Durcir SSH » ou « Installer Docker », et Servor le fait pour vous sur le serveur — en inspectant d'abord l'état courant, en s'adaptant à ce qu'il trouve, et en exécutant chaque étape avec sa propre vérification. Vous suivez le tout sous forme de checklist en temps réel, pas de chat.
Les recettes sont disponibles sur tous les plans, y compris le Free. Elles sont propulsées par un modèle léger côté Servor et plafonnées par un quota mensuel par plan — elles ne consomment pas vos crédits IA.
Lancer une recette
Ouvrir un serveur connecté
Allez dans Serveurs et sélectionnez la machine. Elle doit être connectée — si elle est injoignable, réparez l'agent d'abord. Votre coffre doit être déverrouillé ; voir Déverrouiller votre coffre.
Ouvrir l'onglet Recettes
Choisissez une recette dans le catalogue — groupé par catégorie, chacune avec son niveau de risque.
Renseigner les réglages et lancer
Certaines recettes demandent un réglage (un domaine, un port). Puis appuyez sur Lancer — aucun prompt à écrire.
Suivre la checklist
Servor commence par une reconnaissance (est-ce déjà installé ? y a-t-il déjà une config ? où ?), puis déroule les étapes en cochant chacune et en la vérifiant. Sous chaque tâche, les commandes réellement exécutées s'affichent en direct (dépliées pendant, repliées une fois terminées) — vous voyez exactement ce qui se passe. Une étape longue affiche un chrono, et une étape destructrice s'arrête pour votre confirmation.
La reconnaissance d'abord — ça s'adapte à votre machine
Un serveur réel est en désordre : quelque chose peut déjà être installé, une config peut déjà exister, les chemins ne sont pas forcément là où le manuel le dit. Une recette n'exécute jamais à l'aveugle. Elle commence par inspecter l'état réel et s'adapte — si le logiciel est déjà là et sain, elle vérifie et passe ; une config existante n'est pas touchée ; les chemins non-standards sont détectés. C'est pour ça qu'une recette est fiable là où un script figé casserait.
Adaptées à l'OS de votre serveur
Le catalogue s'ajuste au système d'exploitation détecté. Sur un serveur Linux, vous voyez les recettes Linux (paquets via apt/dnf, services systemd). Sur Windows (winget/Chocolatey, PowerShell, services Windows) et macOS (Homebrew), vous voyez les recettes correspondantes. Une recette qui ne concerne pas votre OS n'apparaît tout simplement pas — impossible de lancer par erreur une commande Linux sur une machine Windows. Le catalogue Linux est le plus fourni ; les jeux Windows et macOS s'étoffent.
Vos propres recettes
Le catalogue officiel ne couvrira jamais votre stack maison. Un admin peut écrire les recettes de l'équipe depuis Réglages › Recettes : elles apparaissent ensuite dans le catalogue sur tous les serveurs de l'équipe, aux côtés des officielles, et se lancent exactement de la même façon.
Une recette s'écrit en JSON — pas un formulaire, parce qu'un playbook est imbriqué
(sondes de reconnaissance, étapes ordonnées, vérification par étape, variables, guardrails)
et qu'un éditeur de texte le rend mieux qu'une pile de champs. L'éditeur valide contre le
schéma exact appliqué par l'API : les erreurs s'affichent avec leur chemin
(steps.0.command), et ce qui passe dans le navigateur est ce que l'API accepte.
{
"slug": "install-redis",
"name": "Installer Redis",
"category": "cache",
"targetOs": ["debian", "ubuntu"],
"riskLevel": "caution",
"recon": [{ "command": "command -v redis-server", "looksFor": "déjà installé ?" }],
"steps": [
{
"id": "install",
"title": "Installer le paquet",
"command": "apt-get install -y redis-server",
"riskLevel": "caution",
"verify": { "command": "systemctl is-active redis-server", "expect": "active" }
}
],
"guardrails": "Ne jamais écraser un redis.conf existant sans le dire."
}Quatre règles pour qu'une recette se comporte comme les officielles : reconnaissance
d'abord (lecture seule), idempotence (un second lancement ne casse rien), une
vérification concrète par étape, et toute étape destructrice marquée "destructive": true
pour qu'elle s'arrête à votre confirmation.
Écrire, modifier et supprimer une recette d'équipe demande le rôle admin — un membre peut la lancer, pas la définir. Supprimer une recette ne supprime pas l'historique des runs passés.
Historique des runs
L'onglet Recettes propose une bascule Catalogue / Historique. L'historique liste toutes les recettes déjà lancées sur ce serveur — nom, statut (réussi, échec, en cours…), date et nombre d'étapes — pour savoir d'un coup d'œil ce qui a déjà été installé et si un run a échoué.
Les recettes respectent toutes les règles de sécurité
- Chaque commande est signée par votre navigateur et exécutée via l'agent — le même chemin zero-knowledge que le copilote. Les serveurs de Servor n'exécutent jamais rien.
- Une étape destructrice (changement de pare-feu, durcissement SSH, fichier d'échange) s'arrête pour votre confirmation explicite avant de s'exécuter.
- Les commandes blacklistées restent bloquées.
- Seuls les membres, admins et propriétaires peuvent lancer une recette — les lecteurs ne peuvent pas exécuter de commandes. Voir Rôles et permissions.
Quota
Chaque plan inclut un nombre de runs de recette par mois (le Free en inclut quelques-uns ; les plans payants davantage, jusqu'à illimité). Le compteur se remet à zéro avec votre période de facturation. Une fois épuisé, passez à un plan supérieur ou attendez le reset — tout le reste du serveur continue de fonctionner.