Writing Skills
writing-skills
效率与协作技能,来自 obra/superpowers,查看原文获取完整用途和操作说明。
fly-io【部署与运维】Assists with deploying applications globally on Fly.io edge infrastructure. Use when deploying Docker-based apps, configuring multi-region machines, setting up persistent storage, or managing global databases. Trigger words: fly.io, fly deploy, fly machines, fly launch, multi-region, edge deployment, flyctl.
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Fly.io deploys applications to Firecracker microVMs across 30+ edge regions worldwide, providing sub-50ms latency to users. It supports scale-to-zero machines, persistent NVMe volumes, LiteFS for multi-region SQLite replication, and private WireGuard networking between services.
fly launch to auto-detect the framework and generate a Dockerfile, then fly deploy for zero-downtime rolling updates with health checks.auto_stop_machines and auto_start_machines in fly.toml to scale to zero when idle and wake on incoming requests, and set machine sizing appropriate to the workload.fly scale count --region to distribute machines, fly-replay header to route writes to the primary region, and LiteFS for SQLite read replicas..internal DNS for private service-to-service communication over the WireGuard mesh and never expose internal services to the public internet.fly secrets set KEY=value for encrypted secret storage accessible as environment variables.fly logs for real-time streaming, fly ssh console to access running machines, and fly proxy to tunnel to internal services.User request: "Deploy my app globally with Fly.io in US, Europe, and Asia"
Actions:
fly launch and configure Dockerfilefly scale count 2 --region iad,cdg,nrtfly-replay header for write routing to the primary regionOutput: A globally distributed app with read replicas in three regions and automatic write routing.
User request: "Set up a Fly.io staging environment that scales to zero when not in use"
Actions:
fly launchauto_stop_machines = "stop" and auto_start_machines = true in fly.tomlOutput: A staging environment that stops idle machines and wakes in sub-second on the next request.
User request: "Deploy my app to Fly.io but test on one machine first. If the health check fails, roll back."
Actions:
--strategy canary to spin up a single new machinefly deploy --strategy rolling to replace all machinesfly releases rollback#!/bin/bash
# deploy-canary.sh — Fly.io canary deployment with auto-rollback
set -euo pipefail
APP="${1:?Usage: deploy-canary.sh <app-name>}"
HEALTH_PATH="${2:-/api/health}"
echo "🐤 Deploying canary..."
fly deploy --app "$APP" --strategy canary --wait-timeout 120
HEALTH_URL="https://${APP}.fly.dev${HEALTH_PATH}"
HEALTHY=false
DEADLINE=$((SECONDS + 60))
while [ $SECONDS -lt $DEADLINE ]; do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$HEALTH_URL" || true)
[ "$STATUS" = "200" ] && HEALTHY=true && break
sleep 3
done
if [ "$HEALTHY" = true ]; then
echo "✅ Canary healthy! Promoting..."
fly deploy --app "$APP" --strategy rolling
echo "🎉 Production deploy complete"
else
echo "❌ Canary failed! Rolling back..."
fly releases rollback --app "$APP"
echo "⏪ Rolled back"
exit 1
fi
auto_stop_machines = "stop" for dev/staging to save costs; machines stop after idle timeout.auto_start_machines = true so machines wake on incoming requests with sub-second cold start..internal DNS for service-to-service calls; never expose internal services publicly.fly-replay header for write operations in multi-region setups to route to the primary region.