feat(deploy): one-command Fly.io launch + fix null client IPs on Fly

[adamXbot]

Summary

bash deploy/fly-launch.sh --app my-mantis --region iad now provisions the Fly app, a Managed Postgres cluster, the secrets and the first admin key, then deploys — in one command.

Fly has no embeddable "Deploy to Fly.io" button (unlike Heroku/Render); their one-click is the dashboard Launch UI, which still needs the app and database to exist. So the closest real equivalent is one idempotent script plus an opt-in Actions workflow for zero-click redeploys.

🐛 The existing Fly example loses every client IP

docker/Dockerfile sets NODE_ENV=production, and in production mantis distrusts forwarding headers unless TRUST_PROXY_HEADERS=1. The current fly.toml.example never sets it. Verified against the actual production image:

before:  ua=IPTest/no-trust  ->  ip=None        # X-Forwarded-For ignored entirely

The container even warns about it on boot. For a tripwire service this silently discards the single field that matters, and the per-IP login limiter fails open because it has no IP to bucket on.

[env] now sets TRUST_PROXY_HEADERS=1 and pins TRUSTED_IP_HEADER=x-forwarded-for — Fly does not strip an inbound CF-Connecting-IP, and mantis tries that header first, so without the pin a client can forge its own recorded IP with one request header. All three cases verified against the image:

Scenario	Recorded IP
Plain X-Forwarded-For (Fly's normal case)	203.0.113.77	real IP, was None
Attacker forges CF-Connecting-IP: 6.6.6.6	203.0.113.88	forgery ignored
Attacker prepends XFF: 1.2.3.4, <real>	203.0.113.99	real rightmost hop wins

The Cloudflare-fronted variant is documented inline: front it with a Cloudflare-proxied domain and you must switch to cf-connecting-ip, or you record Cloudflare's edge IP instead of your visitor's.

Script safety properties

• Write-once pepper — refuses to overwrite MANTIS_API_KEY_PEPPER; rotating it invalidates every API key ever minted
• Idempotent — re-runs skip the existing app/cluster/secrets and just redeploy
• Secrets via stdin — fly secrets import, never argv or shell history
• Prints the admin key directly — generates BOOTSTRAP_API_KEY itself instead of scraping first-boot logs
• --dry-run — prints every command without creating anything
• bash 3.2 compatible — works with macOS stock bash

Postgres

Docs move to fly mpg (Managed Postgres), Fly's supported product. The older fly postgres builds an unmanaged cluster Fly support explicitly does not cover, so it is now opt-in via --db unmanaged with a warning. --db external (Neon/Supabase/your own) and --db none are also supported.

Continuous deploy

.github/workflows/fly-deploy.yml is inert until you set FLY_DEPLOY_ENABLED=true, so forks and unconfigured clones never attempt or fail a deploy. It refuses to deploy a fly.toml missing TRUST_PROXY_HEADERS, and polls /api/health for db:ok after deploying.

Verification

flyctl isn't installed on this machine, so no live Fly deploy was performed. Everything else was exercised for real:

• Script logic against a stubbed flyctl: dry-run, real run, re-run idempotency (pepper not rotated, cluster/app skipped), and every error path
• Generated fly.toml parses as TOML with the correct app / region / base URL and both proxy vars
• A script-format BOOTSTRAP_API_KEY seeds and authenticates against a real mantis container on a fresh database — seeded bootstrap admin key from BOOTSTRAP_API_KEY, HTTP 200 with the key, 401 without
• Both workflow action SHA pins verified to exist via the GitHub API (my first recalled SHA for setup-flyctl did not exist — replaced with the verified 1.6 commit)
• Workflow YAML parses

🤖 Generated with Claude Code