Code and Let Live(fly.io)
73 pointsby usrmea day ago15 comments
  • simonwa day ago
    I'm really excited about https://sprites.dev/ - it hits two of my favourite problems at once:

    1. Developer environment sandboxes. This is a cheap and convenient way to run Claude Code / Codex CLI / etc in YOLO mode in a persistent sandboxed VM with a restricted blast radius if something goes wrong.

    2. Sandbox API. Fly now have a product that lets me make a simple JSON API call to run untrusted code in a new sandbox. There's even snapshotting support so I can roll back to a known state after running that code.

    I wrote more a bunch more about this here: https://simonwillison.net/2026/Jan/9/sprites-dev/

    • realty_geek6 hours ago
      I have found container-use to be super useful for this.

      https://container-use.com/quickstart

      BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more. I'm super appreciative of your work and I'm pretty convinced that the more you profit from it, the better the universe will be!!!

  • psanford2 hours ago
    Playing around with this for a small amount of time, it is very neat but also there are a bunch of things that are unclear / undocumented (I assume the documentation is coming so I'm not faulting them for it not being there yet).

    Some things that are unclear:

    - How should I auth to github? sprite console doesn't use ssh (afaik) so I guess not agent forwarding?

    - What on machine api's are available? Can I use the fly oidc provider[1]? There's a /.sprite/api.sock but curl'ing /v1/tokens/oidc gets a 404.

    - How much is it going to cost me? I know there is pricing but its hard to figure out what actual usage would be like. Also I don't see any usage info in the webui right now.

    [1]: https://fly.io/blog/oidc-cloud-roles/

    • fideloper30 minutes ago
      i believe the .sprite dir has some stuff to help claude answer those questions. haven’t done it myself but my friend said he was able to get claude to set it all up for him (yolo mode helps) including connecting to github.
    • psanford2 hours ago
      To follow up on this a bit, something that I really want is a way to build and launch apps from an llm really easily. I am imagining and environment with a database, object storage, and a publicly reachable webserver. I think this could be that with OIDC auth to an s3 bucket and litestream.

      I was previously thinking about doing the same thing on my homeserver with tailscale to expose the web interface publicly and tailscale oidc auth to an s3 bucket for object storage.

  • qhwudbebd14 hours ago
    AFAIK fly.io run firecracker and cloud-hypervisor VMs. This seems to have a copy-on-write filesystem underneath.

    Given their principled take on only trusting full-VM boundaries, I doubt they moved any of the storage stack into the untrusted VM.

    So maybe a virtio-block device passing through discard to some underlying CoW storage stack, or maybe virtio-fs if it's running on ch instead of fc? Would be interesting to hear more about the underlying design choices and trade-offs.

    Edit: from their website, "Since it's just ext4, you won't run into weird edge cases like you might with NFS or FUSE mounts. You can happily use shared memory files, for example, so you can run SQLite in all its modes." So it's a virtio block device supporting discard that's exposed to the VM. Interesting; fc doesn't support virtio discard passthrough, and support for ch is still in progress...

    • tptacek6 hours ago
      I have a post coming next week about the guts of this thing, but I'm curious why you think we'd avoid running the storage stack inside the VM. From my perspective that's safer than running it outside the VM.
  • dtkav16 hours ago
    fly.io is doing really good work. I've super enjoyed building our product on their platform. I love fly-replay combined with super fast start-up.

    I've been thinking a lot about how to run agents (and skills) securely while giving them a lot of powerful capabilities.

    I recently used their macaroons library to turn arbitrary API keys (e.g. for stripe's API) into macaroons. I route requests for an upstream host (like stripe) through Envoy as a mitm proxy which injects the real creds after verifying the macaroon.

    It is such a powerful pattern. I'm always worried about leaking sensitive keys through prompt injection attacks (or just sending them to anthropic), but in this model you can attenuate the keys (both capabilities & validity window) client side. The Envoy proxy lives inside my flycast network so it can't be accessed externally.

    It would be so cool if fly built something like this into sprites.dev (though I can see how it would be spooky to have fly install their own certs for stripe, etc...)

    • tptacek16 hours ago
      If you read Ben Toews work on the tokenizer you have a good sense of where I want Sprites to go with key leaks and prompt injection:

      https://fly.io/blog/tokenized-tokens/

      • dtkav15 hours ago
        Awesome stuff! Thanks for the reply.

        Tokenizer is an explicit proxy though right?

        My use case is very similar, but I wanted a transparent proxy so I could run unmodified scripts. It is a tricky design decision though.

        I also mount a little fuse filesystem that mints macaroon on read (with a shorter lifetime, probably inspired by y'all but i forget from where).

        I work on realtime collaboration of markdown files (currently in Obsidian), which has become a shared-context substrate for agents, skills, etc.. Our own company workspace has skills that have scoped access to fly, stripe, gmail, etc. We're definitely drinking the file-over-app personal-software-for-teams Kool-Aid, so the problem space for us includes access control and auditing.

        Love your work :)

        • tptacek3 hours ago
          We have enough control over the execution environment in a Sprite (unlike a Fly Machine, where the implied Linux contract we have with our users gets in the way) that we can trivially hide explicit proxies.

          We can also attach Macaroons to Fly Machines and Sprites for configurable ambient privileges, something I've wanted us to expose as a feature for a very long time.

          • dtkav3 minutes ago
            Awesome, i look forward to that. I think that could be a major differentiator for sprites. I wish i could work on that problem at fly.io scale.

            What is the contract with sprites? Is it just built-with-linux but not promising Linux? Or is it more like a machine but y'all control the container image?

            • tptacek2 minutes ago
              There's no "formal" contract in either place but people running on Fly Machines expect that there's nothing at all between them and the kernel, and we don't have that expectation in Sprites; we can do whatever we want. :)

              I don't want to get too far into the rest of the details only because I'm writing this up for next week. They're not that interesting technically, but they're a really big deal for us in other ways.

  • mwcampbell13 hours ago
    I want something like this, but running on my own box. I now have a Linux box with plenty of RAM and storage under my desk. (It happens to be an NVIDIA DGX Spark, but I'm not really interested in passing the GPU through to these sandboxed VMs; I know that's not practical anyway.) Maybe I'll see if I can hack together a local solution like this using Firecracker.
    • tptacek6 hours ago
      That's coming. It's what Jerome has been working on these past few months.
    • indigodaddy10 hours ago
      Maybe bend smolvm to your needs?
  • sheepscreek7 hours ago
    > Claude is a hyper-productive five-year-old savant. It’s uncannily smart, wants to stick its finger in every available electrical socket, and works best when you find a way to let it zap itself.

    This alone was worth the upvote!

  • jmoglya day ago
    Like it, a lot. I think the future of software is going to be unimaginably dynamic. Maybe apps will not have statically defined feature sets, they will adjust themselves around what the user wants and the data it has access to. I’m not entirely sure what that looks like yet, but things like this are a step in that direction.
    • dmuxa day ago
      > I think the future of software is going to be unimaginably dynamic.

      >...I’m not entirely sure what that looks like yet, but things like this are a step in that direction.

      This made me stop and think for a moment as to what this would look like as well. I'm having trouble finding it, but I think there was a post by Joe Armstrong (of Erlang) that talked about globally (as in across system boundaries, not global as in global variable) addressable functions?

  • psanford6 hours ago
    What is the criteria for a sprite being "idle"? Is it no network activity or is it cpu based?
  • CGamesPlay8 hours ago
    I spun one up, started a server on port 8080, ran `sprite url`, it gave me a URL, that URL just has `{ "error": "unauthorized" }`. How am I supposed to access it?
    • mrkurt7 hours ago
      sprite url update --auth public

      It requires your api token by default.

      • indigodaddy3 hours ago
        Do we handle our own certs or do you have a proxy in front of the sprites that can do auto ssl stuff?
        • tptacek3 hours ago
          We handle all the SSL stuff. Sprites run on the same Anycast network with the same control plane as Fly Machines, which are built for srs bzns.
      • CGamesPlay7 hours ago
        Oh, thanks, that works. ([edit] rewrote this whole post) I guess I need to install my own tunneling into the VM to do web development on it, but that's not so bad. The lack of regional support is crippling, because whatever region you put me in is ~200ms from me and the typing lag is terrible.

        I'd love to adopt this for all my development (which I currently do using rented cloud instances, so I'm pretty comfortable with the remote development paradigm). I'm especially excited about the snapshot/clone pattern, and have (this past week) been researching solutions for exactly this problem.

        Hope you launch multiple regions for this ASAP. Will be watching.

        • mrkurt5 hours ago
          If you `sprite console` to it, it'll forward any ports you open to localhost. You can tunnel almost everything through the CLI with the `sprite proxy` command.
  • a_lanfranco13 hours ago
    sprites.dev looks very interesting to me. Is there a way to set up a limit to how much scaling a sprite can get, or to set a spending limit? I wouldn't want to spin something up, and then be surprised by an unexpectedly high bill.
  • nextaccountic14 hours ago
    How exactly can code agents make use of this? You install claude code inside a Sprite and run it there? Do you also need to put all your codebase in this sprite?
    • hashim-warren2 hours ago
      You can use git to pull down code from a remote repo
    • tptacek14 hours ago
      Claude Code is already in the Sprite; just create one and type "claude". But they have an API and Claude (or Gemini or Codex) can use them remotely too. They're disposable computers. Use them however you want.
  • memset17 hours ago
    Could you clarify what this actually is?

    Would I think of this as an EC2 instance which automatically and quickly scales to zero, with pricing only for resources consumed? (CPU and RAM when up, and disk all the time?)

    • simonw17 hours ago
      Yeah that's about right.

      It's a fast starting and fast pausing persistent VM, with a ton of built in developer tools (including a preconfigured Claude Code) and an extra JSON API for executing commands within it so you can treat it as a sandbox.

      You may find my writeup here useful: https://simonwillison.net/2026/Jan/9/sprites-dev/

  • skybriana day ago
    This sounds great and it's roughly what exe.dev is doing too. Coincidence?
    • tptaceka day ago
      This has been in the works for quite awhile here. We put a long bet on "slow create fast start/stop" --- which is a really interesting and useful shape for execution environments --- but it didn't make sense to sandboxers, so "fast create" has been the White Whale at Fly.io for over a year.
    • HumanOstrich16 hours ago
      Not really. One of the primary features of sprites.dev that I don't see anywhere on exe.dev is a fast way to create and restore checkpoints, like a git repo for your entire VM.

      This is needed for sandboxes if you don't want to throw them away and start over when something goes wrong.

      With sprites.dev you can create an additional checkpoint and then turn Claude Code (or your preferred agent) loose to do anything. Even if it burns down the sandbox you can just restore a checkpoint in about a second.

      • skybrian9 hours ago
        Yes that’s certainly a great feature and they don’t have it currently. For what it’s worth, they do have a teaser about “Persistent disks with some really interesting work coming soon.”

        https://blog.exe.dev/meet-exe.dev

    • memset17 hours ago
      I have just now learned about exe.dev and it looks awesome.

      I really hate that modern development means not having persistent disk. I’m glad there are new options coming out which let you do this in and easier way than managing my own EC2 instances!

  • jamietanna11 hours ago
    Unsure if it's an intended typo: `rm -rf $HMOE/bin`
    • CGamesPlay8 hours ago
      I ran the command to check and it erased /bin and now my sprite is busted. But I was able to restore from a checkpoint and it's all good.
      • mrkurt5 hours ago
        Intended typo so you can see restore happen ;)
  • indigodaddy19 hours ago
    So this is neat and useful and I think will/should get traction.

    So let's say sprite is my building/dev ground floor. I get my thing/app to where I want it, but at the end of the day I think my thing/app is so awesome that it should be a production app for the whole world, and, I want to actually deploy it on fly, say.

    Have you guys thought about that workflow, and what it might take to push button/migrate a sprite app over to fly?

    Also, any plans for GPU sprites?

    • tptacek16 hours ago
      It depends on which Fly person you talk to. If you talk to Kurt he'll try to sell you on his crazy dream of how all software is going to be malleable and "prod" doesn't mean anything anymore. If you ask me: tell Claude to make a Dockerfile of the current state of your Sprite, and then deploy it as a Fly Machine. It's a good question, and we're working out how the transition from Sprite to Fly Machine works, but that's how I'd do it today.

      I don't think we're going to do anything new with GPUs any time soon.