Claude Code transcript

Feasibility assessment: fly.io provider

Bottom line: technically possible to wire in, but fly.io is a poor fit for what machine does. Roughly half of the CloudProvider interface has no native fly.io equivalent, and the tool's core workflow — boot an OS image, inject SSH keys, run a cloud-init script, point a DNS record at the VM's IP — doesn't map onto fly.io's model.

One premise worth correcting first: fly.io isn't a bare-metal provider. They run their own bare metal, but what they sell is Firecracker microVMs ("Machines") that boot from Docker/OCI container images (e.g. registry-1.docker.io/library/ubuntu:latest), not full OS images. That difference drives most of the friction below.

What maps cleanly

• API mechanics: a simple REST API (POST /v1/apps/{app}/machines, plus get/list/delete/start/stop) with Authorization: Bearer token auth. No SDK needed — plain requests would do, so no new dependency risk for the Python ≥3.8 / shiv build.
• create_vm / get_vm / destroy_vm / list_vms — all have direct endpoints. tags maps to machine metadata, region maps to fly regions, size maps to guest config (cpu_kind, cpus, memory_mb).
• validate_region / validate_image — straightforward.

What breaks

• cloud-init / user_data — not supported at all. Machines boot a container entrypoint, not a cloud-init-enabled OS. The closest emulation is the files config (write files into the machine) plus a custom entrypoint, but that's a different contract than the cloud.init scripts this tool is built around. This is the biggest blocker since cloud-init specification is one of your three stated core features.
• SSH keys — fly.io has no SSH key resource. Access is via fly ssh console over their WireGuard mesh with their own agent (hallpass); to get real sshd with your keys, you'd have to bake sshd and the public key into the container image. get_ssh_key/list_ssh_keys and the ssh_key_names argument to create_vm can't be implemented natively.
• Public IPs — allocated per app, not per machine, and they're anycast addresses (shared IPv4 by default; dedicated IPv4 costs extra and is still app-scoped). Machines themselves only have private 6PN IPv6 addresses. VM.ip_address — which the DNS workflow presumably feeds — has no clean per-VM answer.
• DNS — fly.io offers no DNS hosting or record-management API (only .fly.dev subdomains and certificate management for custom domains). create_dns_record, delete_dns_record, get_dns_records, and list_domains — four of the ten abstract methods — would have to be stubbed out or delegated to another provider.
• App container concept — every machine must live inside a "Fly App" (which is also the unit of IP allocation and internal DNS), so the provider would need an app-management strategy (one app per VM vs. one shared app) that has no analogue in the current abstraction.

Verdict

If the goal is "manage fly.io machines from this CLI," a provider could be written in a day or two using the four VM CRUD methods and stubs elsewhere — similar in spirit to how GCP presumably omits some pieces. But users would get machines they can't cloud-init, can't ssh into with their configured keys, and can't point DNS at a per-machine IP. I'd recommend against adding it unless you're willing to reframe fly.io support as a container-deployment mode rather than a VM provider. If you want a provider with a similar "modern API, runs its own hardware" flavor that does fit the abstraction (real VMs, cloud-init, SSH keys, per-VM IPs), Hetzner Cloud or Linode would slot into the existing interface almost 1:1.

Sources: Machines API index, Machines resource, Networking services

That analogy is half right, and the half that's right is actually the clever part of their architecture — but the "for desktop users" half is off.

Where the analogy works: like WSL2, fly.io gives you something that feels like a container (you ship a Docker image, you get a filesystem and a process) but is actually a lightweight hardware-virtualized VM underneath (Firecracker microVMs in their case, Hyper-V in WSL2's). In both cases the point is container ergonomics with real VM isolation boundaries. So mechanically, yes: "container UX on a hidden microVM" is exactly the trick both play.

Where it breaks down: the audience and purpose. WSL2 is an interactive environment — you get a shell, you develop in it, it's a pet. Fly.io machines are meant to be cattle: you deploy a server application image, their anycast network routes user traffic to whichever region the request lands near, machines auto-stop when idle and cold-start in milliseconds when a request arrives. The whole product is "run your web app close to your users in 30+ regions without doing ops," competing with Heroku's ghost, Render, Railway, and Cloudflare Workers — not with a remote dev box.

That said, people do bend it into the remote-dev-environment shape you're describing (bake sshd into an image and treat it as a disposable cloud workstation), and the per-second billing plus stop-when-idle makes that cheap. It's just not what the product is aimed at — which circles back to yesterday's conclusion: it's an app-deployment platform wearing VM clothing, not a VM provider wearing container clothing, and that's why it fights your tool's abstraction.

Good question — the answer is that fly.io moves the routing job out of DNS entirely and into anycast IP routing plus their edge proxy. DNS becomes a one-time, nearly-static pointer instead of the load-balancing mechanism.

To be precise about what I said earlier: fly.io has no DNS hosting — no API to manage record zones, which is why your tool's create_dns_record methods have nothing to call. Your apps absolutely are reachable by name; it just works differently:

1. Every app gets one anycast IP (plus a free yourapp.fly.dev hostname pointing at it). "Anycast" means that same IP address is BGP-advertised from every fly.io edge location simultaneously. There's nothing to keep updated — the IP never changes no matter where your machines run.

2. The internet does the geo-routing. When a client in Tokyo connects to that IP, BGP naturally delivers the packets to fly's Tokyo edge; a client in Frankfurt hits the Frankfurt edge. This is the same trick CDNs and public DNS resolvers (1.1.1.1, 8.8.8.8) use. No GeoDNS, no per-region hostnames.

3. fly-proxy at the edge does the last hop. The proxy terminates TLS, reads the SNI/Host header to figure out which app the request is for (this is how thousands of apps share one IPv4), then forwards the connection over fly's private WireGuard backbone to the nearest region where you have a machine. If your machines there are stopped, it cold-starts one (sub-second, since Firecracker + a pre-pulled image) and then delivers the request. That proxy-triggered wake-up is the FaaS-like scale-to-zero behavior.

4. Your custom domain is a single static record at whatever DNS provider you already use — an A/AAAA record pointing at the anycast IP, or a CNAME to yourapp.fly.dev. You set it once; fly issues a Let's Encrypt cert for it. That's why they never built DNS hosting: in their architecture DNS carries no operational load worth managing.

Contrast with the model your machine tool automates: there, each VM has its own IP, so DNS records are per-machine state that must be created and destroyed with the VM. On fly.io the machine fleet can scale, move regions, or stop entirely and the public addressing never changes — the proxy layer absorbs all of that churn.

The trade-off is that fly-proxy sits in front of everything, so you're getting HTTP/TLS/TCP-handler routing whether you want it or not. For raw protocols or "I just want a box with an IP," you're back to paying for a dedicated IPv4 per app — and back to the awkward fit we identified for your tool.

Your instinct from two messages ago turns out to be spot-on — Sprites (launched January 2026) is essentially fly.io productizing the "remoted WSL2" use case I said their main platform wasn't aimed at.

It's the same substrate — Firecracker microVMs on their hardware — but the operating model is flipped from the edge-FaaS story:

• Machines/apps model: stateless cattle, image is the source of truth, anycast + fly-proxy routes inbound user traffic, machines are disposable and interchangeable.
• Sprites model: each sandbox is a pet with a name. It keeps its filesystem state — an agent can apt install things, clone a repo, leave logs lying around, and come back days later to exactly where it left off. Cold-start is 1–12 seconds, and instead of scale-to-zero-by-discarding, it checkpoints the whole environment (~300ms) to object storage and restores on demand. So you get persistent-VM semantics while only paying for actual compute time.

The reason it's marketed at AI agents specifically is that agents created a sudden mass market for exactly this shape of thing: you want to let a coding agent run with dangerous permissions ("YOLO mode") or execute untrusted generated code, so you need hard VM-grade isolation — but the agent also needs a durable working environment across sessions, not a fresh stateless container per request. Interactive terminal/SSH-style access matters more than an anycast IP, and per-second billing with instant suspend matters because agents are bursty. Sandboxed + stateful + cheap-when-idle is precisely the gap between "serverless function" and "rented VM," and Simon Willison's writeup notes it doubles as a general untrusted-code-execution API, not just agents.

So the corrected picture of fly.io: one microVM substrate, two products on top — the anycast/proxy edge platform for serving production traffic, and Sprites for isolated, persistent, interactive workspaces. Notably, Sprites is even less of a fit for your machine tool than the Machines API — no public per-VM IP or DNS story at all — but it's a much better fit for the thing your earlier analogy described.

Sources: Sprites.dev, Simon Willison's review, SDxCentral coverage, devclass coverage, fly.io blog

That's exactly the shape of it — "Linux on a rope" is a better tagline than anything in their marketing. A couple of refinements to the provenance story, because it makes the picture even sharper:

The pivot pattern actually runs twice. Fly.io originally started (circa 2017) as an edge proxy/CDN-ish product — run your JavaScript at the edge, in the Cloudflare Workers vein. It didn't take off, and their first big pivot was "what if you could run your whole app at the edge, not just snippets" — which is what drove them to Firecracker microVMs booted from Docker images, since that let arbitrary existing apps run with hard isolation and fast starts. The anycast/fly-proxy edge platform we discussed was pivot one.

Sprites is pivot two, and your read of the mechanism is right: they looked at what they'd already built and realized the crown jewels weren't the part they'd been selling. The edge/anycast routing — the whole original point — is irrelevant to Sprites. What turned out to be valuable was the boring substrate underneath: the ability to conjure a genuinely isolated Linux VM from a container image in about a second, run it densely and cheaply, and bill by the second. For years that was merely plumbing for the FaaS story; then agentic AI showed up and suddenly "instant disposable-but-persistable Linux boxes at scale" was the product, with the malicious-LLM/untrusted-code concern as the demand driver. Kurt Mauer's blog post about the shift is literally titled "Turn and Face the Strange" — they're quite open that this is a repositioning of existing assets toward where the money moved.

The one place I'd amend "small changes": the checkpoint/restore-to-object-storage machinery (~300ms snapshots of a running VM's full state) was real new engineering, not just a repackaging — it's the piece that converts "cheap ephemeral VM" into "persistent pet you only pay for while it's awake." But architecturally, yes: same Firecracker substrate, same image pipeline, same fleet — different customer, different story, and the second story arguably fits what they built better than the first one did.