zlacker

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

>>skybri+(OP)
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.

>>skybri+(OP)
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!

>>skybri+(OP)
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.

>>HumanO+7F
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

>>HumanO+7F
[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.

>>crawsh+UE2
Exe.dev is very cool.

>>tptace+H3
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?

>>breaki+9g7
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.

>>tptace+8J7
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.