A SESSION_SECRET in [env] goes to everyone who can read the repository, a [[services]] block for Redis gives the cache a public address on the first deploy, and a [[statics]] entry pointing at /app serves your .env and source files to anyone who asks for them. This skill finds those and the other Fly.io config mistakes below before you deploy, and tells you how to fix each one.

Your agent runs a scanner on fly.toml and its variants (fly.staging.toml, fly.production.toml) and on the Dockerfile fly deploy builds for it (its WORKDIR, COPY . ., ENV PORT and start command). It reads the TOML with a line number for every key, knows the defaults of [http_service] and [[services]] (internal port 8080, ports 80 and 443), the tls and pg_tls handlers and process groups, skips placeholders, ${...} references and public-by-design keys, and never runs flyctl, Docker or your app. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• F01: passwords, tokens, keys and connection strings with a password written in [env], [build.args], process, release or console commands (also a flag and its value in separate array items), health check headers or a [[files]] raw_value
• F02: a database or cache port (PostgreSQL, MySQL, Redis, MongoDB and others) served as plain TCP with no tls or pg_tls handler, unless a comment marks the app as private (# flycast only)
• F03: [[statics]] that serve / or a system folder, or the folder the Dockerfile copies the whole project into

REVIEW (check before release)

• F11: [http_service] or an http port without force_https = true
• F12: SSH, a database port with TLS at the proxy, or a plain database port in an app marked as private
• F13: a public service with no health check of any kind
• F14: [build] image or a machine_checks image with no tag or on latest
• F15: an internal_port that differs from [env] PORT or HTTP_PORT, the Dockerfile's ENV PORT or a --port/--bind flag in the start command, or an app bound to localhost
• F16: auto_stop_machines on in a database or cache app that has a volume
• F17: a release_command that needs the volume (release commands run without volumes), such as a SQLite migration
• F18: settings Fly rejects or ignores: canary or bluegreen with volumes, bluegreen without a health check, force_https on a non-http port, a volume mounted at /, FLY_ variables, suspend with swap or more than 2 GB (memory, memory_mb or the size preset), and unknown process groups
• F19: a secret-named [env] or [build.args] variable set to a default word such as password, changeme or admin
• F20: [[statics]] on an nginx, Caddy or httpd web root that the Dockerfile fills with the whole build context

What's included

• The scanner (Python 3.9+, standard library only)
• A rules guide with the reason, safer approach and official Fly.io documentation link for each rule
• A risky and a safe example project (a web app, a Redis app and a static docs site, each with fly.toml, plus their Dockerfiles), and the real report the scanner produces on the risky one

Limits

It reads fly.toml and the Dockerfile as written. It cannot see your app's IP addresses, values set with fly secrets, or changes made with fly scale or the Machines API, so the database and SSH port rules assume Fly's default of public addresses for apps with services (a "# flycast only" comment marks a private app), and F19 cannot tell whether a Fly secret overrides the default value. The fly launch template of most frameworks writes no health check, so expect F13 there. Ports chosen in code or in a Procfile are not followed, and Dockerfile security itself is not checked. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 23 files: SKILL.md, the scanner in scripts/ (6 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (14 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.