Code and Let Live

Original Article ↗ Hacker News Discussion ↗

What Sprites.dev Provides

  • Described as fast-starting, fast-pausing persistent VMs that scale to zero, with durable storage and an API for executing commands.
  • Mental model: “disposable computers” you can create in seconds, keep around sleeping, and restore via checkpoints (VM-level snapshots of disk + memory).
  • Positioned as especially well-suited to AI code agents: you can let them “go wild” in an isolated, persistent environment and roll back if needed.

Comparison to Existing Tools

  • Similarities drawn to EC2, DigitalOcean VPS, Cloudflare containers, exe.dev, container-use, LXC/Incus, libvirt, and Docker.
  • Distinguishing features emphasized in the thread:
    • Near-instant creation + auto scale-to-zero.
    • First-class checkpoint/rollback semantics at VM granularity.
    • Full-VM isolation vs containers sharing a kernel, for untrusted code.
    • Built-in tooling (e.g., preconfigured AI agent, routing, HTTPS).
  • Some argue local VMs/containers (libvirt, LXC, Incus) already cover similar workflows; others prefer managed, elastic cloud over maintaining personal infra.
  • A local/open-source Rust implementation of the same UX is mentioned as “coming.”

Use Cases and Workflows

  • Developer sandboxes for AI agents (Claude Code, Codex, etc.) with persistent state but constrained blast radius.
  • “Sandbox API” for running untrusted user code via JSON calls, then rolling back to a clean checkpoint.
  • CI/CD runners launched per job, preview environments, and quick experiment environments (“when in doubt, make another one”).
  • Personal or small apps needing cheap, durable backends (e.g., SQLite-backed sites, personal MDM-like tools).
  • Production workloads are generally advised to stay on Fly Machines; Sprites are framed as exploratory/dev infrastructure.

Architecture, Security, and Performance

  • Under the hood: KVM VMs; Firecracker is mentioned in the marketing, and users speculate about virtio devices and a copy-on-write storage stack, possibly JuiceFS-based, but details are deferred to a promised follow-up post.
  • Debate over whether storage stack should live inside or outside the VM for safety; consensus that VM isolation is stronger than containers for untrusted code.
  • Idle behavior: primarily network-activity-based; open consoles or exec sessions keep Sprites awake.

Pricing, Limits, and Reliability

  • Billing model: pay for compute while active; storage billed on used GB, not allocated capacity; idle Sprites mostly cost only storage.
  • Questions and concerns about:
    • Concurrent Sprite limits (3 on PAYG, 10 on a higher tier) and suitability for high-concurrency use.
    • Lack of clear spending/usage visibility and per-Sprite limits.
    • Fly’s broader history of API flakiness, billing issues, and support responsiveness; some users explicitly warn against relying on this for critical workloads.

DX, Documentation, and Rough Edges

  • Strong enthusiasm for the core UX and concept, especially checkpoints and “no-brain” environment creation.
  • Early friction points:
    • Quickstart API example missing content-type, causing initial failures.
    • Installer/auth commands hanging for some users.
    • Confusion about GitHub auth, OIDC, and available in-VM APIs.
    • Region lock-in leading to high latency for remote terminals.
    • Environment leakage (e.g., $SHELL, locale) from local machine into Sprite causing odd states and potential sensitivity concerns.
  • Feature requests include: GPU Sprites, custom base images/minimal images, Sprite cloning/forking (acknowledged as coming), cron-like wakeups, stricter network egress control, mobile/Termux CLI, and Vercel-style authenticated preview URLs.