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

31–40 of 195 posts

Re: Code and Let Live

#31

Post by realty_geek »

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 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!!!

Re: Code and Let Live

#32

Post by tptacek »

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.

Re: Code and Let Live

#33

Post by mrkurt »

CGamesPlay wrote: post #28
mrkurt wrote: post #26

Earlier quoted context omitted.

sprite url update --auth public It requires your api token by default.

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

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.

Re: Code and Let Live

#35

Post by indigodaddy »

mrkurt wrote: post #26
CGamesPlay wrote: post #25

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?

sprite url update --auth public It requires your api token by default.

Do we handle our own certs or do you have a proxy in front of the sprites that can do auto ssl stuff?

Re: Code and Let Live

#36

Post by tptacek »

indigodaddy wrote: post #35
mrkurt wrote: post #26

Earlier quoted context omitted.

sprite url update --auth public It requires your api token by default.

Do we handle our own certs or do you have a proxy in front of the sprites that can do auto ssl stuff?

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.

Re: Code and Let Live

#37

Post by tptacek »

dtkav wrote: post #15
tptacek wrote: post #14

Earlier quoted context omitted.

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/

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.

Re: Code and Let Live

#38

Post by psanford »

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/

Re: Code and Let Live

#39

Post by psanford »

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…

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.

Post reply on HN