Fly.io MCP Server Cursor IDE Setup 2026: fly mcp server --cursor
Fly.io MCP server Cursor IDE setup 2026: one flyctl command registers the official MCP server, giving Cursor access to apps, machines, secrets, and logs — plus fly mcp list to verify config and SSE/stream transport for shared setups. Experimental — here's what to lock down first.
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
flyctl installed and up to date — run fly version update if you haven't touched it recently, since the mcp server subcommand is newer than the CLI itselfflyctl session (fly auth login) or a Fly access tokenStep 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.
Checking What's Already Registered
If you've wired this into more than one client (Cursor plus Claude, VS Code, or Zed), it's easy to lose track of which config points where. flyctl has a dedicated lookup command for this:
fly mcp list --cursor
This prints the current MCP server entry as configured for Cursor specifically, so you can confirm the token, command, and args actually match what you intended instead of assuming a previous fly mcp server --cursor run got applied correctly.
Running It Over the Network Instead of Stdio
Everything above assumes the default: Cursor launches fly mcp server as a local stdio process. If you need the server reachable over the network instead — for a shared team environment rather than one laptop — fly mcp server also supports SSE and streaming HTTP transports:
fly mcp server --sse
# or
fly mcp server --stream
Both bind to 127.0.0.1:8080 by default. That default binding matters: it's still localhost-only out of the box, so exposing it beyond your own machine means putting it behind your own reverse proxy and access controls — the server itself doesn't add authentication for network transport beyond what you supply via token or header. Given the "secrets" and "machine" tool groups this server exposes, treat opening it up to a network as a bigger decision than the one-line flag makes it look.
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.
Q: Can I run the Fly.io MCP server over the network instead of stdio, for a shared team setup?
A: Yes — fly mcp server --sse or fly mcp server --stream switch it to SSE or streaming HTTP transport instead of the default local stdio process. Both still bind to 127.0.0.1:8080 by default, so reaching it from another machine requires your own reverse proxy and access controls; the flag alone doesn't add network-level authentication.
Q: How do I check which MCP config was actually written for a given client?
A: Run fly mcp list --cursor (swap the flag for --claude, --vscode, etc.) to print the entry as currently configured for that client, rather than assuming a prior fly mcp server --cursor run applied cleanly.