# fly.io Fly.io is a company offering hardware-isolated virtual machines that boot quickly, run near users, and scale to large workloads. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How Fly.io logging works and how to collect application logs DevFeed: [How Fly.io logging works and how to collect application logs]() Original publisher: [Read original article]() Author: Muhammed Ali Published: 2026-08-13T07:00:00Z Content type: tutorial Language: en Sources: [Honeybadger]() Topics: [fly.io](), [Logging](), [App](), [FastAPI](), [Streams](), [Deployment]() Tags: [app](), [deployment](), [devops-articles](), [fastapi](), [fly-io](), [guide](), [how-to](), [logging](), [streams](), [vector]() ### AI overview This tutorial explains how Fly.io collects and routes application logs, including output from standard output and standard error. It also demonstrates a FastAPI application that generates different log messages and describes handling logs with Honeybadger. ### Source excerpt Logging is an import part of debugging an app. Without a good method of catching errors or logs in general, you would end up with uncaught issues and could also lose valuable customers in the process. Read this article to learn how to effectively handle logs on Fly.io. ## The Design & Implementation of Sprites DevFeed: [The Design & Implementation of Sprites]() Original publisher: [Read original article]() Published: 2026-01-14T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [fly](), [Cloud](), [Linux](), [Orchestration](), [ssh](), [Containers](), [Docker]() Tags: [cdn](), [close-to-users](), [cloud](), [cloud-computing](), [containers](), [cost](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [linux](), [networking](), [orchestration](), [platform](), [postgresql-clusters](), [scale](), [servers](), [ssh]() ### AI overview Fly.io's article introduces Sprites, disposable Linux virtual machines designed to start in seconds, provide root access and a durable 100GB filesystem, and automatically sleep when inactive. It explains the orchestration decisions behind the platform, including moving away from container images while retaining convenient, Docker-like workflows. ### Source excerpt We're Fly.io, and this is the place in the post where we'd normally tell you that our job is to take your containers and run them on our own hardware all around the world. But last week, we launched Sprites, and they don't work that way at all. Sprites are something new: Docker without Docker without Docker. This post is about how they work. Replacement-level homeowners buy boxes of pens and stick them in "the pen drawer". What the elites know: you have to think adversarially about pens. "The purpose of a system is what it does"; a household's is to uniformly distribute pens. Months from now, the drawer will be empty, no matter how many pens you stockpile. Instead, scatter pens every place you could possibly think to look for one -- drawers, ledges, desks. Any time anybody needs a pen, several are at hand, in exactly the first place they look. This is the best way I've found to articulate the idea of Sprites, the platform we just launched at Fly.io. Sprites are ball-point disposable computers. Whatever mark you mean to make, we've rigged it so you're never more than a second or two away from having a Sprite to do it with. Sprites are Linux virtual machines. You get root. They create in just a second or two: so fast, the experience of creating and shelling into one is identical to SSH'ing into a machine that already exists. Sprites all have a 100GB durable root filesystem. They put themselves to sleep automatically when inactive, and cost practically nothing while asleep. As a result, I barely feel the need to name my Sprites. Sometimes I'll just type sprite create dkjsdjk and start some task. People at Fly.io who use Sprites have dozens hanging around. There aren't yet many things in cloud computing that have the exact shape Sprites do: Instant creation No time limits Persistent disk Auto-sleep to a cheap inactive state This is a post about how we managed to get this working. We created a new orchestration stack that undoes some of the core decisions we made for Fly ## Kurt Got Got DevFeed: [Kurt Got Got]() Original publisher: [Read original article]() Published: 2025-10-08T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [X (Twitter)](), [vulnerability](), [Exploit]() Tags: [cdn](), [close-to-users](), [deploy-app-servers](), [developer](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [phishing](), [postgresql-clusters](), [servers](), [vulnerability]() ### AI overview Fly.io describes how its CEO was phished, leading to an account takeover of the company's Twitter/X account. The attack exploited social-engineering cues related to the company's use of developer memes, and the team responded by auditing access to login credentials in 1Password and removing recent access. ### Source excerpt The $FLY Airdrop is live! Claim your share of the token powering Fly.io's global network of 3M+ apps and (🤮) own a piece of the sky! We know. Our Twitter got owned. We knew within moments of it happening. We know exactly how it happened. Nothing was at risk other than our Twitter account (and one Fly.io employee's self-esteem). Also: for fuck's sake. Here's what happened: Kurt Mackey, our intrepid CEO, got phished. Had this been an impactful attack, we would not be this flippant about it. For this, though, any other tone on our part would be false. How They Got Kurt Two reasons: one, it was a pretty good phishing attack, and two, Twitter fell outside the "things we take seriously" boundary. The phishing attack was effective because it exploited a deep psychological vulnerability in our management team: we are old and out of touch with the youths of today. For many months now, we've had an contractor/intern-type-person Boosting Our Brand on Twitter by posting dank developer memes (I think that's what they're called). The thing about this dankery is that we don't really understand it. I mean, hold on, we know what the memes mean technically. We just don't get why they're funny. However, in pushing back on them, we're up against two powerful forces: The dank memes appear to perform better than the stuff we ourselves write on Twitter. We are reliably informed by our zoomer children that we are too cringe to be trusted on these matters. Here's the phish Kurt got: Diabolical. Like a scalpel expertly wielded against Kurt's deepest middle-aged-dude insecurity. Our ruthless attackers clinically designed this email to trigger an autonomic Kurt response: "oh, what the fuck is this, and why did we post it?" ATO is cool-kid for "got owned" I'm getting a little ahead of the story here. We knew our X.com account had suffered an ATO because a bunch of us simultaneously got another email saying that the @flydotio account's email address now pointed to achilles19969@gmail.com. Our im ## Phoenix.new - The Remote AI Runtime for Phoenix DevFeed: [Phoenix.new - The Remote AI Runtime for Phoenix]() Original publisher: [Read original article]() Published: 2025-06-20T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [phoenix](), [Elixir](), [Artificial Intelligence](), [Large Language Model](), [coding](), [fly.io](), [fly](), [browser](), [real-time](), [Visual Studio Code](), [Front end](), [JavaScript]() Tags: [agent](), [agents](), [ai](), [browser](), [cdn](), [close-to-users](), [coding](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [javascript](), [networking](), [phoenix](), [postgresql-clusters](), [real-time](), [servers](), [vscode]() ### AI overview Phoenix.new is a fully online coding agent tailored to Elixir and Phoenix. It runs in a browser-backed, isolated Fly Machine with shell access, a VSCode interface, and browser tools that let the agent inspect front-end changes and JavaScript state while building real-time collaborative applications. ### Source excerpt I'm Chris McCord, the creator of Elixir's Phoenix framework. For the past several months, I've been working on a skunkworks project at Fly.io, and it's time to show it off. I wanted LLM agents to work just as well with Elixir as they do with Python and JavaScript. Last December, in order to figure out what that was going to take, I started a little weekend project to find out how difficult it would be to build a coding agent in Elixir. A few weeks later, I had it spitting out working Phoenix applications and driving a full in-browser IDE. I knew this wasn't going to stay a weekend project. If you follow me on Twitter, you've probably seen me teasing this work as it picked up steam. We're at a point where we're pretty serious about this thing, and so it's time to make a formal introduction. World, meet Phoenix.new, a batteries-included fully-online coding agent tailored to Elixir and Phoenix. I think it's going to be the fastest way to build collaborative, real-time applications. Let's see it in action: What's Interesting About Phoenix.new First, even though it runs entirely in your browser, Phoenix.new gives both you and your agent a root shell, in an ephemeral virtual machine (a Fly Machine) that gives our agent loop free rein to install things and run programs -- without any risk of messing up your local machine. You don't think about any of this; you just open up the VSCode interface, push the shell button, and there you are, on the isolated machine you share with the Phoenix.new agent. Second, it's an agent system I built specifically for Phoenix. Phoenix is about real-time collaborative applications, and Phoenix.new knows what that means. To that end, Phoenix.new includes, in both its UI and its agent tools, a full browser. The Phoenix.new agent uses that browser "headlessly" to check its own front-end changes and interact with the app. Because it's a full browser, instead of trying to iterate on screenshots, the agent sees real page content and JavaScript state ## A Bug in Fly.io's Rust Anycast Router DevFeed: [A Bug in Fly.io's Rust Anycast Router]() Original publisher: [Read original article]() Published: 2025-05-28T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [Rust](), [networking](), [Tokio]() Tags: [bug](), [cdn](), [close-to-users](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [network](), [networking](), [postgresql-clusters](), [proxy](), [rust](), [servers](), [tokio]() ### AI overview Fly.io describes a bug in fly-proxy, its Rust Anycast router. The post explains the challenge of distributing rapidly changing routing state for apps and connections across its infrastructure. ### Source excerpt We're Fly.io, a public cloud that runs apps in a bunch of locations all over the world. This is a post about a gnarly bug in our Anycast router, the largest Rust project in our codebase. You won't need much of any Rust to follow it. The basic idea is simple: customers give us Docker containers, and tell us which one of 30+ regions around the world they want them to run in. We convert the containers into lightweight virtual machines, and then link them to an Anycast network. If you boot up an app here in Sydney and Frankfurt, and a request for it lands in Narita, it'll get routed to Sydney. The component doing that work is called fly-proxy. It's a Rust program, and it has been ill behaved of late. Dramatis Personae fly-proxy, our intrepid Anycast router. corrosion, our intrepid Anycast routing protocol. Rust, a programming language you probably don't use. read-write locks, a synchronization primitive that allows for many readers or one single writer. parking_lot, a well-regarded optimized implementation of locks in Rust. Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing Mathewson 6:31 Anycast Routing You already know how to build a proxy. Connection comes in, connection goes out, copy back and forth. So for the amount of time we spend writing about fly-proxy, you might wonder what the big deal is. To be fair, in the nuts and bolts of actually proxying requests, fly-proxy does some interesting stuff. For one thing, it's written in Rust, which is apparently a big deal all on its own. It's a large, asynchronous codebase that handles multiple protocols, TLS termination, and certificate issuance. It exercises a lot of Tokio features. But none of this is the hard part of fly-proxy. We operate thousands of servers around the world. A customer Fly Machine might get scheduled onto any of them; in some places, the expectation we set with customers is that their Machines will potentially start in l ## Launching MCP Servers on Fly.io DevFeed: [Launching MCP Servers on Fly.io]() Original publisher: [Read original article]() Published: 2025-05-19T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [Model Context Protocol](), [MCP Server](), [fly.io](), [OAuth](), [Security](), [Slack]() Tags: [cdn](), [close-to-users](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [json](), [linux](), [macos](), [mcp](), [mcp-server](), [model-context-protocol](), [networking](), [oauth](), [postgresql-clusters](), [servers](), [slack](), [windows]() ### AI overview This opinionated blog post introduces Fly.io's approach to launching MCP Servers. It explains the trade-offs between local process-based servers and remote HTTP servers, including configuration complexity and OAuth 2.1 security requirements, then demonstrates a Slack MCP Server for interacting with Slack workspaces. ### Source excerpt This is a blog post. Part showing off. Part opinion. Plan accordingly. The Model Context Protocol is days away from turning six months old. You read that right, six months old. MCP Servers have both taken the world by storm, and still trying to figure out what they want to be when they grow up. There is no doubt that MCP servers are useful. But their appeal goes beyond that. They are also simple and universal. What's not to like? Well, for starters, there's basically two types of MCP servers. One small and nimble that runs as a process on your machine. And one that is a HTTP server that runs presumably elsewhere and is standardizing on OAuth 2.1. And there is a third type, but it is deprecated. Next there is the configuration. Asking users to manually edit JSON seems so early 21th century. With Claude, this goes into ~/Library/Application Support/Claude/claude_desktop_config.json, and is found under a MCPServer key. With Zed, this file is in ~/.config/zed/settings.json and is found under a context_servers key. And some tools put these files in a different place depending on whether you are running on MacOS, Linux, or Windows. Finally, there is security. An MCP server running on your machine literally has access to everything you do. Running remote solves this problem, but did I mention OAuth 2.1? Not exactly something one sets up for casual use. None of these issues are fatal - something that is obvious by the fact that MCP servers are quite popular. But can we do better? I think so. Demo time. Let's try out the Slack MCP Server: MCP Server for the Slack API, enabling Claude to interact with Slack workspaces. That certainly sounds like a good test case. There is a small amount of setup you need to do, and when you are done you end up with a Bot User OAuth Token staring with xoxb- and a Team ID starting with a T. You would run it using the following: Wrap text Copy to clipboard npx -y @modelcontextprotocol/server-slack But instead, you convert that command to JSON an ## Provisioning Machines using MCPs DevFeed: [Provisioning Machines using MCPs]() Original publisher: [Read original article]() Published: 2025-05-07T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [Provisioning](), [Model Context Protocol](), [fly.io](), [fly](), [Claude](), [cursor](), [GitHub]() Tags: [api](), [cdn](), [claude](), [close-to-users](), [copilot](), [cursor](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [github](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [mcps](), [networking](), [postgresql-clusters](), [provisioning](), [servers](), [terraform]() ### AI overview The author describes using MCP with Claude to create and manage Fly.io volumes, including deleting an unattached volume. The article argues that connecting LLMs to infrastructure tools can make application resource management more intuitive than using APIs, CLIs, or dashboards. ### Source excerpt Today's state of the art is K8S, Terraform, web based UIs, and CLIs. Those days are numbered. On Monday, I created my first fly volume using an MCP. For those who don't know what MCPs are, they are how you attach tools to LLMs like Claude or Cursor. I added support for fly volume create to fly mcp server, and it worked the first time. A few hours later, and with the assistance of GitHub Copilot, i added support for all fly volumes commands. This movie summary is from When Worlds Collide, by Nalaka Gunawardene I'm reminded of the memorable scene in the film Star Trek IV: The Voyage Home (1986). Chief Engineer Scotty, having time-travelled 200 years back to late 20th century San Francisco with his crew mates, encounters an early Personal Computer (PC). Sitting in front of it, he addresses the machine affably as "Computer!" Nothing happens. Scotty repeats himself; still no response. He doesn't realise that voice recognition capability hadn't arrived yet. Exasperated, he picks up the mouse and speaks into it: "Hello, computer?" The computer's owner offers helpful advice: "Just use the keyboard." Scotty looks astonished. "A keyboard?" he asks, and adds in a sarcastic tone: "How quaint!" A while later, I asked for a list of volumes for an existing app, and Claude noted that I had a few volumes that weren't attached to any machines. So I asked it to delete the oldest unattached volume, and it did so. Then it occurred to me to do it again; this time I captured the screen: A few notes: I could have written a program using the machines API, but that would have required some effort. I could have used flyctl directly, but to be honest, I would have had to use the documentation and a bit of copy/pasting of arguments. I could have navigated to a list of volumes for this application in the Fly.io dashboard, but there currently isn't any way to sort the list or delete a volume. Had those been in place, that would have been a reasonable alternative if that was something I was active ## Our Best Customers Are Now Robots DevFeed: [Our Best Customers Are Now Robots]() Original publisher: [Read original article]() Published: 2025-04-08T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [Vibe coding](), [Cloud](), [Docker](), [Containers](), [Command-line interface](), [Developer experience](), [Code]() Tags: [cdn](), [cli](), [close-to-users](), [cloud](), [code](), [containers](), [deploy-app-servers](), [developer-experience](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [postgresql-clusters](), [servers](), [vibe-coding]() ### AI overview Fly.io argues that AI-driven "robots" and vibe coding are becoming major sources of platform growth, potentially making traditional developer experience less decisive. The article describes Fly.io's cloud as a service that turns Docker containers into hardware-isolated virtual machines and emphasizes its CLI-first workflow for containerizing and deploying applications. ### Source excerpt We're Fly.io, a developer-focused public cloud. We turn Docker containers into hardware-isolated virtual machines running on our own metal around the world. We spent years coming up with a developer experience we were proud of. But now the robots are taking over, and they don't care. It's weird to say this out loud! For years, one of our calling cards was "developer experience". We made a decision, early on, to be a CLI-first company, and put a lot effort into making that CLI seamless. For a good chunk of our users, it really is the case that you can just flyctl launch from a git checkout and have an app containerized and deployed on the Internet. We haven't always nailed these details, but we've really sweated them. But a funny thing has happened over the last 6 months or so. If you look at the numbers, DX might not matter that much. That's because the users driving the most growth on the platform aren't people at all. They're... robots. What The Fuck Is Happening? Here's how we understand what we're seeing. You start by asking, "what do the robots want?" Yesterday's robots had diverse interests. Alcohol. The occasional fiddle contest. A purpose greater than passing butter. The elimination of all life on Earth and the harvesting of its cellular iron for the construction of 800 trillion paperclips. No one cloud platform could serve them all. [*] We didn't make up this term. Don't blame us. Today's robots are different. No longer masses of wire, plates, and transistors, modern robots are comprised of thousands of stacked matrices knit together with some simple equations. All these robots want are vectors. Vectors, and a place to burp out more vectors. When those vectors can be interpreted as source code, we call this process "vibe coding"[*]. We seem to be coated in some kind of vibe coder attractant. I want to talk about what that might be. If you want smart people to read a long post, just about the worst thing you can do is to sound self-promotional. But a lot of th ## Do It Yourself Database CDN with Embedded Replicas DevFeed: [Do It Yourself Database CDN with Embedded Replicas]() Original publisher: [Read original article]() Author: Jamie Barton Published: 2025-02-12T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Embedded Replicas](), [Turso](), [Databases](), [fly.io](), [Replication]() Tags: [database](), [embedded-replicas](), [fly-io](), [replication](), [turso]() ### AI overview The article is titled "Do It Yourself Database CDN with Embedded Replicas" and concerns deploying Turso Edge Replicas with Embedded Replicas and Fly.io. The supplied text also notes that the post references an older version of Turso. ### Source excerpt Deploy your own Turso Edge Replicas with Embedded Replicas and Fly.io ## A Blog, If You Can Keep It DevFeed: [A Blog, If You Can Keep It]() Original publisher: [Read original article]() Published: 2025-02-10T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [Publishing](), [Code]() Tags: [blog](), [cdn](), [close-to-users](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [go](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [postgresql-clusters](), [servers](), [technical](), [writing]() ### AI overview A Fly.io team member reflects on the company's use of long-form technical EffortPosts to reach Hacker News audiences. The article argues that strict editorial processes, perfectionism, and concern about exhausting the audience have slowed publication, and describes a shift toward publishing more freely. ### Source excerpt A boldfaced lede like this was a sure sign you were reading a carefully choreographed EffortPost from our team at Fly.io. We're going to do less of those. Or the same amount but more of a different kind of post. Either way: launch an app on Fly.io today! Over the last 5 years, we've done pretty well for ourselves writing content for Hacker News. And that's mostly been good for us. We don't do conventional marketing, we don't have a sales team, the rest of social media is atomized over 5 different sites. Writing pieces that HN takes seriously has been our primary outreach tool. There's a recipe (probably several, but I know this one works) for charting a post on HN: Write an EffortPost, which is to say a dense technical piece over 2000 words long; within that rubric there's a bunch of things that are catnip to HN, including runnable code, research surveys, and explainers. (There are also cat-repellants you learn to steer clear of.) Assiduously avoid promotion. You have to write for the audience. We get away with sporadically including a call-to-action block in our posts, but otherwise: the post should make sense even if an unrelated company posted it after you went out of business. Pick topics HN is interested in (it helps if all your topics are au courant for HN, and we've been very lucky in that regard). Like 5-6 more style-guide things that help incrementally. Probably 3 different teams writing for HN will have 3 different style guides with only like ½ overlap. Ours, for instances, instructs writers to swear. I like this kind of writing. It's not even a chore. But it's become an impediment for us, for a couple reasons: the team serializes behind an "editorial" function here, which keeps us from publishing everything we want; worse, caring so much about our track record leaves us noodling on posts interminably (the poor Tigrises have been waiting for months for me to publish the piece I wrote about them and FoundationDB; take heart, this post today means that one i ## Deploying applications to Fly.io without Docker DevFeed: [Deploying applications to Fly.io without Docker]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2024-10-05T06:30:00Z Content type: tutorial Language: en Sources: [Posts on Harsh Shandilya]() Topics: [fly.io](), [fly](), [Skopeo](), [Docker Image](), [docker registry](), [Nix](), [Command-line interface](), [Deployment]() Tags: [cli](), [deployment](), [docker](), [docker-image](), [docker-registry](), [fly](), [fly-io](), [nix](), [oci-registry](), [skopeo]() ### AI overview A guide to deploying applications on Fly.io without installing Docker locally. It explains how to use Nix to build an OCI image and Skopeo to copy the image archive to Fly.io's registry before deployment. ### Source excerpt A quick guide to deploying apps to Fly.io without a local Docker installation ## AI GPU Clusters, From Your Laptop, With Livebook DevFeed: [AI GPU Clusters, From Your Laptop, With Livebook]() Original publisher: [Read original article]() Published: 2024-09-24T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [Elixir](), [fly.io](), [jupyter](), [Cloud](), [Machine learning](), [Serverless](), [GPU](), [PyTorch]() Tags: [access-control](), [ai](), [ai-and-ml](), [cdn](), [close-to-users](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [gpu](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [infrastructure](), [jupyter](), [networking](), [postgresql-clusters](), [serverless](), [servers]() ### AI overview This recap introduces Livebook, FLAME, and the Nx stack as Elixir components for interactive notebooks, elastic code execution, and Elixir-native AI and machine learning. It describes moving computation between a laptop and remote Fly.io infrastructure, including GPU-backed workloads, and discusses private network access to other applications such as databases. ### Source excerpt Livebook, FLAME, and the Nx stack: three Elixir components that are easy to describe, more powerful than they look, and intricately threaded into the Elixir ecosystem. A few weeks ago, Chris McCord (👋) and Chris Grainger showed them off at ElixirConf 2024. We thought the talk was worth a recap. Let's begin by introducing our cast of characters. Livebook is usually described as Elixir's answer to Jupyter Notebooks. And that's a good way to think about it. But Livebook takes full advantage of the Elixir platform, which makes it sneakily powerful. By linking up directly with Elixir app clusters, Livebook can switch easily between driving compute locally or on remote servers, and makes it easy to bring in any kind of data into reproducible workflows. FLAME is the Elixir's answer to serverless computing. By having the library manage a pool of executors for you, FLAME lets you treat your entire application as if it was elastic and scale-to-zero. You configure FLAME with some basic information about where to run code and how many instances it's allowed to run with, and then mark off any arbitrary section of code with Flame.call. The framework takes care of the rest. It's the upside of serverless without committing yourself to blowing your app apart into tiny, intricately connected pieces. The Nx stack is how you do Elixir-native AI and ML. Nx gives you an Elixir-native notion of tensor computations with GPU backends. Axon builds a common interface for ML models on top of it. Bumblebee makes those models available to any Elixir app that wants to download them, from just a couple lines of code. Here is quick video showing how to transfer a local tensor to a remote GPU, using Livebook, FLAME, and Nx: Let's dive into the keynote. Poking a hole in your infrastructure Any Livebook, including the one running on your laptop, can start a runtime running on a Fly Machine, in Fly.io's public cloud. That Elixir machine will (by default) live in your default Fly.io organization, giving ## Mozilla Llamafile in Supabase Edge Functions DevFeed: [Mozilla Llamafile in Supabase Edge Functions]() Original publisher: [Read original article]() Author: Thor Schaeff Published: 2024-08-21T07:00:00Z Content type: tutorial Language: en Sources: [Supabase Blog]() Topics: [llamafile](), [Supabase](), [AI Inference](), [API](), [Large Language Model](), [Command-line interface](), [Docker](), [OpenAI](), [fly.io](), [Open Source]() Tags: [ai-inference](), [api](), [cli](), [docker](), [fly-io](), [llamafile](), [llms](), [open-source](), [openai](), [vs-code]() ### AI overview This tutorial explains how to run Mozilla Llamafile as an OpenAI API-compatible inference server with Supabase Edge Functions. It covers calling Llamafile through the functions-js interface or the OpenAI Deno SDK, serving functions locally with the Supabase CLI and Docker, and deploying Llamafile and Supabase Edge Functions. ### Source excerpt Use Mozilla Llamafile OpenAI API compatible server in Supabase Edge Functions. ## Accident Forgiveness DevFeed: [Accident Forgiveness]() Original publisher: [Read original article]() Published: 2024-08-21T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [Cloud](), [hosting](), [configuration](), [CI/CD](), [networking]() Tags: [cdn](), [ci-cd](), [close-to-users](), [cloud](), [configuration](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [postgresql-clusters](), [servers]() ### AI overview Fly.io discusses the financial anxiety of elastic public-cloud resources, where configuration mistakes, unintended virtual machines, or leaked CI/CD environments can produce unexpectedly large bills. The article argues that cloud providers often have billing-support processes that may forgive disputed charges, while suggesting that cloud billing still needs improvement. ### Source excerpt We're Fly.io, a new public cloud with simple, developer-friendly ergonomics. Try it out; you'll be deployed in just minutes, and, as you're about to read, with less financial risk. Public cloud billing is terrifying. The premise of a public cloud -- what sets it apart from a hosting provider -- is 8,760 hours/year of on-tap deployable compute, storage, and networking. Cloud resources are "elastic": they're acquired and released as needed; in the "cloud-iest" apps, without human intervention. Public cloud resources behave like utilities, and that's how they're priced. You probably can't tell me how much electricity your home is using right now, and may only come within tens of dollars of accurately predicting your water bill. But neither of those bills are all that scary, because you assume there's a limit to how much you could run them up in a single billing interval. That's not true of public clouds. There are only so many ways to "spend" water at your home, but there are indeterminably many ways to land on a code path that grabs another VM, or to miskey a configuration, or to leak long-running CI/CD environments every time a PR gets merged. Pick a practitioner at random, and I bet they've read a story within the last couple months about someone running up a galactic-scale bill at some provider or other. Implied Accident Forgiveness For people who don't do a lot of cloud work, what all this means is that every PR push sets off a little alarm in the back of their heads: "you may have just incurred $200,000 of costs!". The alarm is quickly silenced, though it's still subtly extracting a cortisol penalty. But by deadening the nerves that sense the danger of unexpected charges, those people are nudged closer to themselves being the next story on Twitter about an accidental $200,000 bill. The saving grace here, which you'll learn if you ever become that $200,000 story, is that nobody pays those bills. See, what cloud-savvy people know already is that providers have billin ## We're Cutting L40S Prices In Half DevFeed: [We're Cutting L40S Prices In Half]() Original publisher: [Read original article]() Published: 2024-08-15T00:00:00Z Content type: news Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [GPU](), [fly](), [Inference](), [Cloud](), [Artificial Intelligence](), [Generative AI](), [NeMo](), [Nvidia](), [stable-diffusion](), [NVLink]() Tags: [ai](), [cdn](), [close-to-users](), [cloud](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [generative-ai](), [gpu](), [hardware](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [inference](), [nemo](), [networking](), [nvidia](), [nvlink](), [postgresql-clusters](), [servers](), [stable-diffusion]() ### AI overview Fly.io announces that it has cut the price of NVIDIA L40S GPUs to $1.25 per hour. The article explains that customers most often choose the less powerful A10 for inference and mid-sized generative AI workloads such as Mistral Nemo and Stable Diffusion, while Fly.io's earlier GPU strategy focused on more demanding ideas involving A100 partitioning, NVLink clusters, and training. ### Source excerpt We're Fly.io, a new public cloud with simple, developer-friendly ergonomics. And as of today, cheaper GPUs. Try it out; you'll be deployed in just minutes. We just lowered the prices on NVIDIA L40s GPUs to $1.25 per hour. Why? Because our feet are cold and we burn processor cycles for heat. But also other reasons. Let's back up. We offer 4 different NVIDIA GPU models; in increasing order of performance, they're the A10, the L40S, the 40G PCI A100, and the 80G SXM A100. Guess which one is most popular. We guessed wrong, and spent a lot of time working out how to maximize the amount of GPU power we could deliver to a single Fly Machine. Users surprised us. By a wide margin, the most popular GPU in our inventory is the A10. The A10 is an older generation of NVIDIA GPU with fewer, slower cores and less memory. It's the least capable GPU we offer. But that doesn't matter, because it's capable enough. It's solid for random inference tasks, and handles mid-sized generative AI stuff like Mistral Nemo or Stable Diffusion. For those workloads, there's not that much benefit in getting a beefier GPU. As a result, we can't get new A10s in fast enough for our users. If there's one thing we've learned by talking to our customers over the last 4 years, it's that y'all love a peek behind the curtain. So we're going to let you in on a little secret about how a hardware provider like Fly.io formulates GPU strategy: none of us know what the hell we're doing. If you had asked us in 2023 what the biggest GPU problem we could solve was, we'd have said "selling fractional A100 slices". We burned a whole quarter trying to get MIG, or at least vGPUs, working through IOMMU PCI passthrough on Fly Machines, in a project so cursed that Thomas has forsworn ever programming again. Then we went to market selling whole A100s, and for several more months it looked like the biggest problem we needed to solve was finding a secure way to expose NVLink-ganged A100 clusters to VMs so users could run train ## JIT WireGuard DevFeed: [JIT WireGuard]() Original publisher: [Read original article]() Published: 2024-03-12T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [API](), [Command-line interface](), [Firecracker](), [GraphQL](), [Networks](), [Remote Procedure Call (RPC)](), [Messaging](), [Server](), [Kernel](), [SQLite](), [Containers]() Tags: [api](), [cdn](), [cli](), [close-to-users](), [containers](), [deploy-app-servers](), [docker](), [elixir](), [firecracker](), [fly](), [fly-io](), [graphql](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [kernel](), [messaging](), [networking](), [networks](), [postgresql-clusters](), [rpc](), [servers](), [sqlite]() ### AI overview Fly.io describes improvements to its WireGuard gateway architecture for greater speed and scalability. The article explains how flyctl creates a networking stack, obtains peer configurations through a GraphQL API, distributes them to regional gateways through RPC over NATS, and installs them using SQLite and WireGuard libraries. ### Source excerpt We're Fly.io and we transmute containers into VMs, running them on our hardware around the world with the power of Firecracker alchemy. We do a lot of stuff with WireGuard, which has become a part of our customer API. This is a quick story about some tricks we played to make WireGuard faster and more scalable for the hundreds of thousands of people who now use it here. One of many odd decisions we've made at Fly.io is how we use WireGuard. It's not just that we use it in many places where other shops would use HTTPS and REST APIs. We've gone a step beyond that: every time you run flyctl, our lovable, sprawling CLI, it conjures a TCP/IP stack out of thin air, with its own IPv6 address, and speaks directly to Fly Machines running on our networks. There are plusses and minuses to this approach, which we talked about in a blog post a couple years back. Some things, like remote-operated Docker builders, get easier to express (a Fly Machine, as far as flyctl is concerned, might as well be on the same LAN). But everything generally gets trickier to keep running reliably. It was a decision. We own it. Anyways, we've made some improvements recently, and I'd like to talk about them. Where we left off Until a few weeks ago, our gateways ran on a pretty simple system. We operate dozens of "gateway" servers around the world, whose sole purpose is to accept incoming WireGuard connections and connect them to the appropriate private networks. Any time you run flyctl and it needs to talk to a Fly Machine (to build a container, pop an SSH console, copy files, or proxy to a service you're running), it spawns or connects to a background agent process. The first time it runs, the agent generates a new WireGuard peer configuration from our GraphQL API. WireGuard peer configurations are very simple: just a public key and an address to connect to. Our API in turn takes that peer configuration and sends it to the appropriate gateway (say, ord, if you're near Chicago) via an RPC we send over ## Fly Kubernetes does more now DevFeed: [Fly Kubernetes does more now]() Original publisher: [Read original article]() Published: 2024-03-07T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [Kubernetes](), [fly.io](), [Firecracker](), [k3s](), [Containers](), [networking](), [API](), [Prometheus]() Tags: [2](), [api](), [cdn](), [close-to-users](), [complexity](), [containers](), [deploy-app-servers](), [docker](), [elixir](), [firecracker](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [k3s](), [kubernetes](), [networking](), [postgresql-clusters](), [prometheus](), [servers]() ### AI overview Fly Kubernetes has moved from early access toward a closed beta as a managed Kubernetes service backed by Fly.io infrastructure. It handles Kubernetes control-plane operations while users deploy workloads. The article explains that Fly's design uses K3s and Virtual Kubelet, transforms containers into Firecracker microVMs, and connects pods through an internal WireGuard mesh. ### Source excerpt Eons ago, we announced we were working on Fly Kubernetes. It drummed up enough excitement to prove we were heading in the right direction. So, we got hard to work to get from barebones "early access" to a beta release. We'll be onboarding customers to the closed beta over the next few weeks. Email us at sales@fly.io and we'll hook you up. Fly Kubernetes is the "blessed path"™ to using Kubernetes backed by Fly.io infrastructure. Or, in simpler terms, it is our managed Kubernetes service. We take care of the complexity of operating the Kubernetes control plane, leaving you with the unfettered joy of deploying your Kubernetes workloads. If you love Fly.io and K8s, this product is for you. What even is a Kubernete? So how did this all come to be--and what even is a Kubernete? You can see more fun details in Introducing Fly Kubernetes. If you wade through all the YAML and CNCF projects, what's left is an API for declaring workloads and how it should be accessed. But that's not what people usually talk / groan about. It's everything else that comes along with adopting Kubernetes: a container runtime (CRI), networking between workloads (CNI) which leads to DNS (CoreDNS). Then you layer on Prometheus for metrics and whatever the logging daemon du jour is at the time. Now you get to debate which Ingress--strike that--Gateway API to deploy and if the next thing is anything to do with a Service Mess, then as they like to say where I live, "bless your heart". Finally, there's capacity planning. You've got to pick and choose where, how and what the Nodes will look like in order to configure and run the workloads. When we began thinking about what a Fly Kubernetes Service could look like, we started from first principles, as we do with most everything here. The best way we can describe it is the scene from Iron Man 2 when Tony Stark discovers a new element. As he's looking at the knowledge left behind by those that came before, he starts to imagine something entirely different and ## NoSQL Postgres: Add MongoDB compatibility to your Supabase projects with FerretDB DevFeed: [NoSQL Postgres: Add MongoDB compatibility to your Supabase projects with FerretDB]() Original publisher: [Read original article]() Author: Thor Schaeff Published: 2024-01-31T07:00:00Z Content type: tutorial Language: en Sources: [Supabase Blog]() Topics: [MongoDB](), [Supabase](), [NoSQL](), [Docker](), [fly.io](), [Node.js]() Tags: [docker](), [fly-io](), [mongodb](), [node-js](), [nosql](), [postgres]() ### AI overview This tutorial explains how to use FerretDB to add MongoDB compatibility to Postgres-backed Supabase projects. It covers running FerretDB locally with Docker, connecting with MongoDB tools and the Node.js client, performing basic document operations, and deploying FerretDB to Fly.io. ### Source excerpt NoSQL Postgres: Add MongoDB compatibility to your Supabase projects with FerretDB ## Fly Postgres, managed by Supabase DevFeed: [Fly Postgres, managed by Supabase]() Original publisher: [Read original article]() Author: Inian Parameshwaran; Paul Copplestone Published: 2023-12-15T07:00:00Z Content type: release Language: en Sources: [Supabase Blog]() Topics: [Databases](), [fly](), [fly.io](), [Supabase](), [Latency](), [Firecracker](), [API](), [GraphQL](), [observability](), [Replication]() Tags: [api](), [edge-computing](), [firecracker](), [fly](), [fly-io](), [graphql](), [latency](), [observability](), [postgres](), [recovery](), [release](), [replication](), [testing]() ### AI overview Supabase and Fly.io are launching Fly Postgres, a managed Postgres service deployed across Fly.io's edge locations. It includes extensions, pgvector support, connection pooling, backups, point-in-time recovery, branching, observability, migrations, a dashboard, and automatically generated REST and GraphQL APIs. The service is being progressively rolled out to testers. ### Source excerpt A managed Postgres offering developed by Supabase and Fly.io ## How to run Remark42 on Fly.io DevFeed: [How to run Remark42 on Fly.io]() Original publisher: [Read original article]() Author: andreacorbellini Published: 2023-09-19T02:12:00Z Content type: tutorial Language: en Sources: [Andrea Corbellini]() Topics: [fly.io](), [fly](), [cloud-infrastructure](), [Containers](), [Command-line interface](), [backups]() Tags: [backups](), [blog](), [cloud](), [command-line](), [containers](), [fly-io](), [how-to](), [storage]() ### AI overview A tutorial explaining how to set up Remark42 comments on Fly.io. It describes a single-machine, single-volume deployment, notes that Remark42 stores comments in one file without distributed replication, and recommends periodic backups because of the risk of permanent data loss. ### Source excerpt As I wrote on my previous post, I recently switched from Disqus to Remark42 for the comments on my blog. Here I will explain how I set it up on Fly.io. Overview The setup that I ended up with looks like the following: Something to note about this setup is that the "machine" (more on that later) and the storage volume are both ... ## Fly.io makes infrastructure easy for developers DevFeed: [Fly.io makes infrastructure easy for developers]() Original publisher: [Read original article]() Author: Pekka Enberg Published: 2022-09-22T00:00:00Z Content type: opinion Language: en Sources: [Turso Blog]() Topics: [fly.io](), [fly](), [cloud-infrastructure](), [Amazon EKS](), [Turso](), [libSQL]() Tags: [backend-development](), [chiselstrike](), [cloud](), [developers](), [fly](), [fly-io](), [infrastructure](), [infrastructure-as-code](), [libsql](), [turso]() ### AI overview The article presents Fly.io as a developer-friendly way to simplify infrastructure and application deployment, contrasting it with the complexity of EBS volumes and EKS storage classes. It also notes that the referenced Turso material is outdated and describes newer Turso capabilities and SDKs. ### Source excerpt Fly.io feels like it's going to make infrastructure easy for developers. No more fighting with EBS volumes or EKS storage classes to get your app deployed.