Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code and Let Live

fly.io

Post reply on HN
Print view View original

41–50 of 195 posts

Re: Code and Let Live

#41

Post by fideloper »

psanford wrote: post #38

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…

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.

Re: Code and Let Live

#42

Post by dtkav »

tptacek wrote: post #37
dtkav wrote: post #15

Earlier quoted context omitted.

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 (curre…

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.

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?

Re: Code and Let Live

#43

Post by tptacek »

dtkav wrote: post #42
tptacek wrote: post #37

Earlier quoted context omitted.

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.

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?

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.

Re: Code and Let Live

#44

Post by dtkav »

tptacek wrote: post #43
dtkav wrote: post #42

Earlier quoted context omitted.

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?

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.

Great, i look forward to reading it.

Re: Code and Let Live

#45

Post by dang »

simonw wrote: post #6

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.…

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)

Re: Code and Let Live

#46

Post by wmf »

tptacek wrote: post #32
qhwudbebd wrote: post #18

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 he…

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.

Safer from what? It depends whether you're protecting the infra or the data.

Re: Code and Let Live

#47

Post by tptacek »

wmf wrote: post #46
tptacek wrote: post #32

Earlier quoted context omitted.

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.

Safer from what? It depends whether you're protecting the infra or the data.

They're closely linked; protecting the infra is protecting the data.

Re: Code and Let Live

#49

Post by crawshaw »

HumanOstrich wrote: post #11
skybrian wrote: post #3

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

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…

[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.

Re: Code and Let Live

#50

Post by johnfn »

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?

Post reply on HN