I love absolutely everything about this… except for the lack of cross-platform support. I know how ludicrous it is to expect that, but… most workflows I’m considering solutions like this for are crippled by their inability to run Xcode or a native Windows build. Heck, I’m pretty sure I’ll even run into glibc version mismatches that block work I care about.
Frustrating that the best solution is still, “well, if that’s important to you, then set that up in your home lab or rent some extra (pet) VMs in the cloud.”
I appreciate the Fly.io team’s enthusiasm and am optimistic this will mature into a product I’d pay for, but my initial impression was of a lack of polish.
Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result (https://docs.sprites.dev). Blog posts and forum threads and Claude skills shouldn’t be a substitute.
The snappiness of the sprites is very cool and I can definitely see it integrating into future Claude Code workflows. But the lack of a base container images means you’re still doing setup work on the sprite before you can begin development. I understand the philosophy is that sandboxes should be persistent, but Claude Code sessions also work better when isolated from each other, so it’d be nice to have some precepts to get a workspace setup quickly (given agentic coding is clearly a target).
I also found the CLI unintuitive but maybe that was just me!
So very cool idea but left with the impression that the Fly.io team’s should have spent a couple weeks on polish before shipping.
You're not wrong. The documentation actually had a hallucinated link to an Anthropic dependency in it when we shipped. Right now the attitude is mostly "if we have to document it extensively, we're doing something wrong". It's been in the works for awhile, with a small team, and we're just getting it out there right now.
I've been needling Kurt for several months now that if we wait until it's polished enough that we don't see comments like this, we're doing it wrong.
For what it's worth, I evaluated Fly.io during a divorce from Heroku some time in mid 2022 (I think), found the platform was... way too rough around the edges at the time to want to migrate any real workloads. I kept it on my radar and shipped an MVP with it in 2024, found it was a lot more polished, and now have multiple production apps running there. I'm genuinely pumped about Sprites and have started building against the API—I did notice the weirdness with the docs, but you guys have been doing well on the "this thing that {was broken|I didn't like|was missing} now works the way I'd hoped it would" front.
Appreciate your perspective and totally understand that at some point you just have to ship it! From the outside it looks like a bit less time on XYZ feature and bit more time on marketing polish might have been a good call. But can only speculate what the trade offs were internally. Best of luck maturing the product!
The main things i think are missing is (1) how much am i spending and (2) why isn't my sprite paused, and (3) how can i get my stuff out (it would be nice to be able to mount in either direction or else integrate with git/git worktrees).
I ended up using it (and enjoying yolo mode!) but then my sprites weren't pausing and i was worried about spending too much so i deleted them.
I'm sure this is a difference-of-learning or whatever, but I'm usually unwilling to try a product until I can understand it and how it works from the documentation
Understandable. Our current take is that there's not really much to know, and that the people this will really light up are good with that. Of course, we'll flesh out documentation!
I'm really jazzed about this particular product as a product (I just really enjoy using it), but the post is mostly about how we built it, and deliberately not much about how best to use it.
I hate being negative but it sounds like par for the course for fly.
Incredible (truly, incredible, world-class) engineers that somehow lack that final 10% of polish/naming/documentation that makes things...well, seriously usable.
I remember last time I tried them the bizarre hoops/documentation around database creation. I _think_ they solved that but I remember at the time it felt almost like I was getting looked down upon as a user. Ugh, you need clarity? how amateurish!
+1. This thread, the thread about documentation, and the thread about turning off Sprites, when taken together, thoroughly illustrate why I'm not currently a Fly user.
Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled).
It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it.
Can't tell for sure if this means I'm losing credits as there is no billing usage shown anywhere.
Also waiting for the moment where I can launch a sprite from another's checkpoint.
We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.
This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.
ahh finally success—a fresh sprite goes to sleep as it should. unfortunately the original one i created doesn't, so I guess I'm going to have to kill that one off.
Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.
They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering.
This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we don't make our money by billing people for stuff they don't want. We've always gone out of our way not to nickel-and-dime casual users and we're trying hard to find new ways to lean into that here.
(Destroying a Sprite you're done with is a perfectly reasonable move; they're disposable.)
My read of his response is that, even though the sprite is in a running state, that doesn’t mean it’s in a billable state given you aren’t connected; that’s not said explicitly, and I’m making an inference, and so it would be helpful if you let us know if you are billed for these hours.
I think the idling feature still needs some work. I created one over the weekend that hasn't idled once, and I've run several tests with sprites that have nothing in them—just `sprite create` and log out, just to see what happens (which unfortunately is nothing, left alone it keeps on running as well.)
I love the idea and most of the execution, I've really enjoyed getting my first sprite configured just the way I want it. It just needs the idling feature to work as advertised before I think I can use it as cost-effectively as it promises.
Get a console in your sprite. Run “screen”. Run a loop in there : while date; do sleep 1; done. Detach screen and exit the session. Wait a few minutes and go back into the sprite. Reattach screen. You’ll see a gap in the timestamps.
They do suspend even when they say they are “running”.
I created a "mcp server" for sprites yesterday through this new ecosystem I am working on, you can clone the collection, and then just add this https://tpmjs.com/api/mcp/ajax/sprites/sse mcp sse url to claude desktop, or anything you want.
tpmjs is a registry of ai sdk npm packages (i created them for sprites), which you can add to personal collections, we automatically server your collections as mcp servers if you want.
I've been having fun with OpenCode's webui in a Sprite, set it up right in Termux and you can vibe code a website with a full backend from your phone. I have a Termux shortcut that sets up a port forward and pops open my web browser to the OpenCode webui. OpenCode can pick up the Sprite skill built into the containers so it can manage the instance itself (mostly setting up and destroying services).
Of course you can do similar with a VPS, but this makes it very easy (and cheap!) to spin up an entire new machine with a public url and HTTPS whenever you want to.
Yeah, i’ve been looking at this. The easier this is to attach to your tailnet and ssh in from inside, I don’t think you’re dealing with the proxy then.
I tried several things and this is going to be the next one.
Sounds cool. I love Fly.io. That crew is sharp. The article could do with a few pictures to illustrate the layers. I’ve read it, but I can’t say that I understand the implementation.
I wish I'd had more space to write about the global orchestrator design, because it's fun.
The Fly Machines orchestrator goes through some trouble to keep the source of truth for each VM decentralized, owned by the physical it runs on. But there's still global state --- apps, organizations, services. That stuff is all on Postgres. Postgres keeps up with it just fine but I'd be lying if I didn't say we're always looking out the corner of our eyes on metrics.
The global state for Sprites is on object storage. Each organization gets a separate SQLite database, and that database is synchronized to object storage with Litestream.io (Lightstream is load bearing in a bunch of places here; solid as a rock for us).
I think people really still sleep on the "multiple SQLite database" backing store design.
I've been working on the orchestrator side with Elixir and Phoenix, so happy to continue the discussion for curious minds. One of the coolest things we can do is things like this in Elixir - from any node we can reach out to a sqlite db across the planet:
OrgTracker.with_repo(org_id, fn ->
repo.all(from sprite in "sprites", select: ...)
end)
That will find or place an Elixir process on the cluster and rpc the target node with our code. Placements can be sticky so they pin to a machine so we don't have to suck down the db every start, but we also balance out the load and handle failover of durable processes automatically. Combined with litestream, the result is distributed sqlite with failover while treating it essentially like a locally reachable sqlite db. Yes there is the speed of light to contend with, but by sending the execution across the wire rather than individual queries, we only ever pay a single hop to reach the process/sqlite.
We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc, ie `:erpc.call` underneath rather than FLAME where we are managing a pool of elastic nodes, then rpc'ing them.
Thanks for the reply. Summary: Here's this really cool thing we're doing! Oh, are you wrote something exotic for it? Nope, just regular Erlang goodness that's been around 20 years.
Cloudflare definitely isn't with their Durable Object design. As an infra developer/Django user myself, I know it's a pretty big paradigm shift to think in the 1 DB per user realm.
However, I do think it'll unlock "globally available" apps as a first class citizen moving forward. If Uber were made today, I suspect it'd follow the 1 DB per user and be deployed really close to the edge with providers like Fly.io, Koyeb, or Cloudflare.
It’s not even really outdated or unused. Just about everyone who makes 2D games still uses the term “sprite” all the time. The meaning has become slightly less specific, but otherwise is really the same.
Regardless of the usage of the term Sprite, the real measure of how appropriate it is to use the term for something else is how many people get confused in this manner. I can't really tell what the average reader would think because my background is in game development, so my view is not representative.
I think people can get bogged down in the technical weeds over what a sprite is in graphics. Historically it started out as mini graphics overlays in hardware. There was a transition period motivated by Amiga documentation to have Sprites and Bobs, to distinguish, and perhaps advertise, the use of the Blitter. When software or Blitter Sprites became nearly ubiquitous, they returned to simply being called Sprites, the fairly rare use of the original form became known as Hardware Sprites. Usually it was only mouse pointers that remained as Hardware Sprites
Obviously the term Hardware Sprites is not strictly a distinguishing label either. They are all controlled by software using hardware with some degree of balance between the two.
Most Android devices have hardware that's capable of rather interesting version of hardware sprites. Hardware real-time compositing with scaling and colorspace conversions.
Not sure where to report this, so here goes: something weird's going on with the title setters (from default .bashrc, the 'case' block near the top) when connecting from my Linux box.
Tried with xterm, tilix and ghostty, all of which support the title setter escape sequence locally. For some
reason, these get messed up (smells like edge case with escaping) and the result looks like this:
$ sprite c ": history-search-backward'
\]\u@\h\[\]:\[\]\w\[\]\$ ' ": history-search-forward'sprite@sprite:~$
"sprite@sprite:~$
I'm guessing y'all use Zsh because that works flawlessly :)
Shell environments are by far the most difficult part of building a stateful sandbox with checkpoints and restores. It's bananas. This will be fixed soon.
Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on? Do these horizontally scale a long lived, high trafficked application?
TFA links to a post by Kurt M at Fly which speaks to this, from a personal perspective. They are using sprites for a “production” workload - a tool for their family - and it’s persistent and accessible enough that they don’t have plans to move it.
Thomas characterizes this as “believ[ing] that the future belongs to malleable, personalized apps”, which I think describes the use case perfectly. As a “barefoot developer” (to borrow another localfirst term, thanks Maggie Appleton), does every app really need more than a persistent home and an URL?
And so to your question “is the idea that these things can also/should run production workloads”, I believe “can” is right - but suspect that supporting “should” is on Fly’s roadmap.
They're an interesting middle ground between pure ephemeral dev environment and production environment. If your audience is the whole Internet, a Sprite won't scale today to serve it. But for most of the apps I'm building, the Sprite is actually fine for the foreseeable future. There's a ton of security automation stuff we're doing that a Sprite keeps up just fine with; the sandwich bracket I'm running downthread is also indefinitely fine on a Sprite.
On the other hand, if I took the sandwich bracket app and made it a generic "run a bracket" app and that app (inexplicably) got popular, I'd need to move it to a Fly Machine setup.
Sounds neat! Also kind of funny, because I already use Fly machines as a bit of a playground for some personal projects and really like it for that purpose. I have minor issues, some of which this blog post directly talks about, but nothing that has held me back.
Also I like a lot of what you get built-in with Fly machines(ex:Grafana). So I am curious how this would fit in my workflow. Maybe Sprites for rapid development and toy projects, and move to a Fly machine when I need something a little more beefy?
To me, this sounds more monolithic than containers. I think I'd like something less monolithic. However, those who like monorepos might be more quick to develop an interest in this. I could of course use containers within the MicroVM, which is what I really want anyways, because I want lighter weight containers than MicroVMs for sandboxes.
While looking into giving fly another shot as a cloud provider even though I think it's still pretty much a commodity for me, I found an issue in Google: I searched for "fly.io sao paolo" and the title of the first result on fly.io is "Regiones · Fly Docs", translated from english to Spanish. While I find the translation in titles on Google annoying, I haven't often seen the characters messed up like this. I reproduced this in Incognito at this URL: https://www.google.com/search?hl=es&q=fly.io%20sao%20paolo
I was reading through the documentation and it seems like these are writing directly to storage not on the machine where the sprite lives? That makes me worry for how slow the storage is. npm install writes a lot of files.
It's tiered, they have local nvme that gets written back to object storage.
npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.
The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.
What I missed when trying it was a simple way of accessing private repositories. There does not seem to be ssh agent forwarding, or is there? What do people use?
I realize this is all very fresh, but still wondering…
Very cool. One usecase the blogpost seems to hint at is to use this to implement async agents that write code for you. Like, you have some system that hears about a new issue — from slack, linear, wherever — and then spins up a Sprite, checks out the codebase, works on a solution, commits, and creates a PR.
Is that what you guys are thinking of? I get that Sprites are a new primitive, but I feel confused as hell about what exactly I'd want to do with it.
I love sprites. I’m currently trying g to figure out how to best launch and connect to sprites from iOS. I’ve tried several things - vibe coding a terminal app is a little wild and not the best way maybe to handle this.
I believe currently the sprites CLI is using websockets to handle the connection, and the external proxy when you make a sprite public doesn’t handle websockets correctly?
Made a sprint and connected via Windows Terminal and noticed it's purely white on black, not observing the normal Claude terminal color schemes... any ideas why that's the case? Am I missing something insanely simple?
It's too early to say. We started the bracket back in 2020 with a nomination Google Sheet, and then the pandemic happened, and then I kept saying I'd throw a web app together for us to actually do a seeded bracket with; 5 years later, some of the restaurants have changed, so we're re-doing nominations, and we'll have bracket voting rounds starting probably in February. I owe it all to Sprites!
Nhu Lan's Banh Mi #1 and JPG's Muffaletta are the top 2 current noms, but I think the Tempesta B. Franklin is a sleeper, and the Phodega Viet Dip has a cheering section and I haven't tried it yet. The joy of doing an actual bracket is that it'll involve people doing field trips to have their first Mr. D's Pork Shish-Ka-Bob sandwich, or the Alpine Combo.
It's a 16 sandwich tournament and we're at like 26 nominations right now so it'll be interesting to see what happens.
I would love to just mount a directory via SFTP, so I can use my IDE alongside the far-away Claude. That would put this in the realm of daily use for development.
Thought this was going to be a deep dive into sprite sheets.
Low and behold, yet another AI product selling advertisement + veiled promotion on HN.
It's almost as if the guidelines don't matter anymore. From [0].
'Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.'
It's a hardware-isolated Linux shell with a durable disk you can conjure out of the sky on 1.5 seconds notice that costs virtually nothing when you're not actively using it. If we could have shipped this in 2021, before anyone thought coding agents would work, we'd have barfed on our shoes with excitement.
I guess I can see how pre-installing some LLM agents makes it potentially seem "AI-centric", but I don't understand at all how this could be "US-centric".
I love absolutely everything about this… except for the lack of cross-platform support. I know how ludicrous it is to expect that, but… most workflows I’m considering solutions like this for are crippled by their inability to run Xcode or a native Windows build. Heck, I’m pretty sure I’ll even run into glibc version mismatches that block work I care about.
Frustrating that the best solution is still, “well, if that’s important to you, then set that up in your home lab or rent some extra (pet) VMs in the cloud.”
I appreciate the Fly.io team’s enthusiasm and am optimistic this will mature into a product I’d pay for, but my initial impression was of a lack of polish.
Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result (https://docs.sprites.dev). Blog posts and forum threads and Claude skills shouldn’t be a substitute.
The snappiness of the sprites is very cool and I can definitely see it integrating into future Claude Code workflows. But the lack of a base container images means you’re still doing setup work on the sprite before you can begin development. I understand the philosophy is that sandboxes should be persistent, but Claude Code sessions also work better when isolated from each other, so it’d be nice to have some precepts to get a workspace setup quickly (given agentic coding is clearly a target).
I also found the CLI unintuitive but maybe that was just me!
So very cool idea but left with the impression that the Fly.io team’s should have spent a couple weeks on polish before shipping.
You're not wrong. The documentation actually had a hallucinated link to an Anthropic dependency in it when we shipped. Right now the attitude is mostly "if we have to document it extensively, we're doing something wrong". It's been in the works for awhile, with a small team, and we're just getting it out there right now.
I've been needling Kurt for several months now that if we wait until it's polished enough that we don't see comments like this, we're doing it wrong.
For what it's worth, I evaluated Fly.io during a divorce from Heroku some time in mid 2022 (I think), found the platform was... way too rough around the edges at the time to want to migrate any real workloads. I kept it on my radar and shipped an MVP with it in 2024, found it was a lot more polished, and now have multiple production apps running there. I'm genuinely pumped about Sprites and have started building against the API—I did notice the weirdness with the docs, but you guys have been doing well on the "this thing that {was broken|I didn't like|was missing} now works the way I'd hoped it would" front.
Appreciate your perspective and totally understand that at some point you just have to ship it! From the outside it looks like a bit less time on XYZ feature and bit more time on marketing polish might have been a good call. But can only speculate what the trade offs were internally. Best of luck maturing the product!
The main things i think are missing is (1) how much am i spending and (2) why isn't my sprite paused, and (3) how can i get my stuff out (it would be nice to be able to mount in either direction or else integrate with git/git worktrees).
I ended up using it (and enjoying yolo mode!) but then my sprites weren't pausing and i was worried about spending too much so i deleted them.
I'm sure this is a difference-of-learning or whatever, but I'm usually unwilling to try a product until I can understand it and how it works from the documentation
Understandable. Our current take is that there's not really much to know, and that the people this will really light up are good with that. Of course, we'll flesh out documentation!
I'm really jazzed about this particular product as a product (I just really enjoy using it), but the post is mostly about how we built it, and deliberately not much about how best to use it.
I hate being negative but it sounds like par for the course for fly.
Incredible (truly, incredible, world-class) engineers that somehow lack that final 10% of polish/naming/documentation that makes things...well, seriously usable.
I remember last time I tried them the bizarre hoops/documentation around database creation. I _think_ they solved that but I remember at the time it felt almost like I was getting looked down upon as a user. Ugh, you need clarity? how amateurish!
Naming? We got naming wrong?
Could not have illustrated the point better if I tried.
Likewise!
+1. This thread, the thread about documentation, and the thread about turning off Sprites, when taken together, thoroughly illustrate why I'm not currently a Fly user.
The name is excellent.
Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled).
It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it.
Can't tell for sure if this means I'm losing credits as there is no billing usage shown anywhere.
Also waiting for the moment where I can launch a sprite from another's checkpoint.
We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.
This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.
ahh finally success—a fresh sprite goes to sleep as it should. unfortunately the original one i created doesn't, so I guess I'm going to have to kill that one off.
Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.
There's no way to stop sprites from the CLI.
Supposedly they auto-stop when inactive.
But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping.
I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours.
No way to tell if I'm being billed for it or not.
And the per-hour pricing is extremely expensive.
So for now it's `sprite destroy -s spritename`.
Maybe I'll check it out again in a few months after the fly team has iterated on this a few times.
Sprites are active when:
* They're servicing an incoming HTTP request.
* You're interacting with a console.
They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering.
This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we don't make our money by billing people for stuff they don't want. We've always gone out of our way not to nickel-and-dime casual users and we're trying hard to find new ways to lean into that here.
(Destroying a Sprite you're done with is a perfectly reasonable move; they're disposable.)
No console activity, no HTTP requests, but it doesn't stop.
Can't find any place in CLI or web UI to see how many minutes are charged for CPU, memory, storage.
My read of his response is that, even though the sprite is in a running state, that doesn’t mean it’s in a billable state given you aren’t connected; that’s not said explicitly, and I’m making an inference, and so it would be helpful if you let us know if you are billed for these hours.
> Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console.
They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?
I think the idling feature still needs some work. I created one over the weekend that hasn't idled once, and I've run several tests with sprites that have nothing in them—just `sprite create` and log out, just to see what happens (which unfortunately is nothing, left alone it keeps on running as well.)
I love the idea and most of the execution, I've really enjoyed getting my first sprite configured just the way I want it. It just needs the idling feature to work as advertised before I think I can use it as cost-effectively as it promises.
What does "when you stop interacting with it" mean? Closing all TCP connections? When CPU usage drops to below some threshold?
There needs to be a way to see how much it is being used then and not simply the life of the Sprite.
You can. There’s a usage dashboard
Where is it?
For what it's worth, CPU pricing is based on CPU util. A sprite sitting idle CPU costs almost nothing, even when "active".
So is it similar to railway in this context?
Yeah. My sprites never idled inspite of having nothing running in them and had to be destroyed. Ideally there should be two settings
1. A timeout after the last console session is exited 2. Force idle using the CLI
Just tried it again. Creation took a very long time, then errored.
But despite the error, the sprite was apparently created, and it runs continuously.Get a console in your sprite. Run “screen”. Run a loop in there : while date; do sleep 1; done. Detach screen and exit the session. Wait a few minutes and go back into the sprite. Reattach screen. You’ll see a gap in the timestamps.
They do suspend even when they say they are “running”.
Just use container-os as your runtime image: https://hub.docker.com/r/miget/container-os
and you should be good
Could you explain more about how this helps and how one might use a different runtime image on Sprites?
I don't think you can choose the runtime image on Sprites, not sure what they are referring to here.
I created a "mcp server" for sprites yesterday through this new ecosystem I am working on, you can clone the collection, and then just add this https://tpmjs.com/api/mcp/ajax/sprites/sse mcp sse url to claude desktop, or anything you want.
tpmjs is a registry of ai sdk npm packages (i created them for sprites), which you can add to personal collections, we automatically server your collections as mcp servers if you want.
Creating sprites in an example chat bot -> https://imgur.com/a/ETNxR1o
Creating sprites in claude desktop -> https://imgur.com/myC0U28
Listing out my sprites in claude desktop -> https://imgur.com/rgBU0jm
---
You can view the collection of tools here -> https://tpmjs.com/ajax/collections/sprites (fork it to use it yourself)
I'm looking into exe.dev and sprites.dev to build out extra features into tpmjs, agent sandboxes make a lot of sense.
I've been having fun with OpenCode's webui in a Sprite, set it up right in Termux and you can vibe code a website with a full backend from your phone. I have a Termux shortcut that sets up a port forward and pops open my web browser to the OpenCode webui. OpenCode can pick up the Sprite skill built into the containers so it can manage the instance itself (mostly setting up and destroying services).
Of course you can do similar with a VPS, but this makes it very easy (and cheap!) to spin up an entire new machine with a public url and HTTPS whenever you want to.
What's the option for iOS? I've tried installing ish and a-shell and can't get the sprites CLI installed on either of them.
Yeah, i’ve been looking at this. The easier this is to attach to your tailnet and ssh in from inside, I don’t think you’re dealing with the proxy then.
I tried several things and this is going to be the next one.
Let me know when you figure it out!
Vibe code a client in bash or Python that uses the Sprites HTTP API maybe?
Sounds cool. I love Fly.io. That crew is sharp. The article could do with a few pictures to illustrate the layers. I’ve read it, but I can’t say that I understand the implementation.
I wish I'd had more space to write about the global orchestrator design, because it's fun.
The Fly Machines orchestrator goes through some trouble to keep the source of truth for each VM decentralized, owned by the physical it runs on. But there's still global state --- apps, organizations, services. That stuff is all on Postgres. Postgres keeps up with it just fine but I'd be lying if I didn't say we're always looking out the corner of our eyes on metrics.
The global state for Sprites is on object storage. Each organization gets a separate SQLite database, and that database is synchronized to object storage with Litestream.io (Lightstream is load bearing in a bunch of places here; solid as a rock for us).
I think people really still sleep on the "multiple SQLite database" backing store design.
I've been working on the orchestrator side with Elixir and Phoenix, so happy to continue the discussion for curious minds. One of the coolest things we can do is things like this in Elixir - from any node we can reach out to a sqlite db across the planet:
OrgTracker.with_repo(org_id, fn ->
end)That will find or place an Elixir process on the cluster and rpc the target node with our code. Placements can be sticky so they pin to a machine so we don't have to suck down the db every start, but we also balance out the load and handle failover of durable processes automatically. Combined with litestream, the result is distributed sqlite with failover while treating it essentially like a locally reachable sqlite db. Yes there is the speed of light to contend with, but by sending the execution across the wire rather than individual queries, we only ever pay a single hop to reach the process/sqlite.
(Disclaimer: Newbie checking but still curious).
Are you using libluster or Distributed Erlang to reach the clusters? Or just simple networking over the Fly network.
> That will find or place an Elixir process on the cluster and rpc the target node with our code.
Is this similar to what you did with Flame? Or just a refinement of that idea.
We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc, ie `:erpc.call` underneath rather than FLAME where we are managing a pool of elastic nodes, then rpc'ing them.
Thanks for the reply. Summary: Here's this really cool thing we're doing! Oh, are you wrote something exotic for it? Nope, just regular Erlang goodness that's been around 20 years.
Cloudflare definitely isn't with their Durable Object design. As an infra developer/Django user myself, I know it's a pretty big paradigm shift to think in the 1 DB per user realm.
However, I do think it'll unlock "globally available" apps as a first class citizen moving forward. If Uber were made today, I suspect it'd follow the 1 DB per user and be deployed really close to the edge with providers like Fly.io, Koyeb, or Cloudflare.
For those who missed it, tptacek wrote TFA.
The sprite is a pretty outdated thing these days, but is the term sufficiently unused to make it free for reuse?
It’s not even really outdated or unused. Just about everyone who makes 2D games still uses the term “sprite” all the time. The meaning has become slightly less specific, but otherwise is really the same.
I thought this was a post about graphics.
Not even remotely outdated. This was a terrible name to select.
What's a sprite?
https://en.wikipedia.org/wiki/Sprite_(computer_graphics) is the one I'm thinking of.
A graphical object composited just in time in display scanning process.
(Or in other words, a graphical object on screen that is not present in a framebuffer of any kind.)
There was a time before 8bit video games.
https://www.merriam-webster.com/dictionary/sprite
I personally associate the term Shakespeare's The Tempest: https://en.wikipedia.org/wiki/Ariel_(The_Tempest)
This is immediately what popped into my head, and I clicked the link thinking it was going to be some old-school game dev content.
Regardless of the usage of the term Sprite, the real measure of how appropriate it is to use the term for something else is how many people get confused in this manner. I can't really tell what the average reader would think because my background is in game development, so my view is not representative.
I think people can get bogged down in the technical weeds over what a sprite is in graphics. Historically it started out as mini graphics overlays in hardware. There was a transition period motivated by Amiga documentation to have Sprites and Bobs, to distinguish, and perhaps advertise, the use of the Blitter. When software or Blitter Sprites became nearly ubiquitous, they returned to simply being called Sprites, the fairly rare use of the original form became known as Hardware Sprites. Usually it was only mouse pointers that remained as Hardware Sprites
Obviously the term Hardware Sprites is not strictly a distinguishing label either. They are all controlled by software using hardware with some degree of balance between the two.
Most Android devices have hardware that's capable of rather interesting version of hardware sprites. Hardware real-time compositing with scaling and colorspace conversions.
Not sure where to report this, so here goes: something weird's going on with the title setters (from default .bashrc, the 'case' block near the top) when connecting from my Linux box.
Tried with xterm, tilix and ghostty, all of which support the title setter escape sequence locally. For some reason, these get messed up (smells like edge case with escaping) and the result looks like this:
I'm guessing y'all use Zsh because that works flawlessly :)Shell environments are by far the most difficult part of building a stateful sandbox with checkpoints and restores. It's bananas. This will be fixed soon.
Recent and related: Code and Let Live - https://news.ycombinator.com/item?id=46557825 - Jan 2026 (186 comments)
Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on? Do these horizontally scale a long lived, high trafficked application?
TFA links to a post by Kurt M at Fly which speaks to this, from a personal perspective. They are using sprites for a “production” workload - a tool for their family - and it’s persistent and accessible enough that they don’t have plans to move it.
https://fly.io/blog/code-and-let-live/
Thomas characterizes this as “believ[ing] that the future belongs to malleable, personalized apps”, which I think describes the use case perfectly. As a “barefoot developer” (to borrow another localfirst term, thanks Maggie Appleton), does every app really need more than a persistent home and an URL?
And so to your question “is the idea that these things can also/should run production workloads”, I believe “can” is right - but suspect that supporting “should” is on Fly’s roadmap.
They're an interesting middle ground between pure ephemeral dev environment and production environment. If your audience is the whole Internet, a Sprite won't scale today to serve it. But for most of the apps I'm building, the Sprite is actually fine for the foreseeable future. There's a ton of security automation stuff we're doing that a Sprite keeps up just fine with; the sandwich bracket I'm running downthread is also indefinitely fine on a Sprite.
On the other hand, if I took the sandwich bracket app and made it a generic "run a bracket" app and that app (inexplicably) got popular, I'd need to move it to a Fly Machine setup.
> ton of security automation stuff we're doing that a Sprite keeps up
Hm. The sprites.dev webpage goes,
Any plans for Fly.io to support CCA / TDX / SEV-SNP?> Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?..
Yes.
They won't horizontally scale. They're pretty good for hosting my side projects! Not good for, eg, hosting the API that orchestrates Sprites.
Sounds neat! Also kind of funny, because I already use Fly machines as a bit of a playground for some personal projects and really like it for that purpose. I have minor issues, some of which this blog post directly talks about, but nothing that has held me back.
Also I like a lot of what you get built-in with Fly machines(ex:Grafana). So I am curious how this would fit in my workflow. Maybe Sprites for rapid development and toy projects, and move to a Fly machine when I need something a little more beefy?
Looking forward to checking this out.
I was looking forward to a post about designing sprites, i.e. little graphical blobs flying across screen. Needless to say, this was not it.
Especially with the recent story on Street Fighter having a typo fixed by creative usage of sprites. :D
Me too. Well hardware implementation.
To me, this sounds more monolithic than containers. I think I'd like something less monolithic. However, those who like monorepos might be more quick to develop an interest in this. I could of course use containers within the MicroVM, which is what I really want anyways, because I want lighter weight containers than MicroVMs for sandboxes.
While looking into giving fly another shot as a cloud provider even though I think it's still pretty much a commodity for me, I found an issue in Google: I searched for "fly.io sao paolo" and the title of the first result on fly.io is "Regiones · Fly Docs", translated from english to Spanish. While I find the translation in titles on Google annoying, I haven't often seen the characters messed up like this. I reproduced this in Incognito at this URL: https://www.google.com/search?hl=es&q=fly.io%20sao%20paolo
I was reading through the documentation and it seems like these are writing directly to storage not on the machine where the sprite lives? That makes me worry for how slow the storage is. npm install writes a lot of files.
It's tiered, they have local nvme that gets written back to object storage.
npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.
The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.
What I missed when trying it was a simple way of accessing private repositories. There does not seem to be ssh agent forwarding, or is there? What do people use?
I realize this is all very fresh, but still wondering…
Did you ever find an answer? Other than copy/pasting my priv/pub keys into ~/.ssh/ I'm not sure.
I love my sprite.
I just want an easier way to connect to and launch sprites from my phone.
any ideas there?
Very cool. One usecase the blogpost seems to hint at is to use this to implement async agents that write code for you. Like, you have some system that hears about a new issue — from slack, linear, wherever — and then spins up a Sprite, checks out the codebase, works on a solution, commits, and creates a PR.
Is that what you guys are thinking of? I get that Sprites are a new primitive, but I feel confused as hell about what exactly I'd want to do with it.
I love sprites. I’m currently trying g to figure out how to best launch and connect to sprites from iOS. I’ve tried several things - vibe coding a terminal app is a little wild and not the best way maybe to handle this.
I believe currently the sprites CLI is using websockets to handle the connection, and the external proxy when you make a sprite public doesn’t handle websockets correctly?
Does that sound right?
Checkpoints defined by the guest, not the host, was something I was working on recently too [1] (just before this came out). Very validating!
[1] https://github.com/danthegoodman1/checker
>Any time anybody needs a pen, several are at hand, in exactly the first place they look.
>Now, today, under the hood, Sprites are still Fly Machines. But they all run from a standard container.
So its basically a faster VM?
What are some use cases for this that benefit from the faster boot time?
> some use cases for this that benefit from the faster boot time
Faster create times. Sprites create (including booting up) in a second or two, per TFA.
One usecase for Sprites I see are disposable dev boxes (like for rapid prototyping with Coding Agents).
Made a sprint and connected via Windows Terminal and noticed it's purely white on black, not observing the normal Claude terminal color schemes... any ideas why that's the case? Am I missing something insanely simple?
Very cool product, but I have to ask, out of personal interest:
What did the bracket in the slack channel determine was “Chicago’s best sandwich”? Or the top three, even? I’m always looking for new sandwiches.
Off the top of my head, I might nominate,
- the pork tenderloin at JT’s
- the Big L from Fontano’s (hot take, I know; it might go to Graziano’s if they hinge-cut the bread, but not doing so is a fatal flaw to me)
- the Cambodian fried chicken sandwich that’s occasionally available at Hermosa
- honorable mention: the comically oversized chicken torta at Migos
(Edit: I inexcusably transposed Bari and Fontano’s; the nomination is intended for Fontano’s)
It's too early to say. We started the bracket back in 2020 with a nomination Google Sheet, and then the pandemic happened, and then I kept saying I'd throw a web app together for us to actually do a seeded bracket with; 5 years later, some of the restaurants have changed, so we're re-doing nominations, and we'll have bracket voting rounds starting probably in February. I owe it all to Sprites!
Nhu Lan's Banh Mi #1 and JPG's Muffaletta are the top 2 current noms, but I think the Tempesta B. Franklin is a sleeper, and the Phodega Viet Dip has a cheering section and I haven't tried it yet. The joy of doing an actual bracket is that it'll involve people doing field trips to have their first Mr. D's Pork Shish-Ka-Bob sandwich, or the Alpine Combo.
It's a 16 sandwich tournament and we're at like 26 nominations right now so it'll be interesting to see what happens.
I’m so happy I kept reading these comments and came across this gem. Sprites are cool and all but a sandwich tournament is next level.
I love this bracket. The first startup I worked (Triggr Health) at was in Chicago and we started a bracket for best wings. Sadly we never finished!
Very credible nominations; clearly “this guy sandwiches.” Thanks!
I’d love to see a post of some kind when it’s all settled; you’re doing the lord’s work here.
Is there a way to copy files to/from the sprite? Couldn't see an option for that in the CLI
There's an FS API that shipped yesterday:
It'll get CLI support very soon.But I've just been using magic-wormhole for this.
Piping server is another interesting idea for ephemeral transfers They are pretty cool!
https://github.com/nwtgck/piping-server
I was trying to copy a directory and used:
Pull from sprite to local: sprite exec -s my-sprite sh -c "tar -czf - /home/sprite/<my_dir>" | tar -xzf - -C ./
Push from local to sprite: COPYFILE_DISABLE=1 tar -czf - <my_dir> | sprite exec -s my-sprite sh -c "tar -xzf - -C /home/sprite/"
I would love to just mount a directory via SFTP, so I can use my IDE alongside the far-away Claude. That would put this in the realm of daily use for development.
`cat file.txt | sprite exec -s <name> bash -c "cat > ~/file.txt"` is my go to.
How does Sprites compare to E2B sandboxes?
This is not the kind of sprites I'm interested in
Thought this was going to be a deep dive into sprite sheets.
Low and behold, yet another AI product selling advertisement + veiled promotion on HN.
It's almost as if the guidelines don't matter anymore. From [0].
'Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.'
In fairness, I don't think the poster is a Fly.io employee, so that guideline doesn't quite apply here.
[flagged]
It's a hardware-isolated Linux shell with a durable disk you can conjure out of the sky on 1.5 seconds notice that costs virtually nothing when you're not actively using it. If we could have shipped this in 2021, before anyone thought coding agents would work, we'd have barfed on our shoes with excitement.
[flagged]
Please read and follow the HN Guidelines. https://news.ycombinator.com/newsguidelines.html
He's at home! Washing his tights!
I guess I can see how pre-installing some LLM agents makes it potentially seem "AI-centric", but I don't understand at all how this could be "US-centric".
the US is the centre of the world, and AI is at the centre of US attention!
why would anyone do anything else, anywhere else?