Top
Best
New

Posted by usrme 1/9/2026

Code and Let Live(fly.io)
https://sprites.dev/
508 points | 189 commentspage 3
jmogly 1/9/2026|
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.
dmux 1/9/2026|
> 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?

cess11 1/11/2026||
Not sure if I've read such an article, but it would be a reasonable next step from the globally addressable processes of the BEAM VM.

As I understand it Unison tries to do something like that but that might be wrong.

https://www.unison-lang.org/

dotemacs 1/11/2026||
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.

atomon 1/11/2026||
Putting aside the details of the product itself, I love the style of this post. I wish more announcements read like this.
rao-v 1/11/2026||
I'd really love a locally hostable limited version of this, so I can do some quick messing around before switching to the cloud version for long term usage. It cannot be too hard to spin up an API compatible version that just uses the local device + 20GB or something right?
Spivak 1/11/2026||
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.

indigodaddy 1/11/2026||
Sure, but plenty of users don't want to have to do/configure all that locally, sorta like I want shared hosting vs my own VPS as a sort of analogy.
haute_cuisine 1/11/2026||
Thanks for the writeup on the libvirt setup. At some point I used local docker containers for this.
indigodaddy 1/11/2026||
How does the sprite ecosystem know when a sprite needs additional resources? If you start maxing out cores or ram usage gets too high you just automatically get allocated more cores/ram? (Assuming live/dynamically correct?)
Zababa 1/12/2026||
> Rather: an intended part of the ordinary course of using a Sprite. Like git, but for the whole system.

What I've been waiting for, for a long time. Basically the thing you need if you want agents to run freely but still in a safe way kinda.

>For reasons we’ll get into when we write up how we built these things, you wouldn’t want to ship an app to millions of people on a Sprite. But most apps don’t want to serve millions of people. The most important day-to-day apps disproportionately won’t have million-person audiences.

I appreciate a lot this vision of personal computing.

I'll give sprites a try, they sound super cool.

a_lanfranco 1/10/2026||
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.
skybrian 1/9/2026||
This sounds great and it's roughly what exe.dev is doing too. Coincidence?
tptacek 1/9/2026||
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.
breakingcups 1/12/2026||
What I like about exe.dev is that you only need ssh to access it, is something like that under consideration for Sprites.dev?

Additionally, is Tailscale/Wireguard connectivity something you'd consider?

tptacek 1/12/2026||
Nope, re: SSH. Tailscale should already work on a Sprite. Everything we do at Fly.io is connected by WireGuard, so it's just a question of whether we want to expose that to users.
breakingcups 1/16/2026||
Tailscale definitely had issues for me, unless I used user-mode networking and even then it was iffy. I should add that it also auto-signed me up for a trial of Fly.io itself, which is useless to me now but might've come in handy later.
HumanOstrich 1/10/2026|||
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.

crawshaw 1/10/2026|||
[exe.dev co-founder here] If you are curious, we have a `clone` command coming soon for sub-section creation of a new VM out of an existing VM. This is our first pass at checkpointing, rather than introducing an independent `snapshot` noun, you can keep a VM around as the snapshot.

We realize that is not going to cover all the business cases we have been discussing with customers and plan to introduce a snapshot concept (in particular for rewinding the state of a VM to an automatic backup), but we have a lot of FS work underway before we can launch it. There are some other things we want out of our VMs that we cannot do using conventional cloud techniques, so we have code to write.

tptacek 1/11/2026||
Exe.dev is very cool.
skybrian 1/10/2026|||
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

memset 1/10/2026||
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!

PanMan 1/11/2026|
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".. :(
PanMan 1/11/2026|
This did resolve itself.. I guess adding the card took.. a few minutes? Errors were confusing tho
More comments...