Fly.io MCP Server Cursor IDE Setup 2026

There's no config file to hand-write for this one. Fly.io ships its MCP server inside flyctl itself, and registering it with Cursor is a single command:

fly mcp server --cursor

That writes the entry into Cursor's MCP config for you. Restart Cursor, and your AI can inspect and manage live Fly apps, Machines, secrets, logs, and volumes from chat — the same things you'd normally reach for flyctl in a terminal to do.

Fly marks this server experimental in its own docs, and that word is doing real work — it's not boilerplate legal hedging. Treat every write or destructive command (deleting a Machine, rotating a secret, scaling an app down) as something to review before it runs, not something to trust blindly because it came from a natural-language prompt.

Prerequisites

Step 1: Register the Server

fly mcp server --cursor

Flyctl supports the same flag for other editors too — --claude, --vscode, --windsurf, --neovim, --zed — in case you're wiring this into more than one client. If you'd rather see the exact config it's about to write instead of trusting the flag, pass --config with a path to inspect or override it.

Step 2: Confirm Authentication

The server resolves credentials in this order: a bearer token passed in a request header, an --access-token flag, then the FLY_ACCESS_TOKEN environment variable. If you're already logged in via fly auth login, that session covers it — you don't need to generate a separate token for local use. For anything you plan to run outside your own machine (CI, a shared environment), generate a scoped access token from the Fly dashboard rather than reusing your personal login session.

Step 3: Restart Cursor and Test with the Inspector First

Before trusting Cursor's chat with this, run the built-in inspector to see the tool list with no LLM in the loop:

fly mcp server -i

This opens an interactive inspector at http://127.0.0.1:6274 where you can browse and manually invoke every exposed tool. It's worth five minutes here — you'll know exactly what "list my apps" is going to call before an AI agent decides to call something more destructive on your behalf.

Once you've checked that, restart Cursor and try:

List my Fly.io apps and show me the current status of each.

What's Exposed

The server maps to most of flyctl's command groups, not a hand-picked subset:

That's a wide surface. "Secrets" and "machine" in particular are the two groups where a wrong prompt does real damage — a mis-scoped "clean up unused secrets" request can remove one an app actually depends on.

Practical Workflows

Debugging a deploy from chat

Show me the last 100 log lines for the "api-prod" app and tell me
if there's an obvious error around the most recent deploy.

Checking Machine health across regions

List all Machines for "api-prod" and flag any that aren't in a
"started" state.

Scaling — with a confirmation step you control

Show me the current Machine count and region distribution for
"api-prod" before you suggest anything about scaling it.

Asking for the current state first, as a separate step, gives you a chance to sanity-check before authorizing anything that changes machine count.

When This Setup Breaks (and What to Lock Down)

It's marked experimental for a reason — don't skip the read-first habit. Fly's own guidance is to require human confirmation for write or destructive operations and to avoid exposing the MCP server beyond localhost without real access controls. If your Cursor workflow auto-approves tool calls, turn that off for this server specifically.

Token scope matters more here than on most MCP servers. A personal access token typically carries your full account's permissions. If you're wiring this into anything beyond your own local machine, generate a token scoped to a specific app or org instead of reusing a broad personal token — the blast radius of a leaked broad token against machine and secrets tools is a lot worse than against a read-only server.

"Command not found" for fly mcp server. This subcommand shipped later than the base CLI. Run fly version update and check fly version afterward — if it's still missing, you're likely on a pinned older build (common in CI images) rather than hitting an actual config problem.

When NOT to use this MCP server: if you're managing production infrastructure changes that need an audit trail or team review, don't route them through an AI chat prompt just because it's convenient — use flyctl directly or your normal deploy pipeline, and reserve the MCP connection for inspection, debugging, and read-heavy workflows where a mistaken tool call costs you nothing worse than a wasted query.

Frequently Asked Questions

Q: Is the Fly.io MCP server official, or a community wrapper around flyctl?
A: Official — it ships inside flyctl itself as the fly mcp server subcommand, maintained by Fly.io (superfly on GitHub), not a third-party wrapper.

Q: Can it deploy new apps, or only manage existing ones?
A: It exposes most of flyctl's command groups, including apps and machine management, so app-level operations are in scope. Whether a specific deploy action works depends on which flyctl subcommands are mapped in your installed version — check the inspector (fly mcp server -i) to see the exact current tool list rather than assuming parity with every flyctl command.

Q: Do I need a separate Fly access token, or does my CLI login work?
A: If you're already authenticated via fly auth login on the machine running Cursor, that session is sufficient. A separate FLY_ACCESS_TOKEN is mainly for cases where you want a scoped, revocable credential instead of your full personal session — recommended for anything beyond your own laptop.

Q: What does "experimental" actually mean for reliability here?
A: It means tool names, behavior, and safety defaults may still change, and Fly explicitly recommends requiring human confirmation for write/destructive calls rather than trusting full autonomy. It's stable enough for daily inspection and debugging use; treat destructive operations with the same caution you'd apply to any new automation touching production.

Q: Can I restrict which flyctl command groups the MCP server exposes?
A: The --config flag lets you point at a specific configuration instead of the default, which is the mechanism for narrowing scope if you don't want the full command-group surface available to an AI client. Review the inspector output first to see what's exposed by default before deciding what to trim.

Related Guides

---