zlacker

[return to "Fly's Sprites.dev addresses dev environment sandboxes and API sandboxes together"]
1. vivzke+uo[view] [source] 2026-01-10 03:57:03
>>simonw+(OP)
as a guy who is not in loop with all these sandbox developments, I apologize for this extremely stupid question. Why do we need any of these sandboxes? Why cant we use docker? I thought it was a solved problem 10 yrs ago?
◧◩
2. shitco+0v[view] [source] 2026-01-10 05:17:34
>>vivzke+uo
I think one difference is that it also provides the service of being a production environment you can serve from at the same time as development. There's more information about this thought in the fly io blog post.
◧◩◪
3. avsm+Ox[view] [source] 2026-01-10 05:59:24
>>shitco+0v
I just use Docker devcontainers using Anthropic's own Dockerfile as a base, and it gives me a persistent sandbox that have ports opened and work in any container environment (be it remote or local), and work in any IDE that supports devcontainers...

https://anil.recoil.org/notes/ocaml-claude-dev

◧◩◪◨
4. HumanO+cB[view] [source] 2026-01-10 06:45:01
>>avsm+Ox
So what if Claude Code makes a mistake and tears up the sandbox? What happens to all the persisted state (aside from the container image)?

The linked fly.io article discusses why containers aren't a good fit for sandboxes that need persistent state and how sprites.dev addresses the challenges.

[go to top]