Best persistent sandbox platforms for AI agents (2026)
A comparison of the best persistent sandbox platforms for AI agents in 2026, covering how persistence works on each platform, GPU support, BYOC, and which use cases each fits.
Persistent sandboxes have moved from a niche requirement to something a lot of production AI agent teams are actively evaluating. The reasons are practical: agents that build up a working environment incrementally, maintain a filesystem between executions, or run long-horizon tasks need somewhere to keep state. Ephemeral-only platforms force you to engineer around that.
The platforms covered here approach persistence differently. Some keep filesystem state via volumes. Some offer full pause/resume including memory. Some are purpose-built for sandboxing; others are full workload runtimes. This article covers what each platform actually does so you can evaluate them against your specific requirements.
If you're new to the concept, what are persistent sandboxes covers the fundamentals before you get into platform comparisons.
- Persistence models vary significantly across platforms: filesystem-only, full memory/process pause-resume, and snapshot-based approaches all exist and have different tradeoffs.
- The right platform depends on what your agent actually needs to persist, how long it needs to run, and where your code needs to execute.
- No single platform is best for every use case.
- Northflank is the only platform here that supports both persistent and ephemeral environments, full workload orchestration (agents, APIs, workers, databases), bring your own cloud (BYOC) deployment across your own cloud accounts, on-premises, and bare metal infrastructure, GPU access, and SOC 2 Type 2 compliance, all self-serve. It has been in production since 2021 across startups, public companies, and government deployments.
Not all persistent sandboxes work the same way under the hood, and the differences matter when you're building production agent workflows.
- What actually persists? Some platforms persist only the filesystem. Others persist filesystem and memory including running processes. Others use snapshots to create new environments from a saved state. These are meaningfully different capabilities.
- Is there a session time cap? Some platforms impose a continuous runtime limit before you have to pause. Others run indefinitely until you terminate the environment.
- What's the isolation model? MicroVM-based isolation (Firecracker, Kata Containers) and user-space kernel sandboxing (gVisor) offer different tradeoffs between security, performance, and compatibility.
- Do you need GPU access? Not all sandbox platforms support GPU workloads. If your agents run inference or training, this narrows the list.
- Can you deploy in your own infrastructure? If your organisation has data residency or compliance requirements, bring your own cloud (BYOC) support is a hard requirement.
- Is it just sandboxes, or a full platform? Some platforms only run code execution. Others let you run agents, APIs, databases, and workers alongside sandboxes without stitching together separate services.
The platforms below cover the main options for teams evaluating persistent sandbox infrastructure today. Each takes a different approach to persistence, isolation, and deployment.
Northflank is a full workload runtime that supports both persistent and ephemeral sandbox environments as first-class options, built for teams running production AI platforms.
How persistence works: Persistent environments are stateful services backed by persistent volumes. Filesystem state survives between executions. Volumes start at 4GB and scale to 64TB with multi-read-write support. You can attach S3-compatible object storage and deploy stateful databases (Redis, Postgres, MySQL, MongoDB) alongside sandboxes. No forced session time limit.
Key Northflank offerings:
- Environments: Both persistent and ephemeral, configured per workload
- Isolation: MicroVM-based, including Kata Containers, Firecracker, and gVisor, depending on workload
- BYOC: Self-serve deployment across AWS, GCP, Azure, Oracle, Civo, CoreWeave, on-premises, and bare metal
- GPU: On-demand, self-service provisioning, no quota requests
- Access: API, CLI, and SSH
- Compliance: SOC 2 Type 2 certified (security)
- Spin-up: 1–2 seconds end-to-end
- Full workload runtime: Run agents, APIs, workers, databases, and background jobs alongside sandboxes
- Production track record: In use since 2021 across startups, public companies, and government deployments
- Pricing: CPU at $0.01667/vCPU/hour, memory at $0.00833/GB/hour (full GPU and compute pricing)
Running AI agents in production?
Northflank sandboxes support persistent and ephemeral environments, MicroVM isolation, GPU workloads, and BYOC (Bring Your Own Cloud) deployment in one platform.
- Sandbox environments overview: how persistent and ephemeral environments work on Northflank
- Get started: self-serve setup
- Pricing: CPU, memory, and GPU pricing
- Talk to an engineer: for specific infrastructure or compliance requirements
Fly Sprites are persistent Linux microVMs built by Fly.io that hibernate when idle and wake on demand.
- Filesystem: Persists across hibernation (files, installed packages, git repos, and databases on disk all survive)
- Memory: RAM does not persist (running processes stop and in-memory data is lost when a Sprite idles)
- Network config: Open ports and URL settings persist across hibernation
- Storage: 100GB per Sprite
- Wake time: 100–500ms warm, 1–2 seconds cold
- Checkpoints: Save filesystem state only (processes stopped during creation, in-memory state not included)
- Services: Defined processes that auto-restart on wake, used to keep servers running across hibernation cycles
- Isolation: Firecracker microVMs
- GPU: Not supported on Sprites
- BYOC: Not available (runs on Fly.io's managed infrastructure)
e2b is a platform built specifically for running AI-generated code in secure sandboxes, with a pause/resume model that saves both filesystem and memory state.
- Filesystem: Persists on pause/resume
- Memory: Persists on pause/resume (running processes, loaded variables, and data are all saved)
- Pause performance: Approximately 4 seconds per 1 GiB of RAM to pause; approximately 1 second to resume
- Paused sandbox retention: Kept indefinitely, no automatic deletion
- Continuous runtime cap: 24 hours on Pro tier, 1 hour on Base tier (resets after each pause/resume cycle)
- Snapshots: Available as a separate feature. Saves filesystem and memory state and can be used to create new sandboxes from a saved state.
- Isolation: Firecracker microVMs
- GPU: Not supported in sandboxes
- BYOC: AWS only, enterprise customers
Modal is a serverless infrastructure platform covering inference, training, batch compute, and sandboxes, with a snapshot-based persistence model across three maturity tiers.
- Filesystem Snapshots: Stable (copies filesystem at a point in time, stored as an Image, used to create new sandboxes, persist indefinitely). Restoring creates a new sandbox, not a resume of the original.
- Directory Snapshots: Beta (snapshots a specific directory within a running sandbox, expires after 30 days)
- Memory Snapshots: Alpha, not recommended for production (copies full sandbox state including memory, expires after 7 days, snapshotting terminates the sandbox, sandboxes with memory snapshots enabled cannot run with GPUs)
- Volumes: Network filesystems (Modal Volumes) can be mounted into sandboxes for persistent storage
- Isolation: gVisor
- GPU: Supported across the platform, but not available when memory snapshots are enabled
- BYOC: Not available
- SDK model: Python-first (environments are defined through Modal's Python library)
Here's a quick reference for matching your use case to the right platform.
| If your situation is... | Consider... |
|---|---|
| You need both persistent and ephemeral environments on one platform | Northflank |
| You need to deploy sandboxes inside your own cloud account or VPC | Northflank |
| You need GPU support in your sandbox workloads | Northflank |
| You need agents, APIs, workers, and databases running alongside sandboxes | Northflank |
| You need filesystem state to survive between executions with no session cap | Northflank or Fly Sprites |
| You need full memory and process state to survive a pause/resume | e2b |
| You need to save a filesystem snapshot and spin up new sandboxes from it | Modal (Filesystem Snapshots) |
| You want a persistent Linux environment that hibernates when idle and wakes on demand | Fly Sprites |
| Your workloads are Python-first and primarily ML/inference | Modal |
For teams with data residency or compliance requirements, Northflank (with SOC 2 Type 2 compliance) is the only platform here that supports BYOC deployment self-serve across multiple cloud providers and on-premises infrastructure.
Northflank supports GPU workloads in both persistent and ephemeral environments. Modal supports GPUs but sandboxes with memory snapshot support enabled cannot run with GPUs. Fly Sprites are CPU-only. e2b does not support GPU sandboxes.
Yes on Northflank, both are supported as first-class options and you configure per workload. On the other platforms, the persistence model is more fixed to the platform's primary design.
Northflank persistent environments run until you terminate them with no forced time limits. Fly Sprites idle automatically but the filesystem persists indefinitely. e2b paused sandboxes are kept indefinitely, though continuous runtime before a pause is capped. Modal Filesystem Snapshots persist indefinitely; Directory Snapshots expire after 30 days; Memory Snapshots expire after 7 days.
- What are persistent sandboxes?: The foundational explainer on what persistent sandboxes are, how they differ from ephemeral environments, and when you need them.
- Ephemeral sandbox environments: Covers how ephemeral sandboxes work and when they're the right choice over persistent ones.
- E2B vs Modal vs Fly.io Sprites: A deeper comparison of three of the platforms covered in this article, with more detail on isolation models and use case fit.
- E2B vs Sprites dev: A head-to-head comparison of e2b and Fly Sprites, covering persistence approach, isolation, and use case differences.
- Self-hosted AI sandboxes: Covers the self-hosted and BYOC route for teams with compliance or data residency requirements.
- Top AI sandbox platforms for code execution: A broader overview of sandbox platforms for code execution beyond the persistence-focused platforms covered here.
- Best code execution sandbox for AI agents: A platform comparison for agent builders evaluating code execution sandbox options.
