Agent skill · software engineering · jeremylongshore

flyio-deploy-integration

Plan a Fly.io rolling, canary, or blue-green release with health, capacity, storage, and rollback constraints. Use when a release needs progressive exposure. Trigger with: "canary deploy on Fly", "use Fly blue-green", "design Fly rollout".

Why this skill is useful

Adds executable scripts for advanced Fly.io deployment strategies that are not commonly found in public documentation.

What it needs

Requires docker installed locally. Requires fly.io account access. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.

What this skill does

Fly.io Progressive Deployment Design Overview Select a provider-supported deployment strategy based on state, volume attachment, temporary capacity, and risk. Do not implement a custom traffic switch when Fly Launch already provides rolling, canary, blue-green, and immediate strategies with defined constraints. Prerequisites Immutable candidate and previous image references Healthy baseline Machines and at least one meaningful service health check State and volume inventory plus temporary capacity and cost approval Instructions Step 1: Classify the workload Identify stateless and stateful process groups, attached volumes, singleton regions, release commands, connection draining, and external dependencies. Step 2: Choose a supported strategy Use rolling for the general case. Canary creates one new Machine then rolls forward; blue-green creates replacement capacity in each region. Immediate is an emergency option with explicit downtime risk. Step 3: Validate strategy constraints Reject canary or blue-green for Machines with attached volumes. Ensure blue-green has health checks and enough quota and capacity; account for max-per-region behavior. Step 4: Define acceptance gates Set health, error, latency, saturation, business, and data-reconciliation thresholds with an observation window and named approver. Step 5: Execute one release owner Pin image and config, serialize the release, observe Machine replacement and health, and prevent unrelated scaling or secret changes during the window. Step 6: Promote or reverse Confirm every region and process group runs the intended image. If a gate fails, stop progression and restore the recorded prior release or configuration. Authentication Use a scoped deploy token whose app and expiry match the rollout. Keep observation separate with read-only access where practical. Never embed the token in fly.toml, image layers, release metadata, or health-check output. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills jeremylongshore/flyio-deploy-integration

View the source on GitHub

Browse the @skills marketplace