>Any time anybody needs a pen, several are at hand, in exactly the first place they look. >Now, today, under the hood, Sprites are still Fly Machines. But they all run from a standard container. So its basically a faster VM? What are some use cases for this that benefit from the faster boot time?
> some use cases for this that benefit from the faster boot time
Faster create times. Sprites create (including booting up) in a second or two, per TFA.
One usecase for Sprites I see are disposable dev boxes (like for rapid prototyping with Coding Agents).
Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on…
They're an interesting middle ground between pure ephemeral dev environment and production environment. If your audience is the whole Internet, a Sprite won't scale today to serve it. But for most of the apps I'm building, the Sprite is actually fine for the foreseeable future. There's a ton of security automation stuff we're doing that a Sprite keeps up just fine with; the sandwich bracket I'm running downthread is…
> ton of security automation stuff we're doing that a Sprite keeps up
Hm. The sprites.dev webpage goes,
Sprite is a hardware-isolated execution environment ... Sprites execute code in Firecracker VMs. Even we have a hard time seeing what they're doing.
Any plans for Fly.io to support CCA / TDX / SEV-SNP?
Yeah. My sprites never idled inspite of having nothing running in them and had to be destroyed. Ideally there should be two settings 1. A timeout after the last console session is exited 2. Force idle using the CLI
Just tried it again. Creation took a very long time, then errored. $ sprite version sprite version v0.0.1-rc30 $ sprite create quk Error creating sprite: failed to create sprite: Post "https://api.sprites.dev/v1/sprites": context deadline exceeded (Client.Timeout exceeded while awaiting headers) But despite the error, the sprite was apparently created, and it runs continuously. $ sprite ls Sprites in organization : ┌…
Get a console in your sprite. Run “screen”. Run a loop in there : while date; do sleep 1; done. Detach screen and exit the session. Wait a few minutes and go back into the sprite. Reattach screen. You’ll see a gap in the timestamps.
They do suspend even when they say they are “running”.
I've been working on the orchestrator side with Elixir and Phoenix, so happy to continue the discussion for curious minds. One of the coolest things we can do is things like this in Elixir - from any node we can reach out to a sqlite db across the planet: OrgTracker.with_repo(org_id, fn -> repo.all(from sprite in "sprites", select: ...) end) That will find or place an Elixir process on the cluster and rpc the target…
(Disclaimer: Newbie checking but still curious). Are you using libluster or Distributed Erlang to reach the clusters? Or just simple networking over the Fly network. > That will find or place an Elixir process on the cluster and rpc the target node with our code. Is this similar to what you did with Flame? Or just a refinement of that idea.
We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc, ie `:erpc.call` underneath rather than FLAME where we are managing a pool of elastic nodes, then rpc'ing them.
I appreciate the Fly.io team’s enthusiasm and am optimistic this will mature into a product I’d pay for, but my initial impression was of a lack of polish. Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result ( https://docs.sprites.dev ). Blog posts and forum threads and Claude skills…
You're not wrong. The documentation actually had a hallucinated link to an Anthropic dependency in it when we shipped. Right now the attitude is mostly "if we have to document it extensively, we're doing something wrong". It's been in the works for awhile , with a small team, and we're just getting it out there right now. I've been needling Kurt for several months now that if we wait until it's polished enough that w…
The main things i think are missing is (1) how much am i spending and (2) why isn't my sprite paused, and (3) how can i get my stuff out (it would be nice to be able to mount in either direction or else integrate with git/git worktrees).
I ended up using it (and enjoying yolo mode!) but then my sprites weren't pausing and i was worried about spending too much so i deleted them.
I hate being negative but it sounds like par for the course for fly. Incredible (truly, incredible, world-class) engineers that somehow lack that final 10% of polish/naming/documentation that makes things...well, seriously usable. I remember last time I tried them the bizarre hoops/documentation around database creation. I _think_ they solved that but I remember at the time it felt almost like I was getting looked do…
(Disclaimer: Newbie checking but still curious). Are you using libluster or Distributed Erlang to reach the clusters? Or just simple networking over the Fly network. > That will find or place an Elixir process on the cluster and rpc the target node with our code. Is this similar to what you did with Flame? Or just a refinement of that idea.
We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc…
Thanks for the reply. Summary: Here's this really cool thing we're doing! Oh, are you wrote something exotic for it? Nope, just regular Erlang goodness that's been around 20 years.
What I missed when trying it was a simple way of accessing private repositories. There does not seem to be ssh agent forwarding, or is there? What do people use? I realize this is all very fresh, but still wondering…
Did you ever find an answer? Other than copy/pasting my priv/pub keys into ~/.ssh/ I'm not sure.
Very cool product, but I have to ask, out of personal interest: What did the bracket in the slack channel determine was “Chicago’s best sandwich”? Or the top three, even? I’m always looking for new sandwiches. Off the top of my head, I might nominate, - the pork tenderloin at JT’s - the Big L from Fontano’s (hot take, I know; it might go to Graziano’s if they hinge-cut the bread, but not doing so is a fatal flaw to m…
It's too early to say. We started the bracket back in 2020 with a nomination Google Sheet, and then the pandemic happened, and then I kept saying I'd throw a web app together for us to actually do a seeded bracket with; 5 years later, some of the restaurants have changed, so we're re-doing nominations, and we'll have bracket voting rounds starting probably in February. I owe it all to Sprites! Nhu Lan's Banh Mi #1 an…
I love this bracket. The first startup I worked (Triggr Health) at was in Chicago and we started a bracket for best wings. Sadly we never finished!