Fly.io Sprites are the leading Northflank alternative for secure AI code execution: a Firecracker microVM per agent, a persistent 100 GB disk, filesystem checkpoints you can roll back to, and billing on measured usage that stops the moment the agent goes idle. Northflank is the better choice if you need a GPU inside the sandbox or must run in your own cloud account. This page covers both, and the five other platforms teams usually shortlist.
Northflank and Fly.io Sprites are both places to run AI-generated code in hardware isolation, and that is roughly where the resemblance ends. Northflank is a Kubernetes-based platform that runs sandboxes as one workload type among services, databases and cron jobs, either on Northflank’s cloud or inside your own AWS, GCP or Azure account. A Sprite is a persistent Linux computer for an agent: a Firecracker microVM with 100 GB of ext4, filesystem checkpoints, a private HTTPS URL, and a lifecycle that pauses when idle and wakes on the next request. If you are choosing between them for secure AI code execution, the decision turns on whether you want to operate a platform or hand an agent a machine.
Key takeaways
- A Sprite boots a full Ubuntu 26.04 development image with Node, Python, Go, Ruby, Rust, Java and Elixir installed, plus Claude Code, Codex, Cursor and Gemini CLI. Docker runs inside it as a supervised service, so any OCI image runs there too.
- Every Sprite is a Firecracker microVM with its own kernel. Firecracker and Kata Containers are the same class of hardware boundary; gVisor, the third runtime Northflank offers, shares the host kernel and is the weaker of the three.
- Northflank bills the vCPU and RAM you configure for as long as the instance exists. A Sprite bills the CPU, RAM and storage it measured while active, and nothing but storage while paused.
- Sprites are driven through a REST API, an MCP server and SDKs in four languages, with plans that scale to hundreds of concurrently running Sprites and 240 creations per minute.
- Northflank is the better choice if you need GPUs inside the sandbox or must run in your own cloud account. Sprites do neither today.
Northflank vs Fly.io Sprites at a glance
| Dimension | Northflank | Fly.io Sprites |
|---|---|---|
| Isolation | Kata Containers with Cloud Hypervisor, gVisor, or Firecracker, chosen per workload | Firecracker microVM, always |
| What a sandbox boots from | Any OCI image | A full Ubuntu 26.04 dev image with runtimes and coding agents preinstalled |
| Running containers inside | Yes, it is the unit of deployment | Yes, Docker runs inside a Sprite as a supervised service |
| Billing basis | Configured vCPU and RAM, prorated to the second | Measured CPU, RAM and storage while active; sleeping costs storage only |
| Idle behaviour | Runs until stopped or scaled to zero | Pauses after about 30 seconds idle, wakes on the next request |
| Point-in-time rollback | Persistent volumes | Copy-on-write filesystem checkpoints, manual and automatic |
| Inbound URL | Per service | Per Sprite, private to your org by default, public on request |
| Egress control | Platform-level | DNS-based allowlist, read-only from inside the Sprite |
| GPUs in the sandbox | L4, A100, H100, H200 | No |
| Run in your own cloud | Yes, BYOC on AWS, GCP, Azure or bare metal | No |
| Compliance | SOC 2 compliance tooling | SOC 2 Type 2 |
What is Northflank?
Northflank is a platform-as-a-service built on Kubernetes that deploys services, jobs, databases and isolated sandboxes from OCI container images. The product’s distinguishing feature is where it runs: on Northflank’s managed cloud, or as a Kubernetes cluster inside your own AWS, GCP, Azure or bare-metal account under its “Bring Your Own Cloud” model. Sandboxes can be scheduled onto Kata Containers backed by Cloud Hypervisor, onto gVisor, or onto Firecracker, and GPU nodes are available for sandboxed workloads at an all-inclusive hourly rate.
Its pitch to teams running AI code is completeness. The same control plane that runs the sandbox runs the API in front of it, the Postgres behind it, and the CI pipeline that built the image. That is a real strength if you want one vendor for the whole stack and a real cost if you only wanted somewhere safe to run an agent.
What are Fly.io Sprites?
A Fly.io Sprite is a hardware-isolated, persistent Linux computer for running arbitrary code, from a coding agent to a user-uploaded binary. Each one is a Firecracker microVM with 8 vCPUs, memory the platform sizes and grows under pressure, and 100 GB of ext4 backed by a local NVMe cache and durable object storage. A Sprite is active while something is using it, pauses after roughly 30 seconds of idle, and wakes in 100 to 500 milliseconds from a warm state or one to two seconds from cold. Its filesystem is the same on every wake.
Around that machine sit the pieces an agent workload needs: checkpoints that snapshot the writable filesystem and roll it back, services that the runtime restarts after a crash or a cold wake, a private HTTPS URL that wakes the Sprite on an inbound request, a DNS-based egress policy, and Connectors that let code call external APIs without holding the credential. You drive all of it from a CLI, a REST API, an MCP server, or SDKs for JavaScript, Go, Python and Elixir.
What does a Sprite boot from?
A Sprite boots a full Ubuntu 26.04 development image, not a bare Linux box, and it is never rebuilt between sessions. Northflank sandboxes boot from an OCI image you supply. The two models are different, and each is a deliberate choice.
What is in the image
A new Sprite carries Node.js 24, Python 3.13, Go 1.25, Ruby 3.4, Rust 1.90, Java 25 and Elixir 1.19 with Erlang/OTP 28, plus Bun and Deno, the GitHub CLI, and the crun OCI runtime. It also ships four coding agents ready to run: Claude Code, Codex, Cursor CLI and Gemini CLI. Most agent work needs nothing installed before it starts, and anything it does install stays on the disk for every subsequent wake.
Running containers inside it
A Sprite is a computer, and a computer can run Docker. The in-Sprite documentation walks through it: install docker.io with apt, set the overlay2 storage driver, and register dockerd as a Sprite service so the runtime brings it back after a cold wake. From that point any OCI image from Docker Hub, GitHub Container Registry or a private registry runs inside the Sprite the way it would on a laptop. What a Sprite does not do is boot from your image. Fly.io skips the image pull so a Sprite comes up in about a second, and its state lives on a persistent disk rather than in an immutable layer.
Never starting over
Install a toolchain once, take a checkpoint, and every wake of that Sprite lands on the same filesystem. There is no environment to reconstruct, because the environment was never torn down.
Is Firecracker weaker isolation than Kata Containers or gVisor?
No. A menu of runtimes is not a stronger boundary than one runtime, and one item on Northflank’s menu is weaker than the others.
Firecracker is a virtual machine monitor written in Rust, originally built by AWS to run Lambda and Fargate, and it gives each workload its own guest kernel on hardware virtualization. Kata Containers with Cloud Hypervisor does the same thing with a different monitor: a container-shaped interface over a lightweight VM. Those two are the same class of boundary, and both are a step above container-only isolation.
gVisor is the outlier. It is a user-space kernel that intercepts syscalls from a container and reimplements them, so the container never talks to the host kernel directly. That is a meaningful hardening over a plain container, but the workload still shares the host’s kernel process and CPU, and the gVisor project documents the compatibility gaps and performance cost that come with intercepting every syscall. Offering gVisor as an option is fine. Picking it by mistake for untrusted code is not.
Every Sprite gets a dedicated kernel, every time, with no per-workload decision to get wrong. Fly.io’s platform is SOC 2 Type 2, its tenants never share kernels, and the isolation is tested by outside firms including Atredis Partners, Doyensec and Tetrel.
Isolation is a tie, with one difference in defaults. A Sprite’s outbound network is unrestricted until you apply an egress policy. Once applied, the policy is read-only from inside the Sprite, raw IP connections to hosts that were not resolved through the allowlist are dropped, private IP ranges are always blocked, and a tightened rule kills existing connections rather than leaving them open. Turn it on for anything running untrusted code.
How does the pricing compare?
Northflank’s per-unit rates are lower and its billing basis is different, and the second fact matters more than the first for agent workloads.
The rates
| Northflank | Fly.io Sprites | |
|---|---|---|
| CPU | $0.01667 per vCPU-hour | $0.07 per CPU-hour |
| RAM | $0.00833 per GB-hour | $0.04375 per GB-hour |
| Storage | Per volume | $0.000683 per GB-hour hot cache, $0.000027 per GB-hour durable, on bytes written |
| Billed on | Configured resources, per second | Measured usage while active |
A four-hour coding session
Configure a Northflank instance with 2 vCPU and 4 GB of RAM for a four-hour session and you pay for 2 vCPU and 4 GB for four hours: $0.13 for CPU and $0.13 for memory, $0.27 in all, whether the agent inside is compiling or waiting on a model response. Northflank bills on configured resources and instances, prorated to the second.
The same session in a Sprite is Fly.io’s own published example. A coding session is bursts of work between long pauses while the model thinks, so it averages about 30 percent of two CPUs. That comes to 2.4 CPU-hours at $0.17, 6 GB-hours of memory at $0.26, and a cent of storage: $0.44. The Sprite costs more for those four hours, and the number is what the Sprite actually used rather than what someone provisioned.
What happens after the session
Then the session ends. A Northflank instance keeps billing until you stop it or scale it to zero. A Sprite pauses on its own about 30 seconds after the last activity, compute billing stops, and the only charge that continues is storage on the bytes actually written. Nothing is charged per Sprite. Ten projects in ten Sprites cost the storage of ten projects and the compute of the one you are working in, and an agent fleet that runs one task an hour pays for the minutes of the task.
Sustained, predictable workloads favour a provisioned model with lower unit rates. Intermittent workloads favour measured usage with a pause. Agent workloads are the intermittent kind.
Are Sprites built for teams or for individual developers?
Both. A single developer can run one Sprite from the CLI, and an orchestrator can run hundreds through the API, because the product is the same API-first fleet in both cases.
Every Sprite operation is available over the REST API at api.sprites.dev, through an MCP server with OAuth 2.1 that agents and IDEs connect to directly, and through official SDKs for JavaScript, Go, Python and Elixir. There are official plugins for the major coding agents and an adapter that registers a Sprite as a sandbox provider for the OpenAI Agents SDK. Sprite URLs are private to an organization by default, so a service an agent stands up is reachable by your team and nobody else until you flip it public.
The plans are sized for fleets. Hero, at $100 a month, allows 100 concurrently running Sprites with 100 more warm, and the ceiling rises through Champion, Legend, Epic and Mythic, where the creation rate reaches 240 Sprites per minute. Cold Sprites are unlimited on every tier. Email support is included from Hero upward. This is the shape of a platform for orchestrators that spin up a worker per task.
Where Northflank is ahead is enterprise administration. It lists SSO, RBAC and audit logging as platform features, and Sprites’ access model today is organization tokens and organization membership. If you need per-user roles inside the sandbox product itself, ask before you commit.
Are persistent volumes the same as checkpoints?
No. A persistent volume keeps the current state of a disk. A checkpoint lets you get a previous state back. Sprites have both; Northflank sandboxes have the first.
Every Sprite’s disk survives pauses without anyone asking, which is persistence. A checkpoint is a copy-on-write snapshot of the writable filesystem at one moment, taken without interrupting the Sprite, that you can restore later to roll the disk back to exactly that point. The workflow it enables is the one agent operators actually want: checkpoint, let the agent attempt the dependency upgrade or the destructive refactor unattended, and restore if it went wrong. Agents can take and restore their own checkpoints from inside the Sprite, and the platform takes automatic ones after a stretch of continuous work, on idle and on graceful shutdown, so there is a safety net even when nobody remembered to save.
A volume gives you the state as it is now. It does not give you the state as it was before the agent started, and that is the property that makes unattended runs safe to allow.
Where Northflank is the better tool
Two things Northflank offers matter for some teams, and Sprites do not offer either.
GPUs inside the sandbox. Sprites are CPU-only. Northflank offers L4, A100, H100 and H200 GPUs with the same isolation and API as its CPU sandboxes, at all-inclusive hourly prices. Fly.io has GPU Machines, but they are a separate product with their own image-based deployment, not a Sprite with a GPU attached. If the code the agent runs needs CUDA, Northflank is the closer fit today.
Running in your own account. Sprites run on Fly.io’s infrastructure only. Northflank will run its control plane against a Kubernetes cluster in your AWS, GCP or Azure account, which is what a data-residency requirement or a large committed-spend contract sometimes demands. The trade is that you are now operating a cluster: the nodes, their bills and their availability zones are yours.
If neither of those applies, the remaining reason to prefer Northflank is that it also runs your database and cron jobs. Fly.io does too, on Machines, and an agent that built something in a Sprite deploys it there without a rewrite because both run on the same Firecracker substrate.
The other Northflank alternatives
Five other platforms usually make the shortlist for secure AI code execution. Fly.io has compared Sprites with each of them directly.
- Fly.io vs E2B: the same Firecracker isolation, but E2B caps continuous runtime at 24 hours and its pause costs about four seconds per gigabyte of RAM.
- Fly.io vs Modal: Modal runs on gVisor and defines images from a Python SDK, which suits ML inference and fits agent sandboxes less well.
- Fly.io vs Daytona: Daytona starts in milliseconds from warm pools, but its documentation does not name the isolation technology, its default disk is 3 GiB, and sandboxes auto-stop after 15 minutes and archive after 7 days.
- Fly.io vs Vercel: Vercel Sandbox is Firecracker with a session cap of 24 hours on Pro and 45 minutes on Hobby, and it is not designed to run continuously.
- Fly.io vs Cloudflare: the Cloudflare Sandbox SDK sets no lifetime cap either, but its container disk is ephemeral and starts fresh after every sleep, where a Sprite’s 100 GB persists.
Secure AI code execution on Fly.io
Give an agent a Sprite and it gets a real computer with a hardware boundary around it, not a container with a timeout. Create one with sprite create, or with a single API call from your orchestrator, and the agent has 8 vCPUs, a persistent 100 GB disk, and the runtimes and coding agents it needs already installed. Restrict its egress to an allowlist before it runs anything you did not write. Take a checkpoint, let it work, and restore if the run went sideways. Hand it credentials for GitHub, Slack, OpenRouter or any HTTP API through a Connector, so the key never sits on the Sprite’s disk for the agent’s code to read.
When the agent finishes, the Sprite pauses and compute billing stops. When a webhook, a chat message or the next task arrives at its URL, it wakes with its filesystem exactly as it left it. You pay for the seconds it worked and the bytes it kept.
Frequently asked questions
Can Fly.io Sprites run Docker containers?
Yes. A Sprite is a full Linux machine, so you install Docker with apt, register the daemon as a Sprite service so it survives cold wakes, and run any OCI image from any registry inside it. A Sprite does not boot from your image the way a Northflank sandbox does; it boots a preinstalled Ubuntu development image in about a second and your containers run on top.
Is Firecracker less secure than Kata Containers?
No. Both run each workload in its own lightweight virtual machine with a dedicated guest kernel on hardware virtualization, which is a step above container-only isolation. Fly.io Sprites use Firecracker for every Sprite, so there is no per-workload isolation setting to choose incorrectly.
Is gVisor as strong as a microVM?
No. gVisor is a user-space kernel that intercepts a container’s syscalls, which hardens a container but still shares the host kernel with every other tenant. A Fly.io Sprite runs on a Firecracker microVM with its own kernel, which is the boundary that separates tenants at the hardware level.
Is Northflank cheaper than Fly.io Sprites?
Northflank’s per-unit rates are lower, and it bills the resources you configure for as long as the instance exists. Fly.io Sprites bill measured usage only while active and charge nothing but storage while paused, so a sustained workload favours Northflank’s model and an intermittent agent workload favours Sprites.
Do Fly.io Sprites bill while idle?
No compute is billed while a Sprite is paused. Fly.io meters CPU, RAM and hot storage only while a Sprite is active, and a paused Sprite is charged for the durable storage it uses, measured on bytes written rather than the 100 GB allocation. Bandwidth is not metered at all.
Are Fly.io Sprites only for Claude Code?
No. Claude Code is preinstalled alongside Codex, Cursor CLI and Gemini CLI, and Fly.io Sprites are driven through a REST API, an MCP server and SDKs for JavaScript, Go, Python and Elixir, with official plugins for the major coding agents. Plans scale to hundreds of concurrently running Sprites for orchestrators that run one agent per Sprite.
Do Fly.io Sprites support GPUs?
No. Sprites are CPU-only, with 8 vCPUs each. Fly.io offers GPUs on Fly Machines, which are a separate image-based product, so a workload that needs CUDA inside the sandbox itself is one of the two cases where Northflank is the closer fit.
Can I run Fly.io Sprites in my own AWS or GCP account?
No. Fly.io Sprites run on Fly.io’s own bare-metal infrastructure, and there is no bring-your-own-cloud option. Northflank does offer that, at the cost of operating the Kubernetes cluster it runs on.
Does a persistent volume replace checkpoint and restore?
No. A persistent volume keeps the current state of a disk, which Fly.io Sprites also do automatically across pauses. A checkpoint is a copy-on-write snapshot you can roll back to, taken by you or automatically by the platform, so an agent’s failed run can be undone rather than merely preserved.
Is Fly.io SOC 2 compliant?
Yes. Fly.io is SOC 2 Type 2, its tenants never share kernels, and its isolation is tested by outside security firms. Sprites run on that same platform, so an agent’s code executes inside a Firecracker microVM with a dedicated kernel on every run.