fly-io-deploymentlisted

# Making an app deployable to Fly.io **Read [`references/FLY-IO-DEPLOYMENT.md`](references/FLY-IO-DEPLOYMENT.md) before applying any of this.** That file is the standard; everything below it is a summary to help you decide whether this skill applies and to check your work afterwards. Reference-architecture principles: P7, P12. ## What this standard covers - The model in one paragraph - What a service must satisfy before it can be deployed - Repository layout - `fly.toml`, annotated - The four shapes - Networking: public URL, `.internal`, `.flycast` - Scale to zero, and when not to - State: volumes and databases - Configuration and secrets - The deploy pipeline - Bootstrapping a new app - Scaling and teardown workflows - Cost ## Failure modes | Symptom | Cause | |---|---| | Deploy hangs, then fails on health checks | Process bound to `localhost`, or `internal_port` ≠ the port it binds | | Health checks fail only on first deploy | Migration or seeding blocks startup — move it after the listener, and raise `grace_period` | | `initdb: directory not empty` | `PGDATA` points at the mount root; `lost+found` lives there. Use a subdirectory | | Database never initializes against a plain `flyctl deploy`, no useful error | `[build] image` points at Fly's managed `postgres-flex`, which expects `fly postgres create`-style bootstrapping (cluster credentials, multi-machine setup) — not a bare deploy. Use a vanilla `postgres:<major>-alpine` image (§5) instead; it is what a plain `flyct