https://sprites.dev/

I really want to love this, but my experience in the first 20 seconds is unfortunately like some of my other experiences coding against Fly APIs, they're broken.

https://sprites.dev/api has this command:

$ curl -X POST "https://api.sprites.dev/v1/sprites" \ -H "Authorization: Bearer $SPRITES_TOKEN" \ -d '{"name": "my-sprite"}'

which responds with

{"error":"name is required"}

if you use the request body in the full "Create Sprite" documentation at https://sprites.dev/api/sprites#create then it does work.

can I live with some rough edges for some personal workflows that only impact me when things break? sure. however, I was thinking about playing with some CI/CD stuff using sprites that would impact our whole team if things broke and I'm really on the fence because of this experience in the first 20 seconds.

Fly team - please put some black box probes or just better testing on the example you give in the quick start. if you document it, test it.

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/

Does anyone know of similar solutions that can be self-hosted? (without a 12 service stack like Daytona [1])

[1] https://www.daytona.io/docs/en/oss-deployment/

> 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!

This is seriously cool - it's exactly the DX and API I've been waiting for from sandboxed execution providers.

I'd love to be able to configure the base image/VM in a way that doesn't bundle coding tools or anything else I don't need, and comes with some other binaries installed (I'm more interested in using this as an API for a sandbox use-case I have). Is there a way to do this at the moment / is this on the roadmap?

Another option would be configuring the sprite via checkpoint and then cloning the checkpoint from a base sprite, but I don't see this option anywhere either.

I know it's one me for thinking this -- since the domain is fly.io -- but I was really hoping this is some local solution. Not self-hosted, but just local. A thin command line wrapper to something (docker? bubblewrap?) that gave me sort of a containerized "VM" experience for my local machine using CoW.

Philosophically, I like Fly and have been a customer since very early on.

That said, I dread having to do anything CLI related, which for hobby projects is like once every few weeks.

Glancing at the docs for Sprite, I worry that this will be another CLI where a good 95% of the time that I go to invoke a command, my workflow is interrupted by an auto-updater that takes longer than whatever interaction I'm trying to do and derails my train of thought.

I've been having so much fun working on sprites (and working with sprites) the last the several months. There's some neat parts of the Elixir side of this we're going to open source soon.

Also check out the 5 min demo we put out where I walk thru some sprite basics: https://www.youtube.com/watch?v=7BfTLlwO4hw

I might have missed this in the docs, but is there a way to fork/clone a sprite, or restore a checkpoint into a new one?

Use cases: set up my preferred env in one sprite and use that as a template for others; or fire off a few independent sprites with claude code exploring alternative solutions, then choose a winner and reap the rest.

Wow, this looks absolutely fantastic. Can't wait to take it for a spin. I'm actually surprised it isn't seeing more traction here!

In particular, I'm really excited about the extremely fast start up time and checkpointing. I'm curious if anyone knows any alternatives in this space?

Okay this is super interesting!

As I was reading this I was a bit confused by the issues they mention, but at work I use Claude SSHed to a persistent dev server and I’d be annoyed if I didn’t have eg my git repos there all the time or any part of that workflow was ephemeral. I’m not really aware of what everyone else is doing with sandboxes etc.

But the bit at the end with the MDM server made it click for me. I’ve started generating tiny iOS apps for personal software stuff, because they solve data storage better than the web (at least on iOS). A database on some other server seems like a bad fit/overkill for this stuff, client side storage is too flaky because Safari. But iOS apps are limiting in their own annoying ways compared to web apps.

This looks like a really interesting solution, I can just store the data on a sprite with SQLite or whatever. Visit its URL to use my app, then does it go away on its own after a short time? I could have done that before with a server with storage, but this seems easier/probably cheaper.

If this works well/the way I’m hoping it might be the sweet spot for simple personal software that needs persistent data and you want to run anywhere.

One feature that would make this really nice is if it could have something like Vercel preview environments, where I need to auth my fly account to view the URL. That'd solve the public URL without me needing to do my own auth thing in every app.

docs.sprites.dev requires authentication? And what about adding /llm.txt? I want Claude Code Web to install the cli and deploy what it is working on in a sprite :)

> There are some important million-person apps, but most of them just destroy civil society, melt our brains, and arrange chauffeurs for individual cheeseburgers.

All the cool technical stuff aside - this, for me, was the standout line of the article

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...)

This looks great, i've been wanting a dev sandbox that doesn't run the risk of costing a lot if I forget to turn it off.

I had a few issues

1. manpath: can't set the locale; make sure $LC_* and $LANG are correct

suspect this is due to it inheriting locale from my local machine? easy to get around with some updates to .bashrc

2. the $SHELL environment in my sprite is `/opt/homebrew/bin/fish` I use fish on my local (mac + homebrew) machine and it seems to have inherited from my local machine, its nice to be using fish in the sprite, but seems weird that $SHELL in the sprite points to non-existent path. Slightly concerning that a local env var is being transferred to a remote machine without my explicit permission, I have some sensitive env vars locally.

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...

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.

> When you start a feature branch on your own, do you create an entirely new development environment to do it?

… yes? We have a few wrapper scripts around worktree operations that copy some docker volumes (pg data, bundle cache, etc.) from the base and spins up an entirely new stack on different ports with a host alias. We don’t have to install any deps beyond that because we copied over the ruby gems bundle cache and we’re using Yarn PnP + “zero installs” for client-side deps.

This seems cool, but beware that Fly's other products are not exactly models of stability and polish.

API downtime is a semi-frequent occurrence, as are transient API errors and slowness.

I've also had a ticket open with support for weeks due to rampant billing issues. For instance, a destroyed instance still shows up in my usage report as actively accruing billed time, and at a rate faster than is even possible (something like 2 hours for every 1 actual hour that has passed.)

They've released two new products in the AI space, this and Phoenix.new, and my worry is that they are focused on new products over making what they have good and reliable.

This is cool but like...a docker container running locally works fine too?

On one hand it sounds cool. On the other, I feel like I missed it.

Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore?

(Same thing goes for exe.dev)

I saw this headline, saw the tweets and missed what this was about.

Then read Simon Willison's breakdown and got the 'Aha!'.

I like what they've done, played with it and immediately started to plan how I'd try to implement it myself.

I guess this will be the way to go, for development setups instead of using a dedicated machine. Especially when mobile clients are created for Sprites.

Putting aside the details of the product itself, I love the style of this post. I wish more announcements read like this.

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/

I liked this idea so much I signed up and linked my personal cc (to my job email) to try it out. Unfortunately, it keeps saying "You must add a credit card to use Sprites with this organization" - even though I just linked a card. No way to continue from there: it's a loop that shows my account with an "activate" button, clicking it shows the error and my account again. Fly.io says I have an account now and it's "in good standing".. :(

I don't really know the details of the architecture - but I bet there's heavy use of sqlite - if the sprites can be paused without consuming resources.

Treating agents like full computers instead of ephemeral sandboxes makes a lot of sense—durable state and checkpoints solve real pain points that stateless containers force you to work around. Curious how this approach scales when you need dozens or hundreds of Sprites at once.

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.

i dont think i really get what this gives me over docker. everything i read is how i work for years

The sprite installer got stuck after "Installed to ..." for me. After waiting a few minutes I just ctrl+ced and looked at what it does after and manually ran "sprite auth setup --token <token>" and that seems to just hang for me.

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?

This seems cool but maybe not for a production setting requiring concurrency? I just signed up on PAYG which offers 3 concurrent sprites. I only see an option to upgrade to 10 concurrent sprites.

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.

I thought fly.io snapshots weren't guaranteed to stick around? Although I can can't find the docs mentioning it, but i checked within the last few months... maybe they changed it?

It'd cool to create a MCP for this so you can have your agents run persistent code/other agents.

This is a large pain point today if you aren't technical, most of the chat interfaces just let you create frontend only apps.

Would LOVE a Termux build of the CLI. I ran the linux install script and got an incompatible binary.

What is the criteria for a sprite being "idle"? Is it no network activity or is it cpu based?

This sounds great and it's roughly what exe.dev is doing too. Coincidence?

> Stop killing your sandboxes every time you use them.

Fo people do this? I’ve never heard of it.

something simpler I've did, in the same spirit: LXC containers (using Incus) in a VM. LXC containers look and feel like VMs, but are very lightweight. And the VM they all run in provide the hard sandbox.

and when I spin up a new LXC container cloud-init sets it up with the agents and my repos inside

Does cron work (wake up the vm) there?

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?)

> They go idle and stop metering automatically, so it’s cheap to have lots of them. I use dozens.

> Despite all that, they’re fully durable. They don’t die until I tell them to.

what?

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?

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?

This is amazing. Great job Fly team!

Unsure if it's an intended typo: `rm -rf $HMOE/bin`

I'm not really sure I get the value of these being remotely hosted. We're writing code on super powerful machines with hypervisors built in.

My libvirt setup does this right now, I have a little dumb cli I wrote that lets me create, start, stop, save, restore, and destroy preconfigured machines. I use it for testing provisioning scripts and playbooks. You get the full cloud experience by including a cloud-init ISO so you can ssh to it the moment it boots with my key. Didn't realize I was at the frontier of computing paradigms.

Don't get me wrong the interface fly has is super nice but it feels like the endgame isn't remote hosted computers but a nice user-friendly interface (i.e. what docker did) but it's for persistent local VMs.

Nice. I'm trying it for our CI/CD, with GitHub actions just launching sprites.

> I have kids. They have devices. I wanted some control over them. So I did what many of you would do in my situation: I vibe-coded an MDM.

Wait, what?

Now, please make it easy to control network egress!