Loading…
Topic
Fly.io
45 posts about Fly.io. Every summary links to the original.
- 45 posts
- 1 company
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Shared Nothing Architecture
Shared-nothing architecture is presented as a scaling model for Showcase, a Ruby on Rails ballroom-competition application that began on a Mac Mini and grew to cloud VMs serving events in multiple regions. Because each event has few geographically concentrated users, a roughly one-megabyte SQLite database, about one transaction per second, and typical response times of 100ms or less, the design keeps state separate rather than sharing databases and Redis across events. The implementation runs an event’s services on one Fly.io VM, repeats that unit across machines or regions, and can place multiple event instances on one server with Phusion Passenger, NGINX, volumes, and a shared Action Cable process. It specifies 1GB machines with 2G swap after observing about 220MB idle and 450MB active RAM, and recommends WireGuard; the conclusion is that local state and fewer network calls suit this workload and can improve throughput and reliability.
Launching MCP Servers on Fly.io
The post presents Fly.io’s approach to simplifying remote deployment of Model Context Protocol (MCP) servers, which otherwise require client-specific JSON configuration, local processes or HTTP hosting, and potentially cumbersome OAuth 2.1 setup. It uses the Slack MCP Server as a demonstration, converting its npx command into a fly mcp launch invocation with --claude, --server, and secret flags for the bot token and team ID. Running this requires flyctl v0.3.125 or later, and the command supports Fly.io options including auto-stop, file contents, flycast, regions, volumes, secrets, and VM sizes. Built-in configuration support covers Claude, Cursor, Neovim, VS Code, Windsurf, and Zed, with bearer-token authentication enabled by default on both server and client. The broader beta support includes multiple transports, Machines API deployment, separate Machines or containers, in-application deployment, and HTTP Authorization, WireGuard tunnels, flycast, or reverse proxies.
Provisioning Machines using MCPs
Fly.io’s flyctl MCP server lets LLMs such as Claude or Cursor use tools to inspect and modify application resources, demonstrated by creating a volume and adding support for all volume commands. The author describes asking Claude to identify unattached volumes and delete the oldest, while noting that flyctl’s mounted-volume safeguards provided an error if destruction was unsafe. Compared with writing against the Machines API, using flyctl directly, or navigating the dashboard, the conversational workflow surfaced an observation and turned it into an action with less manual effort. The post outlines a future in which an LLM proposes deployment plans, examines build errors and logs, and acts through MCP servers on Fly.io’s private network. Users can try the current open-source server with fly version upgrade to v0.3.117, configure an LLM, or run the MCP Inspector; apps, logs, machines, orgs, platform status, and volumes are roughed in.
30 Minutes With MCP and flyctl
Kurt Mackey describes building a minimal MCP server for flyctl in 30 minutes, motivated by testing how an LLM could inspect deployed applications. MCP connects an LLM client to server-exported tools through JSON exchanges; this implementation uses stdio mode, a Go MCP library, and exposes only fly logs and fly status, producing roughly 90 lines of code. Existing JSON modes in flyctl commands made the tools easier to drive from automation. When pointed at unpkg through Claude, the server surfaced a globally distributed deployment, identified two critical machines, and connected repeated restarts and oom_killed events to Bun using about 3.7 GB of a machine’s 4 GB allocation. The post calls the result surprisingly useful while warning that local MCP servers give cloud-hosted Claude access to native programs and would be safer in isolation.
We're Cutting L40S Prices In Half
Fly.io lowered the hourly price of NVIDIA L40S GPUs to $1.25, making them available at the same price as A10s after customer data showed that A10s—not the more powerful cards—were its most popular GPU. The post argues that most users adding GPUs to fast networks are running inference rather than training, making networking, memory, object storage, and request latency more important than access to an H100. The L40S is described as an AI-optimized L40 with AI compute performance comparable to an A100, while the L40 retains graphics hardware and is designed for rack use with more memory and lower energy consumption than gaming GPUs. The intended combination places model parameters, datasets, and compute near one another on Fly.io’s Anycast network and Tigris object storage. Examples include Llama 3.1 70B, Flux, Whisper, SegAlign, and DOOM Eternal.
Scaling Large Language Models to zero with Ollama
Running GPU nodes for language-model inference can be costly because they often sit idle between requests, so this guide configures Ollama on a Fly.io Machine that scales to zero when idle. Ollama is described as a wrapper around llama.cpp, enabling self-hosted models with GPU acceleration, while about 70 lines of Go add authentication to protect the endpoint from unauthorized use. Deployment uses an A100-40GB GPU, a private Flycast address, automatic start and stop settings, and a 100GB persistent volume mounted at /root/.ollama so downloaded models survive stopped Machines. A stopped Machine no longer incurs GPU charges, but scaling to zero suspends it on the same host and may fail to wake during capacity issues. The setup supports CLI and API requests, WireGuard access, custom Modelfiles, and JSON-mode function-calling workflows.
Rethinking Serverless with FLAME
Rethinking Serverless with FLAME presents a pattern for running selected application functions on short-lived copies of the full app instead of moving code into bespoke FaaS services. FLAME, short for Fleeting Lambda Application for Modular Execution, uses FLAME.call to send a function and closed-over values to a runner pool, while retaining access to the application’s database connections and other code. The Elixir flame library includes LocalBackend and FlyBackend adapters, and Fly.io can boot a same-image Machine in the parent’s region in about three seconds. Runners may stay warm, scale to zero, or grow elastically based on configuration. The post also describes process-based streaming with LiveView and supervision and monitoring mechanisms for transient runners.
How I Fly
This article describes how Xe Iaso uses Fly.io to host a blog, CDN, and experimental personal projects while deploying services near users. The blog backend runs in Toronto, while XeDN runs in 35 datacenters, fetches missing files from Backblaze B2, and uses caching and traffic shifting to tolerate individual node failures. Arsène runs every 12 hours, asking the ChatGPT API for posts, using Stable Diffusion for illustrations through an Automatic1111 API on a private network, then sending images to XeDN for global delivery. The setup emphasizes reusable, interoperable building blocks rather than isolated projects, with Fly.io handling deployment, networking, and scaling concerns. Xe reports that three 256 MB Machines ran XeDN for a year, while Arsène still runs on one, and says applications can scale to zero when idle.
Automated Sentry Error Tracking
Fly.io announces Sentry as the default error-monitoring tool for its applications, with new deployments receiving an automatically provisioned Sentry project and existing apps using flyctl ext sentry create. Each organization receives one year of monthly Team Plan credits covering 50,000 error events, 100,000 performance units, 500 session replays, and 1GB of attachment storage. For Rails apps, flyctl launch installs the required gems, creates initializers, and sets the SENTRY_DSN secret, allowing boot failures, memory exhaustion, exceptions, latency issues, and crashes to reach Sentry. The post demonstrates a deliberately raised Ruby exception, then uses flyctl apps errors to open the Sentry issue dashboard and identify the bug; planned extensions include release tracking and out-of-memory events.
Fly.io ❤️ Bun
Fly.io is preparing support for Bun as Bun 1.0 approaches, expanding beyond its ongoing Node.js work because Bun aims for complete Node.js API compatibility. With flyctl 0.1.54 and @flydotio/dockerfile 0.3.3, users can launch and deploy Bun applications through fly launch and fly deploy if Bun 0.5.3 or later is installed and package.json includes an eligible start, module/type, or main configuration. The post says applications following Bun’s Quickstart and Fly’s hands-on walkthrough can be deployed, and provides a sample. Support is beta, with noted compatibility issues including bun install lacking --prune, unsupported throwIfNoEntry in fs.statSync, and readline-based programs failing to exit; shared Dockerfile generation means fixes for either runtime generally benefit both.
Deploying LangChain to Fly.io
Deploying a minimal LangChain application to Fly.io, using Flask, requires a small Python project that accepts a place and asks an OpenAI-backed model for three places to eat there. The example uses LangChain’s OpenAI wrapper, PromptTemplate, temperature 0.9, and a default Berlin value, while Flask routes requests at / or / and renders the model’s split response in HTML. Local setup includes a virtual environment, pinned Flask, gunicorn, langchain, openai, and python-dotenv dependencies, with OPENAI_API_KEY stored in a local .env file; production uses gunicorn rather than Flask’s development server. Fly launch configures the app name, organization, and deployment region, and fly deploy builds and publishes an image before provisioning machines. The article concludes that more complex, user-dependent requests require LangChain agents and tools, such as Google Places API, because language models lack real-time data and internet browsing.
Fly.io ❤️ JS
Fly.io proposes a general-purpose way to deploy JavaScript and Node.js applications despite the ecosystem’s many frameworks, package managers, runtimes, and TypeScript conventions. Its dockerfile-node project uses package.json, lockfiles, and dependency metadata to generate a baseline Dockerfile, .dockerignore, and optionally a docker-entrypoint script; users can invoke it with npx @flydotio/dockerfile. Conditional EJS templates accommodate framework-specific requirements, with initial templates for Express, Fastify, Gatsby, Nest, Next, Nuxt, and Remix, though current support may extend only to a splash screen. Future plans include replacing Fly.io’s existing flyctl scanners, integrating deployment-time secrets, volumes, databases, and health checks, and adding customization such as build caching, swap, Docker Compose generation, browser setup, and non-root execution.
Logbook: November 14 to December 5, 2022
An edition of Fly’s Logbook covering November 14 to December 5, 2022 collects updates and tutorials for building and operating applications on Fly. It features a real-time collaboration example that connects Replicache with WebSockets and Fly-Replay, plus a LiveWire walkthrough for streaming server content to browsers and another for unloading data during large-dataset pagination. A separate guide explains how to run Supercronic from Fly Dockerfiles when precise cron timing is needed beyond Fly Machines’ monthly, weekly, daily, and hourly scheduling options. The edition also recounts how Fly Postgres was built, despite Fly’s stated preference for off-platform database services such as RDS, CrunchyData, and PlanetScale. The post notes that the update followed a longer break while many Fly staff spent time with family over Thanksgiving.
Logbook: October 21 to 28, 2022
This weekly Logbook changes format from tracking every monthly change to an over-generalized weekly tl;dr of Fly.io updates intended to help with deploying or managing apps. It reports new Postgres documentation for performing failovers, regional failovers, setting up and attaching a database, and migrating one from Heroku, while warning that Fly Postgres is not fully managed and requires customer monitoring. The post also points to an example of integrating the Elastic Stack (ELK) with a Laravel app for user analytics and reporting, plus instructions for shutting down an idle Phoenix app on Fly Machines after a configurable period without requests. It explains that newly launched Fly apps do not yet deploy to Machines in the same way, while fly pg create does use Fly Machines, and directs readers to comparisons of the app versions. Finally, it notes colorblind-friendly dashboard improvements and previews more Postgres documentation work.
Launching Laravel Bytes
Fly is launching Laravel Bytes, a new publication focused on Laravel and on deploying Laravel applications across the globe. The announcement frames the site as a place for future discussions of global-user-base considerations, along with Laravel tips, strategies, how-tos, and coverage of Livewire and real-time apps. Laravel is supported by the fly launch command, and the documented quick start is to enter an existing Laravel app directory and run fly launch. A more comprehensive guide covers running Laravel on Fly with Redis, MySQL, queue workers, and cron tasks, while the post directs readers to deployment documentation and says a Laravel app can be launched in a few minutes.
Logbook - 2022-06-10
Fly.io’s June 10, 2022 logbook lists platform, dashboard, deployment, and account-management changes for its globally distributed application hosting service. WireGuard peer synchronization now adds only peers whose state changed, while removing a global lock from proxy tracing instrumentation improves TLS handshaking and HTTP parsing under load; the post says these changes should speed userspace features, avoid API timeouts, and reduce response times. Deployments gain build-time secrets through fly deploy’s --build-secret flag, larger rolling-deploy batches that are expected to make multi-region releases 2–5x faster, and restored Turboku webhook redeployment from Heroku. Dashboard updates include intelligent longpolling fallback, visible certificate deletion controls, monitoring links, safer app deletion confirmation, and corrected metrics and coupon visibility, while the Jupyter launcher now requires a credit card after abuse.
Logbook - 2022-06-01
Fly.io’s June 1, 2022 logbook records a week of platform, tooling, documentation, and dashboard changes, with forum community feedback driving several logged updates. The release adds rolling behavior to fly restart, extends fly status --all’s failed-VM visibility from two days to seven, supplies Laravel and Node.js examples, and introduces the first official Terraform provider with Machines API parity. Release commands receive 512MB of swap without increasing normal app RAM, while preview GraphQL endpoints fetch volumes, IPs, and certificates directly by ID to support Terraform imports and stateful tooling. Dashboard work adds Livebook upgrades, clearer billing and typography, individual Machine event tables, and fixes for IPv6 copying, organization-plan changes, cross-tab logout, billing URLs, misleading volume usage, and two-factor input limits.
Logbook - 2022-05-05
Fly.io’s 2022-05-05 Logbook reports a broad set of infrastructure, product, security, documentation, and bug-fix updates intended to run customer apps faster and more reliably in VMs close to users worldwide. Remote builders now use regional Docker Hub mirrors, clean unused RUN --mount=type=cache build caches, and perform cleanup at startup and shutdown; the new behavior is default for new builders, while existing builders must be destroyed to receive it. WireGuard gateway improvements address load issues, add regional capacity, and support future redundancy, while another IAD gateway is intended to improve connectivity for customer 6pn networks and CI, especially GitHub Actions. The update also adds API security logging for SOC2, re-enables OpenTelemetry, speeds the proxy build pipeline, changes default persistent volume size from 10GB to 3GB, and ships a dashboard, payment retry feature, VSCode fly.toml validation and documentation changes, alongside GraphQL performance work and fixes for monitoring, invoices, encryption, and Homebrew updates.
Turbocharge your Heroku Apps with New Turboku
New Turboku clones a Heroku app on Fly.io without requiring data migration, while the resulting app should be able to use services such as Heroku Postgres or Redis through transferred environment variables. The rebuilt workflow integrates flyctl with Fly.io’s remote builders instead of AWS CodeBuild: it queries Heroku, selects a region, converts config variables to secrets, and generates fly.toml, an ephemeral Dockerfile, and a reconstituted Procfile from the slug and process map. A Phoenix LiveView web launcher wraps the deployment by starting a Fly.io Machine running flyctl, while the CLI is available through flyctl turboku. The launcher also configures webhooks and watches environment-variable changes for automatic updates, whereas the CLI lacks webhook integration; the source reports about one millisecond of added database latency for a US-based app.
Self-service account deactivation: why it’s harder than you would think
Fly.io introduces a self-service UI for deactivating accounts, replacing the previous requirement to email support. The difficulty is preventing a “delete everything” action from accidentally destroying infrastructure, because users may own apps, share organizations, and administer shared applications. The workflow first addresses app deletion and resource cleanup, then points migrating users toward certificate and DNS changes, while reminding organization administrators to delete or transfer organizations. Rather than embedding every task in one action, the UI guides users to the relevant pages and usually requires deleting only the apps they own. Automatic deactivation still cannot handle accounts involved in shared organizations or organizations administered for others; those cases require help, and the UI identifies the blocking organization step.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.