[HN Gopher] Code and Let Live
___________________________________________________________________
Code and Let Live
https://sprites.dev/
Author : usrme
Score : 153 points
Date : 2026-01-09 19:11 UTC (1 days ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| jmogly wrote:
| 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 wrote:
| > 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?
| skybrian wrote:
| This sounds great and it's roughly what exe.dev is doing too.
| Coincidence?
| tptacek wrote:
| 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.
| memset wrote:
| 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!
| HumanOstrich wrote:
| 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.
| skybrian wrote:
| 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
| crawshaw wrote:
| [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.
| simonw wrote:
| 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/
| realty_geek wrote:
| 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!!!
| dang wrote:
| I know you know this, as you posted it, but readers might want
| to look at this related thread:
|
| _Fly 's Sprites.dev addresses dev environment sandboxes and
| API sandboxes together_ -
| https://news.ycombinator.com/item?id=46561089 - Jan 2026 (10
| comments)
| indigodaddy wrote:
| 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?
| tptacek wrote:
| It depends on which Fly person you talk to. If you talk to Kurt
| he'll try to sell you on his crazy dream of how all software is
| going to be malleable and "prod" doesn't mean anything anymore.
| If you ask me: tell Claude to make a Dockerfile of the current
| state of your Sprite, and then deploy it as a Fly Machine. It's
| a good question, and we're working out how the transition from
| Sprite to Fly Machine works, but that's how I'd do it today.
|
| I don't think we're going to do anything new with GPUs any time
| soon.
| memset wrote:
| 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?)
| simonw wrote:
| Yeah that's about right.
|
| It's a fast starting and fast pausing persistent VM, with a ton
| of built in developer tools (including a preconfigured Claude
| Code) and an extra JSON API for executing commands within it so
| you can treat it as a sandbox.
|
| You may find my writeup here useful:
| https://simonwillison.net/2026/Jan/9/sprites-dev/
| dtkav wrote:
| 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...)
| tptacek wrote:
| If you read Ben Toews work on the tokenizer you have a good
| sense of where I want Sprites to go with key leaks and prompt
| injection:
|
| https://fly.io/blog/tokenized-tokens/
| dtkav wrote:
| Awesome stuff! Thanks for the reply.
|
| Tokenizer is an explicit proxy though right?
|
| My use case is very similar, but I wanted a transparent proxy
| so I could run unmodified scripts. It is a tricky design
| decision though.
|
| I also mount a little fuse filesystem that mints macaroon on
| read (with a shorter lifetime, probably inspired by y'all but
| i forget from where).
|
| I work on realtime collaboration of markdown files (currently
| in Obsidian), which has become a shared-context substrate for
| agents, skills, etc.. Our own company workspace has skills
| that have scoped access to fly, stripe, gmail, etc. We're
| definitely drinking the file-over-app personal-software-for-
| teams Kool-Aid, so the problem space for us includes access
| control and auditing.
|
| Love your work :)
| tptacek wrote:
| We have enough control over the execution environment in a
| Sprite (unlike a Fly Machine, where the implied Linux
| contract we have with our users gets in the way) that we
| can trivially hide explicit proxies.
|
| We can also attach Macaroons to Fly Machines and Sprites
| for configurable ambient privileges, something I've wanted
| us to expose as a feature for a very long time.
| dtkav wrote:
| Awesome, i look forward to that. I think that could be a
| major differentiator for sprites. I wish i could work on
| that problem at fly.io scale.
|
| What is the contract with sprites? Is it just built-with-
| linux but not promising Linux? Or is it more like a
| machine but y'all control the container image?
| tptacek wrote:
| There's no "formal" contract in either place but people
| running on Fly Machines expect that there's nothing at
| all between them and the kernel, and we don't have that
| expectation in Sprites; we can do whatever we want. :)
|
| I don't want to get _too_ far into the rest of the
| details only because I 'm writing this up for next week.
| They're not that interesting technically, but they're a
| really big deal for us in other ways.
| dtkav wrote:
| Great, i look forward to reading it.
| nextaccountic wrote:
| 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?
| tptacek wrote:
| Claude Code is already in the Sprite; just create one and type
| "claude". But they have an API and Claude (or Gemini or Codex)
| can use them remotely too. They're disposable computers. Use
| them however you want.
| hashim-warren wrote:
| You can use git to pull down code from a remote repo
| qhwudbebd wrote:
| 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...
| tptacek wrote:
| I have a post coming next week about the guts of this thing,
| but I'm curious why you think we'd avoid running the storage
| stack inside the VM. From my perspective that's _safer_ than
| running it outside the VM.
| wmf wrote:
| Safer from what? It depends whether you're protecting the
| infra or the data.
| tptacek wrote:
| They're closely linked; protecting the infra _is_
| protecting the data.
| a_lanfranco wrote:
| 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.
| mwcampbell wrote:
| 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.
| indigodaddy wrote:
| Maybe bend smolvm to your needs?
| tptacek wrote:
| That's coming. It's what Jerome has been working on these past
| few months.
| jamietanna wrote:
| Unsure if it's an intended typo: `rm -rf $HMOE/bin`
| CGamesPlay wrote:
| I ran the command to check and it erased /bin and now my sprite
| is busted. But I was able to restore from a checkpoint and it's
| all good.
| mrkurt wrote:
| Intended typo so you can see restore happen ;)
| CGamesPlay wrote:
| 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?
| mrkurt wrote:
| sprite url update --auth public
|
| It requires your api token by default.
| CGamesPlay wrote:
| Oh, thanks, that works. ([edit] rewrote this whole post) I
| guess I need to install my own tunneling into the VM to do
| web development on it, but that's not so bad. The lack of
| regional support is crippling, because whatever region you
| put me in is ~200ms from me and the typing lag is terrible.
|
| I'd love to adopt this for all my development (which I
| currently do using rented cloud instances, so I'm pretty
| comfortable with the remote development paradigm). I'm
| especially excited about the snapshot/clone pattern, and have
| (this past week) been researching solutions for exactly this
| problem.
|
| Hope you launch multiple regions for this ASAP. Will be
| watching.
| mrkurt wrote:
| If you `sprite console` to it, it'll forward any ports you
| open to localhost. You can tunnel almost everything through
| the CLI with the `sprite proxy` command.
| indigodaddy wrote:
| Do we handle our own certs or do you have a proxy in front of
| the sprites that can do auto ssl stuff?
| tptacek wrote:
| We handle all the SSL stuff. Sprites run on the same
| Anycast network with the same control plane as Fly
| Machines, which are built for srs bzns.
| sheepscreek wrote:
| > 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!
| psanford wrote:
| What is the criteria for a sprite being "idle"? Is it no network
| activity or is it cpu based?
| simonw wrote:
| Looks like it's no network activity for 30 seconds.
| psanford wrote:
| 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/
| psanford wrote:
| To follow up on this a bit, something that I really want is a
| way to build and launch apps from an llm really easily. I am
| imagining and environment with a database, object storage, and
| a publicly reachable webserver. I think this could be that with
| OIDC auth to an s3 bucket and litestream.
|
| I was previously thinking about doing the same thing on my
| homeserver with tailscale to expose the web interface publicly
| and tailscale oidc auth to an s3 bucket for object storage.
| fideloper wrote:
| i believe the .sprite dir has some stuff to help claude answer
| those questions. haven't done it myself but my friend said he
| was able to get claude to set it all up for him (yolo mode
| helps) including connecting to github.
| johnfn wrote:
| 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?
___________________________________________________________________
(page generated 2026-01-10 23:00 UTC)