fly · Fly.io

Fly.io flyctl Agent 使用指南

部署并检查 Fly.io 应用、Machines、日志和发布。

官方工具操作风险: R2R3docs-verified
Agent 适配度
84/100
证据可信度
docs-verified
文档检查日期
2026-07-10
独立测试版本
尚未独立测试

为 Agent 安装

选择与运行环境匹配的官方安装方式。在团队或 CI 环境中固定版本,并先运行版本检查。

Homebrew推荐
macos · linux
$ shell
brew install flyctl
认证与最小权限
只提供任务需要的权限,凭证通过环境变量或平台密钥存储传入,不能写进提示词、仓库或日志。
需要认证支持无界面认证

Token 仅授权任务所需组织与应用。

认证方式
browser login, access token
密钥环境变量
FLY_API_TOKEN
凭据保存位置
无界面运行时,在进程启动时从 CI 或平台密钥管理器注入 FLY_API_TOKEN。本地交互使用时,若官方客户端支持,应优先使用 CLI 或操作系统凭据存储;不要把值写入仓库文件。
Agent 与运行环境兼容性
先确认 Agent 能使用 Shell,再检查平台、网络与凭证是否可用。
claude-codecodexgemini-clicopilot-cli
Environments
local, ci, container, headless, remote
Platforms
macos, linux, windows

用于稳定自动化的结构化输出

优先使用机器可读格式,并把 stdout 作为结果、stderr 作为诊断信息分别处理。

json · text
在支持的命令中使用 --json,并将诊断日志保留在 stderr。
--json

尚未记录真实输出样例

当前结构化输出能力来自官方文档。完成有限、非破坏性执行并保存 stdout 前,不展示推测样例或伪造 Schema。

R0–R3 命令风险指南

风险按单条命令判断。R0 是本地或远程只读,R1 是可逆的本地写入,R2 会改变远程状态,R3 可能造成不可逆或生产级影响。

只读不等于可公开

R0 只表示命令不更改本地或远程状态。只读命令仍可能返回令牌、身份信息、配置或生产数据;只展示完成任务所需的最少内容,不得写入日志、Prompt 或提交内容。

R0检查应用状态
读取 Machines 和部署状态。
$ shell
fly status --app APP --json
可重复执行敏感输出
R2部署应用
会构建并远程发布应用代码。
$ shell
fly deploy --app APP
执行前必须确认可能产生重复变更
R3销毁应用
会删除远程应用及其关联状态。
$ shell
fly apps destroy APP
执行前必须确认可能产生重复变更

Agent Readiness 评分依据

适配度描述 Agent 操作工具的稳定程度,不代表所有命令都安全,也不替代独立执行测试。

文档证据对应的 Agent Readiness 为 84/100;尚未记录本地执行测试。

结构化输出
在支持的命令中使用 --json,并将诊断日志保留在 stderr。
18/20
x
无界面运行
官方文档描述了非交互认证或执行路径。
14/15
x
安全控制
CLI Finder 将读取命令与需要确认的命令分开。
11/15
x
确定性
命令尽量使用显式参数和文档支持的输出控制。
8/10
x
认证
Token 仅授权任务所需组织与应用。
8/10
x
文档
本条目引用了 2026-07-10 检查的官方文档。
9/10
x
安装
官方安装路径覆盖 macOS、Linux 和 Windows。
8/8
x
维护状态
条目链接了官方源码仓库,便于检查发布与维护状态。
6/7
x
Agent 产物
CLI Finder 可生成基于注册表的 Skill 和策略;该分数不假定工具自身提供这些产物。
2/5
x

生成 Skill 或 Agent 策略

选择目标 Agent 和安全模式,生成包含安装、允许命令、确认边界与证据说明的可复制产物。

生成结果预览
SKILL.md
---
name: flyctl-agent-workflow
description: Use Fly.io flyctl for Fly.io apps, Machines, logs with explicit command risk and evidence boundaries.
---

# Fly.io flyctl agent workflow

Use this skill when the task needs Fly.io apps, Machines, logs, releases.

## Evidence boundary

- Registry confidence: `docs-verified`
- Documentation checked: `2026-07-10`
- Locally tested version: `not tested`
- Do not describe this CLI as locally verified until its commands have actually been executed in an isolated environment.

## Executed smoke checks

- No local execution record is available.

## Installation

- Homebrew (macos, linux): `brew install flyctl`

## Authentication

- Methods: browser login, access token
- Secret environment variables: `FLY_API_TOKEN`
- Minimum permissions: Use a token scoped to the organization and app required by the task.
- Credential storage: For headless runs, inject FLY_API_TOKEN from the CI or platform secret manager at process start. For local interactive use, prefer the CLI or operating-system credential store when the official client supports one. Never save values in repository files.
- Never print, persist, or commit credential values.

## Allowed commands (read-only)

- `fly status --app APP --json` — R0: Reads Machines and deployment state.

## Commands requiring explicit approval (read-only)

- None recorded.

## Forbidden commands (read-only)

- R2 `fly deploy --app APP` — Builds and releases application code remotely.
- R3 `fly apps destroy APP` — Deletes the remote application and attached state.

## Execution rules

1. Mode boundary: R0 exact commands may be used; R1, R2, and R3 commands are forbidden.
2. Confirm the selected account, project, context, database, namespace, or environment before any command.
3. Prefer structured output using `--json`.
4. Capture the exact command, exit code, stdout, and stderr separately.
5. A generated prefix policy must prompt unless that exact prefix is explicitly marked suffix-safe; do not infer safety from the executable name.
6. Never broaden credentials or disable safety controls to make a command succeed.

## Official sources

- [flyctl documentation](https://fly.io/docs/flyctl/)
- [flyctl documentation source repository](https://github.com/superfly/flyctl)

这个任务该用 CLI、MCP 还是 API

CLI
适合在开发机、CI 或容器里复用现有 Shell、凭证和脚本,尤其适合短时、可观察的任务。
MCP
当 Agent 需要受控工具定义、委托身份或由服务端集中治理访问时,MCP 可能更合适。
API
当工作流是应用内长期集成、批量调用或事件驱动时,直接 API 往往比启动进程更稳定。
查看 CLI 与 MCP 完整对比

验证记录与官方证据

CLI Finder 分开记录文档检查和真实执行。未执行过的安装、帮助、退出码与输出不能标为 Verified。

当前证据边界
已审阅官方文档,但未在本地执行安装、帮助输出、退出码、无界面行为或结构化输出测试。
证据可信度
docs-verified
独立测试版本
尚未独立测试
测试环境
未记录
官方来源
打开官方资料确认当前版本和命令。

替代工具与相关入口

在明确环境边界的前提下部署应用并检查云资源。
无需依赖控制台即可创建、检查和提升 Vercel 部署。
开发、部署并检查 Cloudflare Workers 及相关资源。
验证配置和构建输出,先本地或预览检查,再只向明确环境部署并完成验证。
用确定性本地工具配合 Codex,只在沙箱和审批规则允许时加入远程 CLI。
本地和 CI 的 shell 工作优先 CLI;更看重 typed discovery 和中介式远程权限时选 MCP。

Agent 使用 Fly.io flyctl 的常见问题