Un SESSION_SECRET dans [env] est visible par tous ceux qui peuvent lire le dépôt, un bloc [[services]] pour Redis donne au cache une adresse publique dès le premier déploiement, et une entrée [[statics]] pointant vers /app sert votre .env et vos fichiers source à quiconque les demande. Ce skill détecte ces erreurs et les autres erreurs de configuration Fly.io ci-dessous avant le déploiement, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur fly.toml et ses variantes (fly.staging.toml, fly.production.toml) ainsi que sur le Dockerfile que fly deploy construit pour lui (son WORKDIR, COPY . ., ENV PORT et la commande de démarrage). Il lit le TOML avec un numéro de ligne pour chaque clé, connaît les valeurs par défaut de [http_service] et [[services]] (port interne 8080, ports 80 et 443), les handlers tls et pg_tls et les groupes de processus, ignore les placeholders, les références ${...} et les clés publiques par conception, et n'exécute jamais flyctl, Docker ni votre application. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• F01 : mots de passe, tokens, clés et chaînes de connexion avec mot de passe écrits dans [env], [build.args], les commandes de processus, release ou console (y compris un flag et sa valeur dans des éléments de tableau séparés), les en-têtes de health checks ou un raw_value de [[files]]
• F02 : un port de base de données ou de cache (PostgreSQL, MySQL, Redis, MongoDB et autres) servi en TCP brut sans handler tls ni pg_tls, sauf si un commentaire marque l'application comme privée (# flycast only)
• F03 : des [[statics]] qui servent / ou un dossier système, ou le dossier dans lequel le Dockerfile copie tout le projet

REVIEW (à vérifier avant la publication)

• F11 : [http_service] ou un port http sans force_https = true
• F12 : SSH, un port de base de données avec TLS au niveau du proxy, ou un port de base de données non chiffré dans une application marquée comme privée
• F13 : un service public sans aucun health check
• F14 : une image [build] ou une image machine_checks sans tag ou en latest
• F15 : un internal_port différent de PORT ou HTTP_PORT dans [env], de l'ENV PORT du Dockerfile ou d'un flag --port/--bind dans la commande de démarrage, ou une application liée à localhost
• F16 : auto_stop_machines activé dans une application de base de données ou de cache qui possède un volume
• F17 : un release_command qui a besoin du volume (les commandes de release s'exécutent sans volumes), comme une migration SQLite
• F18 : paramètres que Fly refuse ou ignore : canary ou bluegreen avec des volumes, bluegreen sans health check, force_https sur un port non http, un volume monté sur /, des variables FLY_, suspend avec swap ou plus de 2 Go (memory, memory_mb ou le preset size), et des groupes de processus inconnus
• F19 : une variable [env] ou [build.args] au nom de secret définie sur un mot par défaut comme password, changeme ou admin
• F20 : des [[statics]] sur la racine web de nginx, Caddy ou httpd que le Dockerfile remplit avec tout le contexte de build

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et le lien vers la documentation officielle de Fly.io pour chaque règle
• Un projet d'exemple risqué et un projet sûr (une application web, une application Redis et un site de documentation statique, chacun avec son fly.toml, plus leurs Dockerfiles), ainsi que le rapport réel produit par le scanner sur le projet risqué

Limites

Il lit fly.toml et le Dockerfile tels qu'ils sont écrits. Il ne voit ni les adresses IP de votre application, ni les valeurs définies avec fly secrets, ni les modifications faites avec fly scale ou la Machines API : les règles sur les ports de base de données et SSH partent donc du comportement par défaut de Fly, qui attribue des adresses publiques aux applications avec services (un commentaire "# flycast only" marque une application comme privée), et F19 ne peut pas savoir si un secret Fly remplace la valeur par défaut. Le modèle fly launch de la plupart des frameworks ne crée aucun health check, attendez-vous donc à F13 dans ce cas. Les ports choisis dans le code ou dans un Procfile ne sont pas suivis, et la sécurité du Dockerfile lui-même n'est pas vérifiée. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP contenant 23 fichiers : SKILL.md, le scanner dans scripts/ (6 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (14 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Utilisation : Il s'agit d'un skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi de manière autonome avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.