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.
Code and Let Live
111–120 of 195 posts
Re: Code and Let Live
#112Okay 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.
Re: Code and Let Live
#113I 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.
What about `docker run`? It'll be the same isolated container that keeps state. You can also mount some local directory
Re: Code and Let Live
#114I'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
One of the coolest things about this is that Claude in his environment --- without him asking to --- knows how to drive Sprites. If you ask it to run a server, it will register it as a local service so it survives reboots. Without you asking to, it'll checkpoint when it makes big changes. I think this is kind of freaky. I can't say enough how, if you're using this like Kurt and Chris have been, you have like, a dozen…
That’s a great demo! For curious mere mortals, are all those custom instructions that make Claude know how to use it public? I’d like to learn how to drive it myself too, just out of curiosity!
Re: Code and Let Live
#115I'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…
Thanks for the writeup on the libvirt setup. At some point I used local docker containers for this.
Re: Code and Let Live
#116I 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.
It's coming, and it'll make sense how and why next week when I run the "how this shit works" post. I actually pushed to include it in the launch release. You'd have to ask Kurt why he didn't, but I think the idea is just to get more real-world usage first.
Do you expect that to replace git worktree for getting Claude to work on multiple things in parallel? That was something I was curious about watching the demo video.
Re: Code and Let Live
#117Would LOVE a Termux build of the CLI. I ran the linux install script and got an incompatible binary.
Re: Code and Let Live
#118Philosophically, 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.
Re: Code and Let Live
#119Does cron work (wake up the vm) there?
Re: Code and Let Live
#120I'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.…
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!!!
For those of us who weren’t on that podcast, can you clarify who Theo is?