Fly.io MCP. Manage global compute and persistent state via chat.
Works with every AI agent you already use
…and any MCP-compatible client
Just plug in your AI agents and start using Vinkius.
Fly.io MCP Server gives your AI client full control over your edge infrastructure. Monitor apps and machines, scale compute horizontally, handle persistent volumes, and run remote commands directly from natural conversation.
You can list apps, check machine health, and provision new Edge Machines without touching the CLI.
What your AI agents can do
Create machine
Adds a new, highly available Edge Machine inside an existing App space to increase compute capacity.
Delete machine
Permanently terminates and destroys a Fly Machine, stopping compute billing for that resource.
Exec machine
Runs a specific shell or Bash command inside a live Machine, useful for diagnostics or migrations.
List all Apps belonging to your organization and list the individual Machines inside a specific App, getting their unique IDs and placement regions.
Dynamically provision new Edge Machines to increase capacity or gracefully halt running Machines to save costs.
Run arbitrary shell or Bash commands (like ls or ps aux) directly inside a live Machine without needing SSH access.
List and manage hardware NVMe Volumes, keeping stateful data separate and independent from the compute layer.
Retrieve the operational baseline of an App, identifying anycast IPs, Wireguard ranges, and the cluster master region.
Ask AI about this MCP
Supported MCP Clients
Waiting for input…
Fly.io MCP Server: 10 Tools for Edge Control
These tools give your AI client direct access to your Fly.io cloud environment, allowing it to manage app spaces, individual machines, and persistent storage.
019d759ccreate machine
Adds a new, highly available Edge Machine inside an existing App space to increase compute capacity.
019d759cdelete machine
Permanently terminates and destroys a Fly Machine, stopping compute billing for that resource.
019d759cexec machine
Runs a specific shell or Bash command inside a live Machine, useful for diagnostics or migrations.
019d759cget app
Retrieves the operational state of an entire App, including its master region, Wireguard ranges, and any active global IP addresses.
019d759cget machine
Checks a single Machine's runtime status, including its Docker image digest and mapped persistent volumes.
019d759clist apps
Lists all App spaces within your Fly.io organization, which contain groups of machines and volumes.
019d759clist machines
Lists all individual MicroVM endpoints (Machines) within a specific App, providing their unique IDs and regions.
019d759clist volumes
Lists all persistent hardware NVMe Volumes attached to an App, managing stateful data separate from the compute nodes.
019d759cstart machine
Restarts a previously stopped or suspended Machine, bringing it back online for processing.
019d759cstop machine
Gracefully halts a running Machine, reducing costs when the service isn't actively receiving traffic.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with Fly.io, then connect any of our 4,700+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 4,700+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
What you can do with this MCP connector
Connect your AI client to the Fly.io MCP Server. You'll get full control over your edge infrastructure stack, managing everything from the App space down to individual microVMs. You can monitor apps and machines, scale compute horizontally, handle persistent volumes, and run remote commands—all through natural conversation.
Inspect App and Machine Status
List all App spaces in your organization using list_apps. You can then list every individual Machine within a specific App, getting their unique IDs and placement regions via list_machines. To check the operational baseline of an entire App, use get_app; this pulls the master region, Wireguard ranges, and any active global IP addresses.
You can also check a single Machine's runtime status, including its Docker image digest and mapped persistent volumes, by calling get_machine.
Scale Compute Resources
Need more juice? You can use create_machine to add a new, highly available Edge Machine inside an existing App space, increasing your compute capacity. If you need less power, stop_machine gracefully halts a running Machine, cutting costs when the service isn't handling traffic. You can also use start_machine to bring a previously suspended Machine back online for processing.
Execute Remote Commands
Run arbitrary shell or Bash commands—like ls or ps aux—directly inside a live Machine using exec_machine. This lets you run diagnostics or migrations without ever needing SSH access.
Manage Persistent Storagelist_volumes lets you list all persistent hardware NVMe Volumes attached to an App. You manage stateful data—think PostgreSQL or SQLite data—separately and independently from the compute nodes.
Core Operationslist_apps shows you every App space in your Fly.io org. list_machines shows every Machine in a specific App. get_app gives you the full status of an App, including its master region, Wireguard ranges, and global IPs. get_machine confirms a Machine's status, including its Docker image digest and mapped volumes. create_machine adds a new Machine. delete_machine permanently terminates a Machine, stopping compute billing. start_machine brings a machine online. stop_machine halts a machine.
How Fly.io MCP Works
- 1 Subscribe to the Fly.io server and provide your API token. This links your AI client to your cloud account.
- 2 Use a natural language prompt to request an action, like 'List all machines in my web-api app.'
- 3 The AI client executes the necessary tool call (e.g.,
list_machines), and the result is returned to you for follow-up actions.
The bottom line is that your AI client handles all the API calls; you just talk to it.
Who Is Fly.io MCP For?
This is for the platform engineer who needs to manage distributed systems across global edge points of presence. If your job involves keeping services running reliably in multiple regions—and you hate writing complex, multi-step scripts—this is for you. It cuts out the manual CLI dance.
Checks machine health across multiple global regions and triggers restarts or scaling events using simple chat prompts.
Runs database migrations or verifies deployment digests on a specific Machine directly from the chat, instead of SSHing in.
Audits complex network setups, mapping out anycast IPs and persistent volume attachments without manual CLI commands.
What Changes When You Connect
- Audit entire App networks and get the full baseline using
get_app. You instantly know the cluster master region and all assigned anycast IPs without running a dozen manual commands. - Scale compute on demand. Use
create_machineto provision a new Edge Machine quickly, orstop_machineto halt a resource when it's idle, saving money instantly. - Run diagnostics without SSH.
exec_machinelets you inject a shell command (likeps auxorls -la /app) directly into a running Machine, giving you immediate visibility. - Keep data separate from compute.
list_volumeslets you see all attached hardware NVMe Volumes, managing stateful data like Postgres logs independently of the machine's lifecycle. - Control the entire machine lifecycle. Use
list_machinesto find all endpoints, and thenstart_machineorstop_machineto manage their active status in bulk. - Get deep state visibility.
get_machineprovides the exact Docker image digest and runtime status for any Machine, which is crucial for verifying deployment integrity.
Real-World Use Cases
Debugging a Stalled Deployment
The deployment failed in one region. Instead of writing a complex script to check status, you ask your agent to run get_machine on the suspected machine. The agent returns the runtime state and the image digest, telling you exactly what version of the code is running and why it's stuck.
Scaling for a Traffic Spike
Traffic suddenly spikes in the Asia-Pacific region. You tell your agent, 'We need more capacity in APAC.' The agent uses create_machine to provision new, highly available Edge Machines immediately, handling the scaling logic so you don't have to wait on platform deploys.
Preparing for Downtime
You're shutting down an environment for maintenance. You ask the agent to stop_machine for all web-api machines. The agent gracefully halts every running node, cutting compute costs instantly, while leaving the necessary persistent volumes intact.
Verifying Data Integrity
A database migration needs to run. You ask the agent to exec_machine to run the migration script on the designated machine. The agent executes the command and returns the output, confirming the data change without needing terminal access.
The Tradeoffs
Sequential Status Checks
Trying to check if a machine is running by first running list_machines, then manually taking the ID, and then running get_machine for each one. This is slow and error-prone.
→
Instead, use list_machines to gather IDs, and then ask the agent to check the status of all machines in one go. This streamlines the process and prevents you from missing a node.
Manual Command Chaining
Writing a script that runs get_app to get the region, then uses that region to manually construct the list_machines call. This breaks if the region changes.
→
Let the agent handle the context. Ask the agent to 'list machines for my primary app.' The agent handles the dependency flow between get_app and list_machines automatically.
Ignoring Storage Boundaries
Assuming that stopping a machine (stop_machine) also deletes the associated data. This is a common mistake that leads to lost state.
→
Remember that list_volumes keeps your data safe. You can stop_machine to save money, knowing that your persistent volumes remain attached and ready for the next boot cycle.
When It Fits, When It Doesn't
Use this if your workflow requires managing the entire lifecycle of containerized applications across multiple global regions. Specifically, if you need to scale compute capacity, run diagnostics, or manage persistent data volumes without leaving your chat interface. It excels at coordinating the sequence of actions—like first running get_app to find the network ranges, then using list_machines to find endpoints, and finally running exec_machine to debug—all in one conversation. Don't use it if you only need to check a single, isolated API endpoint, or if your system architecture doesn't rely on microVMs. For pure, single-point read operations, a simple read-only API might suffice, but for anything that involves state change, this toolset is necessary.
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by Fly.io. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This server provides 10 capabilities that interface natively with Claude, ChatGPT, Cursor, and any MCP client. No middleware. No custom integration required.
Available Capabilities
Dealing with global infrastructure means fighting complex, multi-step CLIs.
Today, checking the health of a global service means jumping through hoops. You run `fly apps list` to see your App names. Then, for each App, you have to run `fly machines list` to get the IDs. If you want to check the status of a specific machine, you run `fly machines status <id>`. If you need to run a diagnostic, you have to manually SSH into it or use a complex command sequence. It's tedious, and one wrong flag breaks the whole thing.
With the Fly.io MCP Server, you just ask the agent: 'What's the status of my web-api machines?' It handles the `list_machines` and `get_machine` calls in the background. You get a clean, synthesized answer detailing the status, region, and image digest, right in the chat.
Fly.io MCP Server: Control the entire machine lifecycle
You can eliminate the need to manually sequence commands like `fly machines stop <id>` followed by `fly machines start <id>`. The agent handles the state transition, ensuring the machine is properly halted or booted up, and you can manage the flow of resources—like provisioning with `create_machine`—without ever leaving the conversation.
It changes everything. You stop thinking about the CLI syntax and start thinking about the system's actual state. You just tell it what you want, and it makes it happen.
Common Questions About Fly.io MCP
How do I use the `list_machines` tool to see all my endpoints? +
You simply ask the agent to list machines for a specific App. The agent runs list_machines and returns a list of all individual MicroVM IDs and their placement regions. This is the first step when you need an inventory of active nodes.
What is the difference between `get_machine` and `list_machines`? +
list_machines gives you an inventory of every machine in an App. get_machine gets the detailed, current state for one specific machine ID, showing its status, image digest, and attached volumes.
Can I run commands using `exec_machine` on a paused machine? +
No. exec_machine runs commands only on active machines. If the machine is stopped or suspended, you must first use start_machine before attempting to run any commands.
How does `list_volumes` help with my database? +
list_volumes shows the hardware NVMe Volumes attached to your App. This lets you manage stateful data (like Postgres data) separately from the machine that processes it. The data survives machine restarts.
What if I want to scale up my services? +
You use create_machine. Just tell the agent to 'add two more machines to the web-api app.' The agent provisions the necessary resources and increases your horizontal capacity automatically.
How do I use `get_app` to check my current network setup? +
The get_app tool retrieves the operational baseline for a specific App. It shows the primary region, assigned Wireguard ranges, and any active Anycast IPs. This is useful for mapping your network's global presence.
What is the difference between `create_machine` and `list_machines`? +
Use list_machines to see all existing Machine IDs and their placement regions. Use create_machine when you need to dynamically scale up, provisioning a new highly available Edge Machine within an App.
Can I use `exec_machine` to run a database migration command? +
Yes, exec_machine runs shell commands directly inside an active Machine. You can use it to run database migrations or diagnostics, effectively bypassing the need for SSH access.
Can my agent scale up my application by creating more machines in a specific region? +
Yes. Use the 'create_machine' tool. You can specify the region (e.g., 'iad', 'gru') and the Docker image. The agent will command the Fly.io orchestrator to boot up new VM instances instantly to handle increased demand.
How do I run a database migration or shell command on a live machine via chat? +
Use the 'exec_machine' tool. Provide the machine ID and the command. The agent bypasses SSH entirely by interacting directly with the hypervisor API to run your binary alongside the running container securely.
Can I check the health and image version of my active machines through the agent? +
Absolutely. The 'get_machine' tool retrieves exhaustive runtime states, including container health, current executing status (started/stopped), and the precise docker image digest actively booted into memory.
Multi-server workflows that include Fly.io MCP
MCP Workflow for Serverless Database Operations
Your staging database diverged from production three weeks ago because nobody tracks branch schemas , now the migration that works perfectly in staging fails catastrophically in production
Monitor Auto-Scaling Events Using MCP Servers
Machines monitored, cache hit rates measured, cold starts counted, scaling decisions documented , run your distributed backend from one prompt
Use it with your favorite AI tools
Connect this server to Cursor, Claude, VS Code, and more.
More in this category
Retool
Connect your AI assistant to Retool to inspect applications, audit users, review connected resources, and monitor workflows directly from chat.
Insomnia (Collaborative API Design)
Manage API designs and collections via Insomnia — list organizations, projects, and files, and audit API specs.
Chroma (Vector DB)
Manage vector embeddings via Chroma — list collections, query embeddings, and audit document counts directly from any AI agent.
You might also like
Freshsales (Sales CRM & Lead Scoring API)
Manage your sales pipeline via Freshsales — create leads, track contacts, manage deals, and automate CRM workflows directly from any AI agent.
Transport for London
Get live tube status, bus arrivals, journey planning, road disruptions and bike point data across London.
RCSB PDB
Explore 220K+ 3D molecular structures — search proteins, DNA, and RNA by name, experimental method, resolution, and bound ligands from the Protein Data Bank.