Fly.io flyctl for coding agents

A coding agent with shell access can use Fly.io’s command-line tool, flyctl, to inspect and manage cloud apps. The tool runs as the fly command. The agent can use it to deploy apps, check app status, and read logs. The agent can also manage secrets and Fly Machines, Fly.io’s virtual machines. Before suggesting a code change or deployment, the agent can check whether a named app is running.

The example below lists apps available to the signed-in account and reads the status of one app. These commands make network requests to Fly.io but do not change the app. Deploying is a separate action that updates the service.

Install and authenticate

On a machine with Homebrew, install the CLI with the command from Fly.io’s installation page:

brew install flyctl

The same page has an install script for macOS and Linux and a PowerShell script for Windows. Fly.io’s documentation uses fly as the command name. Authenticate with:

fly auth login

fly auth login opens a browser sign-in by default. Complete the sign-in flow when prompted. If you do not have a Fly.io account, the CLI also provides fly auth signup. Sign in outside the agent prompt. The agent needs access to the authenticated CLI session to make requests to your account. Treat shell access as permission to use the actions that account allows. Fly.io documents these commands and the CLI’s broader capabilities in its flyctl reference.

Check an app without changing it

First list the apps the authenticated account can access, then check the status of the target app:

fly apps list --json
fly status -a YOUR_APP_NAME --json

Replace YOUR_APP_NAME with the actual Fly.io app name. The first command shows the apps the account can access, across all organizations the user belongs to. The second asks Fly.io for the selected app’s current status, including its most recent deployment and the regions it runs in. Both fly apps list and fly status document a --json option, which gives the agent structured output to read. Without --json, the commands print text meant for people.

-a explicitly selects the app. Without it, flyctl looks for a fly.toml file in the current directory and uses the app name from that file. The output reports current status. It is not a deployment plan or a guarantee of future availability.

Both commands contact Fly.io. They read account and app information without changing configuration, secrets, or running Machines.

A realistic request to an agent would be:

Use fly apps list --json to find the Fly.io app named YOUR_APP_NAME, then run fly status -a YOUR_APP_NAME --json. Report the status shown. Do not deploy, change secrets, or modify Machines.

Keep inspection separate from deployment

fly deploy is a write action. It builds and deploys the configured app, changing the running service. Do not treat a status check as approval to run it.

Fly.io documents a staged way to automate deployment: use fly deploy --build-only --push to build and push an app image, then update Machines separately. An app image is the packaged version Fly.io uses to run the app. That command still pushes the image to Fly.io’s registry, but it does not update running Machines. A later rollout changes which image those Machines run. Fly’s custom deploy workflows also describe targeting Machines by region or process group, which lets an operator limit a rollout’s scope.

flyctl can target the wrong app when the current directory contains a fly.toml file for another app. In that case, -a YOUR_APP_NAME makes the target explicit. For read-only checks, use the explicit app name when the agent’s working directory might contain another app’s configuration.