Agent skill · software engineering · jeremylongshore
flyio-upgrade-migration
Migrate Fly.io app configuration, runtime images, Machine resources, regions, volumes, or Managed Postgres through staged change control. Use when upgrading a live workload. Trigger with: "upgrade Fly app", "migrate Fly region", "change Fly runtime safely".
Why this skill is useful
Adds specific commands and procedures for migrating between Fly.io platform versions and Postgres upgrades that the AI wouldn't reliably generate on its own.
What it needs
Requires fly installed locally. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Fly.io Runtime and Platform Change Control Overview Replace the obsolete Apps v1-to-v2 tutorial with ongoing change control for the current Machines platform. Treat flyctl, fly.toml, images, architecture, Machine resources, regions, volumes, and Managed Postgres as separate migration surfaces with distinct rollback and data risks. Prerequisites Current and target versions, configuration, image, architecture, resources, regions, and data topology Provider documentation and release notes retrieved at the change boundary Backup, export, restore test, acceptance gates, owner, approver, and rollback window Instructions Step 1: Classify the change surface Separate CLI behavior, config schema, API contract, image or runtime, CPU architecture, VM size, region placement, volume state, and Managed Postgres changes. Step 2: Freeze current state and contract Record flyctl version, image, Machine instance versions, configuration hash, health, regions, volumes and snapshots, database plan and version, and dependency compatibility. Step 3: Build a staging rehearsal Use production-like configuration with synthetic or protected copied data. Exercise application startup, release command, health, connectivity, schema compatibility, and restore. Step 4: Plan data movement explicitly For a region-bound volume, create and verify the supported copy or snapshot path before Machine movement. For Managed Postgres, follow its current service features and support path; do not apply unmanaged Postgres commands. Step 5: Canary the approved change Change one process group, Machine, or non-production database boundary first. Observe health, errors, latency, data counts, and dependent services for the agreed window. Step 6: Complete or reverse Roll through remaining resources only after acceptance. Reconcile every image, instance version, region, volume attachment, and data count; retain rollback assets until expiry. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/flyio-upgrade-migration