Berry Wiki

Fly.io Sprites

Properties2
tagsai, hosted
aliasesFly Io Sprites

8 min read

Fly.io Sprites

Checked: 2026-07-14

Summary

Fly.io Sprites is a hosted service for persistent, hardware-isolated Linux environments. A Sprite behaves like a small cloud development machine: its files and installed software remain between sessions, while compute sleeps when idle and wakes on a command or HTTP request.

It targets coding agents, untrusted code, remote development environments, long-lived low-traffic services, and CI tasks.

Problem

Coding agents need shell access and freedom to install and run software, but giving that access on a developer laptop exposes personal files, credentials, and the local network. Containers reduce accidental damage but share the host kernel. Building and operating stronger virtual-machine isolation, persistence, networking, and rollback is extra work.

Sprites moves this work to Fly.io’s hardware and gives each agent a separate Linux machine with managed persistence and networking.

How It Works

  • Each Sprite is a dedicated microVM, not merely a container.
  • It has a persistent ext4 filesystem. Active data uses NVMe storage; idle data is backed by durable object storage.
  • A Sprite becomes warm when idle and may later become cold. Idle compute is not charged. A later command or HTTP request wakes it.
  • Commands run through the CLI, REST API, software development kits, or Sprites’ remote MCP server.
  • Services can run in the background and wake on inbound HTTP requests.
  • Checkpoints capture the filesystem for rollback. Restoring replaces later filesystem changes.
  • Each Sprite currently has 100 GB of persistent storage according to the working guide.

Security and Isolation Boundary

  • Official documentation describes hardware-level isolation through a dedicated microVM.
  • This is a stronger boundary than a normal container because the guest does not share the host operating-system kernel.
  • The Sprite is remote from the developer’s laptop and home network. This reduces the damage if an agent or downloaded package becomes hostile.
  • Isolation does not make agent actions harmless. An agent can still destroy its Sprite, alter files, call allowed network services, or use credentials granted to it.
  • A Sprite URL is private to organization members by default. Public mode has no Sprites authentication and needs application-level protection for real services.
  • Unknown: the reviewed public overview does not provide a full threat model, independent security audit, compliance claims, or a promise that VM escape is impossible.

Platforms and Agents

  • Sprite CLI: macOS, Linux, and Windows, including x86-64 and ARM64 builds.
  • Guest: currently Ubuntu 25.10. Older Sprites may need an in-place operating-system upgrade or replacement.
  • Preinstalled agent tools: Claude CLI, Gemini CLI, OpenAI Codex, and Cursor.
  • Preinstalled languages include Node.js, Python, Go, Ruby, Rust, Elixir, Java, Bun, and Deno.
  • Remote MCP support lets compatible clients create and manage Sprites. Restricted tokens can limit names and the number of Sprites an MCP client may create.

Setup and Workflow

  1. Install the sprite CLI using the official install script or a checksum-verified binary.
  2. Authenticate with a Fly.io account using sprite org auth.
  3. Create and select a Sprite with sprite create <name> and sprite use <name>.
  4. Run one-off commands with sprite exec, or open an interactive shell with sprite console.
  5. Clone a repository and run the preferred coding agent inside the Sprite.
  6. Create a checkpoint before risky work. Restore it if the agent damages the environment.
  7. Destroy the Sprite when it is no longer needed; destruction is permanent.

The official install page showed CLI version v0.0.1-rc45 on 2026-07-14. The rc label means release candidate, not a final 1.0 release.

Network and Credentials

  • Inbound: every Sprite receives an HTTPS URL. It is organization-private by default and can be made public.
  • Local access: sprite proxy maps Sprite ports to localhost and supports any TCP traffic. Direct SSH is not exposed; SSH can be installed and tunneled through the proxy.
  • Outbound: unrestricted by default. An optional DNS-based policy can allow or deny domains, block raw-IP bypasses, block private IP ranges, and drop existing connections when a policy tightens.
  • Network policy is read-only inside the Sprite and changed from outside through the API.
  • Connectors: Fly.io can store an external service token centrally and proxy calls to Slack, GitHub, OpenRouter, or a custom API. The Sprite receives no raw provider token.
  • Connector access is deny-by-default until policy grants specific Sprites and provider paths.
  • Organization tokens and the active Sprite selection are stored by the local CLI in ~/.sprites/sprites.json.
  • Credential brokering is useful, but any credential placed directly inside the Sprite remains visible to processes with sufficient access inside that Sprite.

Pricing

Official public rates checked 2026-07-14:

ResourceRate
CPU time$0.07 per CPU-hour
Memory time$0.04375 per GB-hour
Hot storage$0.000683 per GB-hour
Cold storage$0.000027 per GB-hour

Billing is based on actual hourly resource use. Compute is free while idle, but stored data continues to cost money. The official example estimates a four-hour Claude Code session at $0.44, based on its stated average usage. Actual cost depends on agent behavior and stored data.

Unknown: no current official spending-cap guarantee was found in the reviewed pages. Confirm account limits before unattended large-scale use.

Strengths

  • Stronger isolation than ordinary containers and separation from the laptop and home network.
  • Persistent development state without maintaining a personal cloud server.
  • Sleep-on-idle lowers the cost of intermittent agent work.
  • Full Linux environment with common agents and toolchains already installed.
  • Checkpoints support recovery before risky agent actions.
  • Built-in private HTTP URL, TCP proxy, network policy, REST API, and MCP access.
  • Connectors keep supported third-party credentials outside the guest.

Limits and Risks

  • It is a hosted Fly.io service, so work depends on Fly.io availability, account access, pricing, and product continuity.
  • Outbound network access is open unless the user explicitly applies a policy.
  • Making the Sprite URL public removes Sprites authentication.
  • Persistent machines also preserve stale packages. Users must maintain the operating system and bundled tools.
  • Checkpoint restore discards work done after the checkpoint; destruction has no undo.
  • Official guidance says SSH and file transfer require extra setup through a proxy or filesystem mount.
  • The CLI still carries a release-candidate version. Fly.io community posts in 2026 reported rough edges, service failures, filesystem concerns, and outdated operating-system images. These reports are not proof that every Sprite is unreliable, but they argue against treating it as mature infrastructure without testing.
  • Fly.io staff stated in June 2026 that development was active but focused on fundamental storage work, while its software development kits were underloved because many users call the API directly.

Activity and Maturity

  • Active but pre-1.0: official docs and features were current in July 2026, while the CLI version remained v0.0.1-rc45.
  • Documentation covers checkpoints, services, network policy, connectors, APIs, and remote MCP.
  • A Fly.io staff reply on 2026-06-11 said Sprites development was not dormant and that storage work was underway.
  • The public community shows real use alongside stability and maintenance complaints.
  • Practical reading: suitable for experiments and individual agent work after testing; evaluate reliability, recovery, limits, and support before team-critical use.

Best Fit

  • Developers who want Claude Code, Codex, Cursor, or Gemini to work freely without access to their laptop.
  • Persistent, remote agent workspaces that should sleep between tasks.
  • Running untrusted or generated code behind a microVM boundary.
  • Agent fleets controlled through a REST API or MCP.
  • Small web services that benefit from automatic wake-up and persistent disk.

It is less suitable when work must remain entirely local, must run without a third-party dependency, needs mature enterprise guarantees not documented publicly, or requires unrestricted low-latency access to a private local network.

Comparison Facts

FactFly.io SpritesClawk
LocationFly.io hardwareDeveloper-controlled local machine
IsolationDedicated microVMLocal VM using platform virtualization
Laptop and home-network exposureRemote by designVM is adjacent to the laptop; Clawk adds network controls
PersistencePersistent filesystem with automatic sleepDisposable project VMs with suspend/resume workflow
AgentsClaude, Codex, Gemini, Cursor preinstalledAgent-agnostic local VM workflow
NetworkPrivate/public URL, local proxy, optional outbound policyPort forwarding and allow-list described by the OP
CredentialsOrg tokens and optional brokered connectorsProject-specific credential workflow; verify in Clawk documentation
CostMetered hosted serviceUses local hardware; no hosted compute charge
Offline/self-hostedNoYes, after local dependencies are available

Hacker News Context

In the Clawk discussion, bad_haircut72 said Fly.io Sprites already does this well and has Claude preinstalled. A reply by whitlock said the core abstraction is the same: give a coding agent a real Linux machine with a firm network and isolation boundary. The reply argued that Sprites may have the better security boundary because the agent is not next to the user’s laptop and home network.

Another commenter later described Sprites as a similar idea hosted on Fly.io hardware, with a public or private domain, and said their experience had been good.

These comments identify the main tradeoff: Sprites buys remote managed isolation; Clawk keeps control and execution local. The HN claims are user opinions, not independent security proof.

Sources

Graph View