Ein SESSION_SECRET in [env] geht an alle, die das Repository lesen können, ein [[services]]-Block für Redis gibt dem Cache schon beim ersten Deployment eine öffentliche Adresse, und ein [[statics]]-Eintrag, der auf /app zeigt, liefert Ihre .env und Ihre Quelldateien an jeden aus, der danach fragt. Dieser Skill findet diese und die weiteren unten aufgeführten Fly.io-Konfigurationsfehler vor dem Deployment und zeigt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner über fly.toml und dessen Varianten (fly.staging.toml, fly.production.toml) aus sowie über das Dockerfile, das fly deploy dafür baut (dessen WORKDIR, COPY . ., ENV PORT und Startbefehl). Er liest das TOML mit einer Zeilennummer für jeden Schlüssel, kennt die Standardwerte von [http_service] und [[services]] (interner Port 8080, Ports 80 und 443), die Handler tls und pg_tls sowie Prozessgruppen, überspringt Platzhalter, ${...}-Referenzen und bewusst öffentliche Schlüssel und führt nie flyctl, Docker oder Ihre App aus. Er liefert BLOCK, REVIEW oder NOT FLAGGED mit Datei, Zeile, Begründung und einem sichereren Ansatz. Secrets werden nie ausgegeben.

Was geprüft wird

BLOCK (vor dem Ausliefern beheben)

• F01: Passwörter, Tokens, Schlüssel und Verbindungsstrings mit Passwort, die in [env], [build.args], Prozess-, Release- oder Console-Befehlen (auch ein Flag und sein Wert in getrennten Array-Elementen), Health-Check-Headern oder einem raw_value in [[files]] stehen
• F02: ein Datenbank- oder Cache-Port (PostgreSQL, MySQL, Redis, MongoDB und andere), der als reines TCP ohne tls- oder pg_tls-Handler bereitgestellt wird, es sei denn, ein Kommentar kennzeichnet die App als privat (# flycast only)
• F03: [[statics]], die / oder einen Systemordner ausliefern oder den Ordner, in den das Dockerfile das gesamte Projekt kopiert

REVIEW (vor dem Release prüfen)

• F11: [http_service] oder ein http-Port ohne force_https = true
• F12: SSH, ein Datenbankport mit TLS am Proxy oder ein unverschlüsselter Datenbankport in einer als privat gekennzeichneten App
• F13: ein öffentlicher Dienst ganz ohne Health Check
• F14: ein Image in [build] oder ein machine_checks-Image ohne Tag oder auf latest
• F15: ein internal_port, der von PORT oder HTTP_PORT in [env], von ENV PORT im Dockerfile oder von einem --port/--bind-Flag im Startbefehl abweicht, oder eine App, die an localhost gebunden ist
• F16: aktiviertes auto_stop_machines in einer Datenbank- oder Cache-App mit Volume
• F17: ein release_command, der das Volume benötigt (Release-Befehle laufen ohne Volumes), etwa eine SQLite-Migration
• F18: Einstellungen, die Fly ablehnt oder ignoriert: canary oder bluegreen mit Volumes, bluegreen ohne Health Check, force_https auf einem Nicht-http-Port, ein unter / eingehängtes Volume, FLY_-Variablen, suspend mit Swap oder mehr als 2 GB (memory, memory_mb oder das size-Preset) sowie unbekannte Prozessgruppen
• F19: eine [env]- oder [build.args]-Variable mit Secret-Namen, die auf ein Standardwort wie password, changeme oder admin gesetzt ist
• F20: [[statics]] auf einem Web-Root von nginx, Caddy oder httpd, den das Dockerfile mit dem gesamten Build-Kontext füllt

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Ansatz und Link zur offiziellen Fly.io-Dokumentation für jede Regel
• Ein riskantes und ein sicheres Beispielprojekt (eine Web-App, eine Redis-App und eine statische Dokumentationsseite, jeweils mit fly.toml, dazu ihre Dockerfiles) sowie der echte Bericht, den der Scanner für das riskante Projekt erzeugt

Grenzen

Er liest fly.toml und das Dockerfile so, wie sie geschrieben sind. Er sieht weder die IP-Adressen Ihrer App noch mit fly secrets gesetzte Werte oder Änderungen über fly scale oder die Machines API. Daher gehen die Regeln zu Datenbank- und SSH-Ports vom Fly-Standard aus, nach dem Apps mit Diensten öffentliche Adressen erhalten (ein Kommentar "# flycast only" kennzeichnet eine private App), und F19 kann nicht erkennen, ob ein Fly-Secret den Standardwert überschreibt. Die fly-launch-Vorlage der meisten Frameworks legt keinen Health Check an, rechnen Sie dort also mit F13. Ports, die im Code oder in einem Procfile gewählt werden, werden nicht verfolgt, und die Sicherheit des Dockerfiles selbst wird nicht geprüft. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 23 Dateien: SKILL.md, der Scanner in scripts/ (6 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Ansatz) und examples/ (14 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

Verwendung: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie dann Ihren Agenten, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.